Решение проблем совместимости в DLE после обновления до PHP 5.4

Недавно столкнулся с необходимостью переноса нескольких сайтов моего знакомого на выделенный сервер, сайты построены на основе движка DLE (Data Life Engine) версий 8.3 и 9.3. Скопировал все файлы сайтов, выставил нужные права для чтения и записи на необходимые папки и залил дампы баз данных - после этого сайты заработали да вот только не совсем корректно... На сайтах пропали заголовки, в некоторых блоках текст, в админке при просмотре списка публикаций нет заголовков новостей, поиск публикаций по пользователю приводит к пустой белой страничке, проблемы с авторизацией через форму на сайте. Стоял выбор: даунгрейд PHP до версии 5.2 или правка движков под PHP 5.4 - я выбрал последний, казалось-бы сумасшедший вариант...

Содержание:

1. Предисловие
2. Ищем суть проблемы
3. Приступаем к исправлениям
4. Дополнительно
5. В завершение

Предисловие

Для начала решил поискать что народ думает и как поступает в данной ситуации, кинулся в поиск и наоткрывал разных форумов, сервисов вопросов-ответов. Все советы и комментарии сводились к нескольким решениям: даунгрейд PHP, обновление ДЛЕ до самой новой версии(там все корректно работает с PHP 5.4), сменить хостера )))

В общем я понял что нужно брать и разбираться самому, поскольку ниодного толкового совета я не встретил - я выбрал путь который идет вразрез со всеми советами и подсказками на форумах и конференциях.

(i) Если вам не интересны технические нюансы и нужно только руководство к действию то можете сразу переходить к нижней части  статьи.

Итак, для начала разберемся что же изменилось в PHP 5.4 без обратной совместимости, для этого в несколько кликов через Гугл попадаем вот сюда: Что изменилось в PHP 5.4.x?, а там идем по ссылке несколько несовместимостей.

Ищем суть проблемы

Вот основные необратимые изменения которые нам интересны:

• Безопасного режима в PHP больше нет (для ДЛЕ это не критично, здесь все ОК)
• "Волшебные" кавычки (Magic Quotes) теперь не работают (здесь желательно будет проверить)
• Возможность передачи по ссылке во время вызова функции была убрана (тоже может что-то поломать, проверим)
• Операторы break и continue теперь не принимают аргументов в виде переменной (редко встречал такое в ДЛЕ, думаю тут все ОК)
• Если вы используете функцию htmlentities с азиатскими наборами символов, то она работает также, как функция htmlspecialchars. (нужно будет проверить)
• Удалены некторые функции, нам интересны здесь: session_is_registered(), session_register() и session_unregister().

По умолчанию в DLE включено достаточное отображение ошибок, что нам очень кстати для отслеживания проблемных скриптов:

@error_reporting ( E_ALL ^ E_WARNING ^ E_NOTICE );
@ini_set ( 'display_errors', true );

Смотрим проблемные странички на предмет вывода сообщений об ошибке - сразу же наткнулся на ошибку:

Function set_magic_quotes_runtime() is deprecated

На сайтах стоят модули SAPE и матерится именно на файл-скрипт sape.php. Функции set_magic_quotes_runtime уже нет начиная с PHP 5.3, просто нужно удалить все вызовы этой функции из файла и все будет в порядке. Насчет обновления кода SAPE с сайта партнерки я париться не стал, все ссылки отображаются корректно.

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

После недолгих поисков по коду было найдено что текст заголовка перед выводом экранируется(фильтруется) функцией htmlspecialchars - эта функция нужна для преобразования специальных HTML символов в безопасные для вывода пользователю в браузер.

Убрав фильтрацию этой функцией все названия статей в админке вернулись на свое место. Функция htmlspecialchars используется достаточно часто и отказаться от ее использования очень неразумное решение, нужно разобраться почему она не работает.

Исследовав как в DLE в разных модулях вызывается данная функция я пришел к выводу что вызывают ее очень часто с одним аргументом, а иногда еще в качестве другого аргумента передается флаг ENT_QUOTES.

Обратившись к документации по PHP внимательно рассмотрим какие аргументы принимает функция:

string htmlspecialchars ( string $string [, int $flags = ENT_COMPAT | ENT_HTML401 [, string $encoding = 'UTF-8' [, bool $double_encode = true ]]] )

Итак 1й аргумент - строка для обработки, 2й - специальный флаг для указания необходимой обработки, 3й - кодировка, 4й - переключатель что указывает нужно ли преобразовывать существующие html-сущности.

Итак, флаги по умолчанию используются ENT_COMPAT | ENT_HTML401, кодировка по умолчанию UTF-8, следующий аргумент...стоп, стоп...кодировка по умолчанию UTF-8? - так у меня же сайты в CP1251, я решил попробовать принудительно указать функции htmlspecialchars кодировку cp1251 и что вы думаете, названия новостей стали отображаться правильно.

Решил я поГуглить насчет данной темы и выяснилось что функция htmlspecialchars в PHP 5.4 корректно работает с кодировками UTF-8 CP1251 если в качестве кодировки принудительно передать пустую строку, вот как:

$title = htmlspecialchars($str, ENT_COMPAT, '');
$title = htmlspecialchars($str, ENT_QUOTES, '')

Поправив все функции в движке с текстами все стало ОК.

Даже после исправления всех функций htmlspecialchars все же в некоторых модулях тексты могут отображаться в неверной кодировке. Причиной этому может быть функция htmlentities которая переводит символы HTMl в сущности. Вызов ее в скриптах осуществляется таким же образом как и htmlspecialchars, поэтому следует так же пройтись по всем скриптам где есть эта функция и исправить ее вызов.

Осталось разобраться с пустой страницей при выводе списка новостей по имени пользователя.

Отыскав модуль что отвечает за отображение этой странички я начал смотреть на чем затыкается выполнение скрипта. Ставим по порядку в разных местах скрипта вывод отладочного текста и смотрим на каком участке скрипта прекращается вывод отладки. Вот отладочный код для вставок - простой echo, здесь нечего выдумывать:

echo 'Testing 1';

Остановка может происходить из-за включения в скрипт другого скрипта, значит и его таким самым методом нужно прощупать до выяснения окончательной неработающей точки.

Таким способом было выяснено что к затыку приводит функция session_register() в одном из модулей что отвечает за авторизацию. После вызова данной функции инициализируются переменные в глобальном массиве $_SESSION. Имея опыт работы с сессиями я без опасения закомментировал функции session_register() и проблема с пустой страничкой исчезла - все отображается как нужно, с авторизацией нет проблем.

Можно конечно сразу же произвести поиск по всем скриптам на наличие в них функции session_register и поудалять ее там где она есть, но мне хотелось рассказатьь тебе, мой читатель, как еще можно выловить подобный баг.

Были также проверены и другие несовместимости PHP 5.4 на предмет наличия в скриптах сайтов на DLE - больше ничего править не понадобилось.

Подведем итог, подгонка старого движка DLE для работы с PHP 5.4 заключается вот в чем:

• исправление вызова функций htmlspecialchars().
• исправление вызова функций htmlentities().
• удаление/комментирование вызовов функции session_register().

Приступаем к исправлениям

Расскажу подробно как достаточно быстро и удобно поправить скрипты движка любой версии.

Чистка функции session_register().

1. Для работы нам будет нужен Total Commander и Notepad++.
2. Загружаем с сайта себе на локальный компьютер папку engine (если на сайте есть другие папки со скриптами, например forum, то нужно их также скопировать для будущей правки); Делаем копию архива с загруженными файлами в надежное место на всякий случай, если нужно будет что-то вернуть назад. Распаковываем еще одну копию файлов(они у нас будут рабочими) в любую удобную папку, например d:Work.
3. Открываем папку с загруженными скриптами в Total Commander'е и жмем ALT+F7 (поиск), там где "искать файлы" ставим *, а там где "С текстом" ставим галочку и вводим  "session_register(" и нажимаем Поиск;
4. По завершению поиска снизу в панели будут отображены найденные файлы, нажимаем кнопочку "Файлы на панель" - в панели Total Commander отобразится список с найденными файлами, выделяем их правой кнопкой миши и перетаскиваем в Notepad++.
5. Каждый файл отображен в своей вкладке, в каждом файле ищем вызов функции session_register с любыми аргументами и полностью ее удаляем. Для удобного поиска жмем CTRL+F и панель поиска переместим вправо к краю не закрывая ее, вводим туда session_register и чистим все найденные файлы от этой функции.

Для большей ясности изложенного приведу несколько скриншотов процесса:

Рис. 1. Поиск текста в в папке при помощи Total Commander.

Рис. 2. Помечаем файлы для редактирования в Total Commander.

Рис. 3. Поиск кода и его редактирование в Notepad++ (кликните для увеличения).

Исправления функции htmlspecialchars.

Здесь работки будет побольше. Так само по аналогии ищем все файлы скриптов, в которых встречается ф-я htmlspecialchars, таких файлов может найтись порядка 40-70 штук(в зависимости от количества установленных плагинов и модулей к движку), перетаскиваем их в наш любимый Notepad++ и производим правки в зависимости от того как вызывается ф-я, это очень важно!

а) Если функция вызывается с одним аргументом, например:

$title=htmlspecialchars($title)
$name = $db->safesql( $parse->process( htmlspecialchars( trim( $_POST['name'] ) ) ) );

то добавляем еще два аргумента, правим ее к слудующему виду :

$title=htmlspecialchars($title, ENT_COMPAT, '')
$name = $db->safesql( $parse->process( htmlspecialchars( trim( $_POST['name'] ), ENT_COMPAT, '' ) ) );

б) Если функция вызывается с двумя аргументами, например в fullsearch.php:

$tpl->set( '{result-author}', "<a href="mailto:".htmlspecialchars($row['gast_email'], ENT_QUOTES)."">"

то добавляем третий - пустая строка, кавычки:

$tpl->set( '{result-author}', "<a href="mailto:".htmlspecialchars($row['gast_email'], ENT_QUOTES, '')."">"

в) Есть моменты(таких немного, 1-2 шт примерно) где не нужно ничего трогать, например это файлы editnews.php, registration.php:

$name = $db->safesql(trim(htmlspecialchars($parse->process(convert_unicode($_POST['name'], $config['charset'])))));

Здесь переменная $_POST['name'] приводится к нужной кодировке с помощью функции convert_unicode в которую указана кодировка для предварительной конвертации из системной переменной $config.

Нужно очень внимательно исправлять все функции, смотреть вложенность и где какой аргумент. Notepad++ умеет подсвечивать синтаксис - пользуйтесь этим, став на одну из кавычек функции редактор подсветит ту кавычку, которая закрывает первую, вот как пример с вложенными функциями:

$db->safesql(htmlspecialchars(trim($_POST['name'])));

здесь понятно что перед подсвеченной кавычкой нужно добавить два аргумента исходя из предоставленных выше вариантов.

Аналогичным способом ищем и исправляем все вызовы функции htmlentities, их будет намного меньце - как правило несколько штук.

После всех правок закрываем редактор, упаковываем папки со скриптами в архив и закачиваем его на хостинг, там распаковываем архив с заменой файлов и радуемся результату. Желательно все же перед  распаковкой архива удалить старые папки со скриптами, так будет более надежно и мы будем уверены что скрипты у нас теперь те что нужно.

Если какую-то правку сделаете неверно то  очень скоро она себя проявит и вы достаточно быстро сможете ее исправить.

Также советую пройтись по всех ключевых моментах работы движка и проверить работоспособность - зарегистрировать пользователя, пройти авторизацию, создать новость, загрузить картинки, сохранить настройки в админке.

Итак включив свою логику и использовав простые подручные программные средства мы добились нужного результата. После вот таких сравнительно несложных но множественных операций работоспособность движка DLE, перенесенного на PHP 5.4, будет восстановлена. По крайней мере других глюков пока замечено не было. )

Дополнительно

В случае обновления PHP до еще более свежих версий может потревожить еще одна проблема несовместимости:

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead

Связана она с тем, что в целях безопасности использования функции "preg_replace" был "упразднен" модификатор "/e", который позволял в обработчике регулярного выражения исполнять содержащийся в строчке код (eval).

Например в DLE версии 8.3 эта функция используется в файле "engine/modules/show.short.php":

$tpl->copy_template = preg_replace ( "#\{date=(.+?)\}#ie", "langdate('\\1', '{$row['date']}')", $tpl->copy_template );

Простой замены названия функции с "preg_replace" на "preg_replace_callback" здесь не достаточно, нужно вынести исполняемую часть кода из строки в отдельную функцию и потом передать название этой функции (callback name) как аргумент для "preg_replace_callback".

Чтобы не выносить эту вспомогательную функцию в одтельный блок, ее можно указать в виде анонимной функции (без имени) прямо на позиции аргумента в "preg_replace_callback".

Переделав вызов функции "preg_replace" новый код будет выглядеть вот так:

$tpl->copy_template = preg_replace_callback(
    "#\{date=(.+?)\}#i",
    function ($matches) use ($row) {
        return langdate($matches[1], $row['date']);
    },
    $tpl->copy_template
);

При вызове "preg_replace_callback" все найденные совпадения по шаблону будут переданы в переменную $matches, также мы указываем что для работы внутри анонимной функции нам нужна внешняя переменная $row.

Дальше вызывается внешняя функция "langdate", в качестве аргументов ей передаются: 1) первое из найденных совпадений, хранящихся в переменной $matches 2) Строка из массива $row с индексом 'date'.

После этой переделки функции, модификатор "/e" уже не нужен, PHP интерпретатор будет доволен и все должно заработать.

Аналогичная, но более сложная задача может поджидать при исправлениях "preg_replace" с модификатором "/e" внутри классов, например в файле "engine/classes/parse.class.php".

Одна из строк кода с функцией "preg_replace" с модификатором "/e", требующая исправления (для удобочитаемости я перенес аргументы функции в новые строчки):

class ParseFilter {
    ... код
    function BB_Parse($source, $use_html = TRUE) {
       ... код
        if( ! $this->safe_mode ) {
            $source = preg_replace(
                 "'\[thumb\]([^\[]*)([/\\\\])(.*?)\[/thumb\]'ie", 
                 "\$this->build_thumb('\$1\$2\$3', '\$1\$2thumbs\$2\$3')",
                 $source
            );
            ... код

Функция "BB_Parse" является методом класса "ParseFilter", в ней при некотором условии вызывается "preg_replace".

Дело в том, что функция обратного вызова (callback) "$this->build_thumb" здесь не статическая (отдельно объявленная в коде глобально), а является методом этого же класса.

Вот каким образом можно в качестве коллбек-функции вызвать метод "build_thumb", который объявлен в том же родном классе "ParseFilter":

$source = preg_replace_callback(
    "'\[thumb\]([^\[]*)([/\\\\])(.*?)\[/thumb\]'i", 
    array( &$this, 'build_thumb'),
    $source
);

Но возникает другая проблема - в функцию обратного вызова можно передать только один аргумент, а в оригинальном неисправленном коде DLE 8.3 у нас два аргумента, причем не простые:

//                   1 аргумент       2 аргумен    
"\$this->build_thumb('\$1\$2\$3', '\$1\$2thumbs\$2\$3')"

Как видим, здесь в качестве первого аргумента коллбек-функции передается строка '\$1\$2\$3', состоящая из трех соединенных подстрок с найденными по шаблону функцией "preg_replace_callback" результатами:

• $1 - данные, извлеченные по шаблону "([^\[]*)";
• $2 - "([/\\\\])";
• $3 - "(.*?)".

Второй аргумент коллбек-функции - '\$1\$2thumbs\$2\$3', похожая строчка, для построения которой наряду с результатами поиска по шаблону ($1, $2 и $3) используется еще строчка 'thumb'.

Из названий методов и переменных в коде интуитивно можно разобрать что эта функция отвечает за построения (build) превью (thumb) к изображению, путь котрого найден и после генерации миниатюр будет заменен по шаблону функцией "preg_replace" или "preg_replace_callback".

Чтобы переделать эту конструкцию с учетом требований функции "preg_replace_callback" придется выкручиваться и придумывать какие-то дополнительные решения.

Например в этом же классе можно создать дополнительный метод - "обертку" для функции "build_thumb", который будет извлекать из единого переданного в коллбек-функцию аргумента (массива) все данные, и вызывать уже оригинальный метод "build_thumb" со всеми заранее подготовленными аргументами.

Назовем этот метод "build_thumb_callback", его объявление в классе будет выглядеть примерно вот так:

// Callback function (cover) for "build_thumb".
// "\$this->build_thumb('\$1\$2\$3', '\$1\$2thumbs\$2\$3')"
function build_thumb_callback($matches=array()) {
    $gurl = $matches[1] . $matches[2] . $matches[3];
    $url = $matches[1] . $matches[2] . 'thumbs' . $matches[2] . $matches[3];
    return $this->build_thumb($gurl, $url);
}

В начале не помешает добавить комментарий, указать оригинальный шаблон вызова коллбек-функции, который подвергается исправлению. Это поможет проще понимать суть работы, не придется скролить код.

Метод принимает один единственный аргумент "$matches", являющийся массивом и в нашем случае будет содержать 3 элемента с данными, найденными по шаблону функцией "preg_replace_callback" (из которой этот метод и будет вызываться).

Дальше объявляются две переменные "$gurl" и "$url", значения которых создаются путем соединения строк (оператор ".") в PHP, а в качестве соединяемых строк выступают найденные по шаблону значения из массива "$matches".

В конце мы вызываем оригинальным метод, в который и передаем подготовленные нами переменные "$gurl" и "$url".

После создания метода "build_thumb_callback" в классе следует указать его вызов в качестве Callback-функции для переделываемой функции "preg_replace_callback":

$source = preg_replace_callback(
    "'\[thumb\]([^\[]*)([/\\\\])(.*?)\[/thumb\]'i", 
    array( &$this, 'build_thumb_callback'),
    $source
);

Примерно вот так можно переделать вызовы функции "preg_replace" с модификатором "/e" на использование "preg_replace_callback" внутри метода кокого-то класса.

Хочу заметить что начиная с 10-й версии DLE код с модификаторами "/e" уже переработан, это также потянуло за собой переработку некоторых функций и методов классов.

Поэтому, примеры и подсказки для решения подобных задач можно подсмотреть в коде более новой версии движка Data Life Engine. Поскольку в новой версии искомые для DLE 8.3 строчки с кодом могут быть изменены, то поиск строки или ее части в дереве файлов более новой версии движка (10+) может завершиться неудачей.

Здесь лучше поступать вот так: смотрим в каком файле и какой его части, после какого куска кода размещен искомый нами код, потом ищем этот код примерно там же в файле движка новой версии. Таким образом, можно ориентироваться по методам классов, функциям "if" с уникальными аргументами и т.п.

Также не забываем про официальную документацию для PHP, например вот страничка по функции "preg_replace_callback" - PHP: preg_replace_callback - Manual. Обращайте внимание на комментарии к основному описанию функции - там есть много примеров использования функции и полезных уникальных решений.

В завершение

В этой статье я постарался с одной стороны - коснуться сложных технических моментов, а с другой - доступно разъяснить новичку как все исправить. Хотя работы получается не мало, но все же это может быть дешевле и более практично нежели делать даунгрейд PHP или переезжать к другому хостеру у которого есть поддержка старых версий интерпретатора скриптов.

К тому же, у PHP версий 5.4+ есть ряд новшеств, которые будут использоваться в более новых движках, которые вы возможно будете использовать, да и производительность сежих версий PHP, по сравнению с устарелыми, значительно возросла.

Буду рад выслушать ваши мнения и комментарии!

Если статья оказалась полезной - помочь проекту можно тут: → 👍 ПОМОЩЬ, 🎁 DONATE