Ошибка в статьях: Warning: Division by zero in /xxx/zzz.php on line 156 (версия от 21.04.2010)

Добрый

После установки на 3 независимых хостинга получаю одно и тоже сообщение
Warning: Division by zero in /******************6730ae.php on line 154

Вручную проверил, статьи перетянулись, проблема именно с выводом.

 

Сейчас попытаюсь технически описать эту ерунду.

Статьи на хостинге это 4 файла:

* .htaccess для красивых урлов
* xxx.php - скрипт получения и рисования статей
* xxx.txt - файл для хранения кэша статей
* xxx.html - файл шаблона

Так вот xxx.php при запуске считывает файл шаблона и выдирает из него все что нужно для нормальной отрисовки статей в том виде как это задал пользователь. Физически это объект запакованный функцией serialize() с различными полями, как-то tpl_page - большой шаблон, tpl_articles_per_page - число статей на страницу, tpl_title_main - тайтл статейного раздела и др.

Генератор кода на стороне сервера считывает что же ввел пользователь в соответствующие поля, собирает это в один объект и соединяет в xxx.html файл при помощи функции seialize. А сохраняет он это в директорию data. А пользователь может потом скачать все это в виде архива и скопировать на хостинг.

Так вот иногда случаются чудеса. Вот один пример. Ошибка вида:

на самом деле не одна, если их включить все, то мы увидим еще одну, главную:

То есть функция unserialize прямо ругается на то, что по смещению 14072 какая-то неожиданная фигня. И если заглянуть в файл xxx.html, то там действительно фигня. По данному смещению мы попадаем не на следующее поле объекта, а прямо в строку. То есть получается, что сбоит именно php на стороне сервера, который не правильно запаковывает объект в строку. И в результате клиентский код видит какую-то фигню и умирает с простецкой ошибкой - деление на ноль (он просто не смог считать знаменатель и сделал его равным нулю).

Моя мысль в следующем. На стороне сервера надо проверять корректность запаковки объекта и делать его serialize до тех пор, пока unserialize не будет возвращать ошибку. Соответствующий апдейт сделаю.

Странное дело, но получается, что виноват PHP.

P.S. Тогда все становится на свои места - те, у кого это ошибка была после перегенерации получали нормальный файл с нормальными смещениями и все работало.

 

Новую версию 2010.05.04 можно скачать. По сути изменился только один файл /modules/articles.php. Для того, что бы проверить что все заработало, достаточно зайти в шаблон статьи где наблюдаются проблемы и заново его сохранить. После чего сделать архив для хостинга и залить туда же. Добавил проверку на корректность выполнения serialize. Посмотрим что из этого выйдет.

 

МЫ ПОБЕДИЛИ

Все дело в режиме передачи текстовых файлов. После того как мы скачиваем архив, мы его распаковываем а затем заливаем на хостинг. Так вот существуют два режима передачи файлов TEXT и BINARY. TEXT использовать нельзя, только BINARY. TEXT тупо урезает размер файла, убирая "неправильные" переводы строк.