Спустя почти три года с момента выхода ветки 5.3 представлен (http://www.php.net/archive/2012.php#id2012-03-01-1) релиз языка программирования PHP 5.4.0 (http://php.net/releases/5_4_0.php). Среди ключевых особенностей новой ветки отмечается (http://ru.php.net/migration54) реализация поддержки конструкции "Traits" и сокращенного синтаксиса массивов, увеличение производительности и сокращение потребления памяти, поддержка многобайтовых символов для всех сборок, добавление встроенного web-сервера в модуль CLI. В новой ветке удалены некоторые устаревшие возможности языка и опции настройки, поэтому версия 5.4 не обеспечивает полную совместимость на уровне API и конфигурации. При использовании PHP 5.4 может потребоваться модификация приложений и серверных настроек (например, удалена поддержка Safe mode и register_globals).
PHP 5.4 является первой веткой, разработка которой велась в рамках нового регламента (http://www.opennet.me/opennews/art.shtml?num=30752) подготовки релизов, подра...URL: http://www.php.net/archive/2012.php#id2012-03-01-1
Новость: http://www.opennet.me/opennews/art.shtml?num=33241
Отлично.
Теперь ждем пару-тройку корректирующих релизов, и можно ставить на свои сервера.
Вот правда хостинги еще не скоро на нее перейдут, если конечно вообще перейдут, что довольно спорный вопрос.
> хостинги еще не скоро на нее перейдутох уж эти сказочки... ох уж эти сказочники...
у некоторых слоупоков ещё 5.2 стоит, но это не значит, что все такие неумные
Просто перевод на новую ветку PHP стоит немалых денег.
Чего сложного в давании возможность выбрать версию PHP ?
в настройки сервера. купите себе VPS и выбирайте там все что хотите
> в настройки сервера. купите себе VPS и выбирайте там все что хотитеА без vps, возможность выбора версии PHP для всех клиентов на сервере ?
перевод чего? софта? хостинга? или ваших мыслей?
Для хостинга это вообще ноль проблем, если, конечно, изначально нормально устроена архитектура. Добавить ещё один выполняемый CGI-шник, знаете ли, не потребует даже рестарта httpd.
Ну, CGI в эпоху поставляемого искаропки FPM -- это китч. ;)
1. Если уж на то пошло, то FastCGI - это разновидность CGI.
2. PHP-FPM "искаропки", как известно, не старше PHP 5.3.0. Который также далеко не везде даже с CGI.
3. Китч - это то, что у РНР до сих пор нет вменяемой альтернативы. Которая была бы сравнима по популярности, скорости, кол-ву расширений и простоте развёртывания.
Приходится писать на рнр и плеваться.
>у РНР до сих пор нет вменяемой альтернативы. Которая была бы сравнима по популярности, скорости, кол-ву расширений и простоте развёртыванияpython?
>>у РНР до сих пор нет вменяемой альтернативы. Которая была бы сравнима по популярности, скорости, кол-ву расширений и простоте развёртывания
> python?Нет. Я не имею ничего против питона, но рассматривать его как альтернативу в веб-программинге я не могу ни при каких условиях. Думаю, так же, как и 90% веб-программистов.
Perla вполне хватает.
для кого? не смешите.
> для кого? не смешите.для того, кто отделяет "мухи от котлет"... не ведет в одном файле верстку, стили и обработку..
Назовите хоть один Perl-шаблонизатор со Smarty-синтаксисом и возможностями такого же уровня?
TT, синтаксис естественно отличается
Я вообще-то не прогер, однако в админской части приходится иметь дело с массой разноязыких скриптов. Вот например, нижеследующая питоновская конструкция всего лишь призвана получить объект класса datetime из куска представления даты (типа '20120306'):
dt1 = datetime.datetime.fromtimestamp(time.mktime(time.strptime(dt, '%Y%m%d')))
Намеренно привел полную форму записи (без всяких 'from datetime import xxx').Мне - не нравится. 2 класса и 3 функции для выполнения простейшей (в рамках скриптового языка) задачи. Аналогично нужно обработать исключение, чтобы проверить валидность введенной даты.
Это типа иллюстрация простоты написания. Теперь касаемо простоты развертывания. У питона для fast-cgi есть собственный WSGI класс. Хорошо? Ровно до тех пор, пока будете пользоваться готовыми фреймворками типа джанги. После пыха, который вкручивается в html где надо, питон выглядит ничуть не привлекательнее перла.
Что-что? Питон компилится? А вы внутрь этого самого "компилится" заглядывали? Могу сказать за подручную связку CentOS-5 + python-2.4 (понятно, оно древнее, но революции во 2-й ветке 1x запретили). Так вот, это тупо однопроходный псевдокод без попыток хотя бы проверить приведение типов. Поэтому, WSGI-сервер отлаживается примерно так:
* Исправили код
* Рестартовали питон (btw, конструкция "killall script.py" тут в пролете)
* Исправили права на wscgi-сокет (если оно должно с разными привелегиями исполняться)
* Зашли на страничку, нагребли пачку багов (вероятно, есть способ перенаправить сиё в файл, так глубоко не копал)Это я все не в оправдание пыха написал, а к тому, что крики "питон-рулез" ну как бы пока преждевременны. Так же как перл сохраняет актуальность при парсинге текста, например. А в шелле удобнее выполнять конвейерную обработку. И т.д.
что-то не видно любителей гвидобейсика со срыванием покровов. то ли ниасилили многабукаф, то ли уроки ещё не закончились.
Ну если PHP был подключен через CGI (ха-ха-ха, бред полнейший), то действительно не проблема. Только через CGI на shared хостингах PHP никто не подключает из-за низкого перфоманса.
> Ну если PHP был подключен через CGI (ха-ха-ха, бред полнейший), то действительно
> не проблема. Только через CGI на shared хостингах PHP никто не
> подключает из-за низкого перфоманса.1. Если 80% российских хостингов - это никто, кто же тогда по-вашему "кто"? И вообще не рекомендую бросаться обобщающими словами: "Никогда не говори никогда".
2. Насчёт "бреда": а как ещё обеспечить выполнение разных версий всего-всего-всего? Хотя бы пыхов версий 4, 5.2, 5.3, помноженных на разные сейф моды, АРС, зенд-декодеры и пр. Вообще, CGI - единственное удобное решение для предоставления юзеру возможности конфигурировать пых (на шаред-хостинге). Есть ещё, конечно, всякие user-mode апачи в джейлах и пр, но тут уже неизвестно, что будет проще и быстрее.
3. Да и не такие уж большие потери на CGI для той ниши, на которую изначально рассчитан РНР - personal home pages :) А те, кто на пыхе пишет серьёзные проекты, наверно могут поднять его и на собственном физ/вирт серваке.
4. "Перфоманс" и программирование на рнр - вещи, совместимые в исключительно редких случаях. Кстати, тот же друпал и кое-какие другие известные системы (зенд) на некоторых хостингах были попросту запрещены - по причинам их перфоманса.
5. В принципе, нормальным людям давно очевидно, что скрипты и перформанс - вещи несовместимые. А как эти скрипты выполнять, CGI или модулем, это уже не столь важно, если они заново парсятся каждый раз. Именно поэтому и делают всякие APC, Zend optimizer, а так же node.js и тд. Надеюсь, что если node.js получит широкое распространение, перейду на него. А РНР пусть остаётся там, где ему и место исходя из названия.
Если хостер будет запускать PHP как CGI это немного повысит нагрузку на сервер и сможет размещать на сервере немного меньше клиентов. Поэтому будет немного нерентабельно.
Сайты у клиентов последнее время жирненькие (Joomla Wordpress Bitrix Drupal) и если хостер будет использовать CGI то пользователи будут страдать от такой тормознутости и поищут другого хостера. Если конечно вы имеете ввиду именно CGI , а не FastCGI . С FastCGI производительность будет не так страдать.Хотя часть движков имеют в списке своих технических требований Apache + mod_php , в этом случае хостеры с CGI отпадают.
> это немного повысит нагрузку на сервероригинальное написание слова "катастрофически"...
>> это немного повысит нагрузку на сервер
> оригинальное написание слова "катастрофически"...Вы исследования проводили?
Имхо так, катастрофически повысив нагрузку на сервак путём собственно установки (чего-то на базе) РНР, насколько повысится нагрузка из-за CGI - уже никого не волнует.
Следует заметить (ещё раз), что:
1. высоконагруженные сайты обычно всё-таки используют выделенный сервер.
2. настроить хостинг на несколько сосуществующих версий РНР и динамически изменяемые конфигурации (состав РНР модулей, настройки типа magic_quotes) фактически доступно только при CGI. Либо онанизм с переносом клиентских сайтов с одного сервака на другой...
3. Исполняемый файл РНР CGI с парой основных модулей - 2-3 МБ, вполне успешно кешируется не то что дисковым кешем ОС, но и кешем проца, если, конечно, это не пентиум-про.
4. Так как помимо РНР, можно предоставлять ещё и перл, сш, питон, ещё хз что, и всё это не имеет никакого смысла встаивать в НТТР сервер (иначе он будет блобом), а также тк с CGI можно использовать апач в режиме worker, а не prefork (многопоточность vs многопроцессность), вся эта суета вокруг ничтожной потери - бессмысленна.
И ещё, не забывайте, уважаемые сэры, что виртуальный хостинг в принципе предназначен не для высокой производительности, а для того, чтобы его использовало максимальное кол-во клиентов. А если сайты клиентов будут тормозить, то виноваты в этом ... сами клиенты. Велкам, платите бабло и переходите на выделенный хостинг. А объяснять клиенту, который поставил жумлу в первый раз в жизни, что его сайт тормозит из-за того, что это жумла тормозная, во-первых, некогда, а во-вторых, коммерчески нецелесообразно.
>>> это немного повысит нагрузку на сервер
>> оригинальное написание слова "катастрофически"...
> Вы исследования проводили?чиво?
> Следует заметить (ещё раз), что:
> 1. высоконагруженные сайты обычно всё-таки используют выделенный сервер.это решительно не повод долбиться с кривульками.
> 3. Исполняемый файл РНР CGI с парой основных модулей - 2-3 МБ,
> вполне успешно кешируется не то что дисковым кешем ОС, но и
> кешем проца, если, конечно, это не пентиум-про.просто послушать и забиться на волне радости.
> 4. Так как помимо РНР, можно предоставлять ещё и перл, сш, питон,
> ещё хз что, и всё это не имеет никакого смысла встаивать
> в НТТР сервер (иначе он будет блобом), а также тк с
> CGI можно использовать апач в режиме worker, а не prefork (многопоточность
> vs многопроцессность), вся эта суета вокруг ничтожной потери - бессмысленна.какой, простите, апач? у вас рефрижератор сломался? у вас альтернатива апачу cgi? тогда протеоретизируйте про php-fpm.
> И ещё, не забывайте, уважаемые сэры, что виртуальный хостинг в принципе предназначен
> не для высокой производительности, а для того, чтобы его использовало максимальное
> кол-во клиентов.вы вогнали меня в ступор: то выделенный сервер, то максимальное количество клиентов. вы уж определитесь.
> Если хостер будет запускать PHP как CGI это немного повысит нагрузку на сервервот именно, что немного
> Поэтому будет немного нерентабельно.
Между "немного нерентабельно" и "немного менее рентабельно" есть немного разница.
> Сайты у клиентов последнее время жирненькие (Joomla Wordpress Bitrix Drupal)
В том-то и дело, что CGI создаёт оверхед только при запуске исполняемого файла, а во время выполнения скрипта уже не важно, в чём он выполняется. Так что если запуск будет дольше на 0.01с, при времени выполнения скрипта 10с, сами понимаете, что никому от этого жарче или холоднее не станет.
Плюс, с CGI можно запустить апач c worker mpm (один многопоточный процесс), а с РНР модулем - только c prefork mpm, что само по себе даёт оверхед и имеет тенденцию к блокировке при большом кол-ве запросов. Да и с учётом утечек памяти, РНР модуль быстрее только в первые Х запросов после старта, а потом, бабушка на три (Х3) сказала...
> и если хостер будет использовать CGI то пользователи будут страдать от такой тормознутости и поищут другого хостера.
Я работаю со многими хостерами и практически у каждого приходится использовать CGI, потому что РНР 5.3 в модуле апача нет почти ни у кого, а работает он именно в CGI.
> Если конечно вы имеете ввиду именно CGI , а не FastCGI . С FastCGI производительность будет не так страдать.
С FastCGI на хостингах мне не приходилось встречаться. Да и ещё раз замечу, что настроить CGI гораздо проще (в том числе и для юзера - поменять настройки РНР), а оверхед в 0.01с/скрипт (а то и меньше - можно повесить /cgi-bin в memfs), знаете ли, не то, из-за чего стоит ломать копья.
> Хотя часть движков имеют в списке своих технических требований Apache + mod_php , в этом случае хостеры с CGI отпадают.
А часть движков юзает ещё РНР 4.
Оффтоп: А ещё часть движков просто кривая :)
>CGI можно запустить апач c worker mpm (один многопоточный процесс), а с РНР модулем - только c prefork mpmЕсть один хостер где апач с worker mpm (собственного производства) и можно выбирать версию PHP между 5.2 и 5.3
Это вопрос или утверждение?
Если вопрос, то почему нет в конце соответствующего знака препинания?
Если утверждение, то почему не прослеживается его суть?
> Если хостер будет запускать PHP как CGI это немного повысит нагрузку на
> серверИ таки да. Финальный аккорд на тему про производительность с CGI.
Вы знаете хоть один современный движок/CMS, не использующий БД?
А теперь представьте, что у хостера (и это опять же не редкость) выделенный сервер с БД (т.е. не localhost). Сколько составят временные расходы на работу с БД в % от общего времени выполнения скрипта?
Итак, можно разделить выполнение скрипта на этапы и прикинуть время на их выполнение:
1. Всякие include/require - 10-20%
2. Парсинг - 10-20%
3. Общение с БД - 30-70%, а то и все 90%
4. Ввод-вывод - 30-50%
5. Собственно отдача по сети - 10-20%
Сколько уйдёт на собственно запуск CGI - 1% или 10%, здесь уже не столь существенно.---
При этом, если разного рода умные веб-программисты пишут такой код:
$query = 'SELECT ...';
if ( mysql_numrows( $db->query($query) ) > 0 ) {
while ( mysql_fetch_assoc( $db->query($query) ) { ... }
}
... то в этом случае что в режиме CGI, что в режиме модуля, это один хрен создаст 100% загрузку (на процесс) в течение max_execution_time ...
На переподсоединение к БД из CGI время должно порядочно идти
> На переподсоединение к БД из CGI время должно порядочно идтиВ нормальных языках программирования соединение с бд поддерживается а не перезапускается :-))
>> На переподсоединение к БД из CGI время должно порядочно идти
> В нормальных языках программирования соединение с бд поддерживается а не перезапускается
> :-))Какие "языки" подпирают такими костылями =CGI= (не Fast-, не WS-) ?? Очень интересно же.
А как там на счёт включения в базовый пакет расширенных кэширующих утилит? Вроде APC (Alternative PHP Cache, относится к акселераторам PHP) хотели включить по умолчанию. Правда он давненько не обновлялся.
Кстати, тоже интересно почему. Т.е. я вообще не знаю причин, по которым нужно было бы не включать акселерацию кода. Просветите, если таковые вообще есть.
Насколько мне известно APC входит в базовый состав уже с версии PHP 5.1
они избавляются от "базовых" и переносят инфраструктуру в PECL. APC уже давно в нём.
А можно где-нибудь ознакомится с дальнейшими планами разрабов?
https://wiki.php.net/todo
https://wiki.php.net/rfc
Придётся поставить на локалхост и протестировать проекты.
ждали 6.0 а вышел 5.4.0
Поддержку юникода в стандартные строковые функции так и не встроили?
> Поддержку юникода в стандартные строковые функции так и не встроили?хмм. А побайтно тогда какими функциями кодить?
можно ими же, строковые функции ведь по моему должны с символами работать а не с байтами, количество байт определять в зависимости от текущей кодировки, ну а если надо работать именно с кусками памяти (байтами) то тут опять таки по моему лучше отдельные функции сделать, логичность и читаемость кода лучше будет
> можно ими же, строковые функции ведь по моему должны с символами работать
> а не с байтами, количество байт определять в зависимости от текущей
> кодировки, ну а если надо работать именно с кусками памяти (байтами)
> то тут опять таки по моему лучше отдельные функции сделать, логичность
> и читаемость кода лучше будетчто-то вы запутались.
Вот есть у меня блоб (binary large object). Как я с ним буду работать строковыми функциями, использующими кодировку??? Мне нужен побайтный доступ, а не посимвольный, да ещё и с проверкой допустимости (utf-x).
То, что нужно раздельные функции - я согласен, но как, пардон, переделать УЖЕ существующие строковые (побайтные) функции для поддержки кодировок, чтобы при этом не пришлось переписывать 146% кода? К тому же, сейчас и так есть mb_* функции, которые работают с кодировками. Нужно всего лишь сделать каждой бинарной функции пару - mb_*.
Эт гдеж то я запутался если вы согласны? К уже существующим однобайтным строковым функциям надо добавить поддержку работы с многобайтовыми символами, в зависимости от текущей кодировки, если она у вас однобайтная (вы ее так выставили), то никаких 146% переделывать не надо, а если работаете с многобайтной то они автоматически начинают работать с ней, тогда вне зависимости от кодировки строковые функции остаются строковыми и работают с символами а не байтами, и переделывать ничего не надо, а для работы с бинарными данными (байтами, LOB) отдельные побайтовые функции, и проверка допустимости utf тут уже дело десятое, если у вас utf, т.е. текст, работайте строковыми функциями, впрочем на уровне кусков памяти они свободно совмещаются.
ибо понимаете, сейчас фигня какая получается, для одних строк одни функции, для других другие, для лобов строковые, все это запутывает, а так все будет четко и понятно - для строк строковые, одни и те же вне зависимости от кодировки, а для лобов - лобные
Наконец то дождались :)))
register_globals фтопку
magic_quotes_gpc фтопку
временные зоны в виде отклонения от гринвича фтопку
utf-8 по дефолту
сокращённый синтаксис для массивов
разыменование массивов
задание бинарных чисел
и общее ускорение в целом :))Теперь осталось подождать пока это добро вместе с apache 2.4.1 соберут на openSUSE ...
По поводу быдлоадминов быдлохостеров они скорее сами ся в зад отымеют, чем откажутся от magic_quotes_gpc ON...
Остаётся надеется на отдельные сервера специально запущенные под 5.4.x
> Наконец то дождались :)))
> utf-8 по дефолтуугу, и терь каждый раз проверять, по дефолту оно или нет, как с magic_quotes =)
> сокращённый синтаксис для массивов
> разыменование массивоввот ещё бы массив в виде объекта... Бесит то, что нельзя прозрачно использовать ArrayObject и массив.
> Остаётся надеется на отдельные сервера специально запущенные под 5.4.x
CGI.
Хотя даже под CGI и то появится это чудо на хостингах не раньше года-двух спустя...
>> Наконец то дождались :)))
>> utf-8 по дефолту
> угу, и терь каждый раз проверять, по дефолту оно или нет, как
> с magic_quotes =)Дефолт значит дефолт его проверять не нужно, конечно если собираетесь писать исключительно под 5.4 я имел ввиду что он поддерживает многобайтовые кодировки по умолчанию то меж utf-8 для всех операций со строками.
>> сокращённый синтаксис для массивов
>> разыменование массивов
> вот ещё бы массив в виде объекта... Бесит то, что нельзя прозрачно
> использовать ArrayObject и массив.Ну не всё сразу :))
>> Остаётся надеется на отдельные сервера специально запущенные под 5.4.x
> CGI.
> Хотя даже под CGI и то появится это чудо на хостингах не
> раньше года-двух спустя...На моём хостинге он будет сразу же как его или в зелёнке собирут, или я на Arch Linux перейду, а там уже если серьёзные заказы у меня будут то поиск сервера с 5.4.х будет проблема моего менеджера а не моя :)
>>> сокращённый синтаксис для массивов
>>> разыменование массивов
>> вот ещё бы массив в виде объекта... Бесит то, что нельзя прозрачно
>> использовать ArrayObject и массив.
> Ну не всё сразу :))С РНР, по-видимому, уже не только "не сразу", но вообще никогда.
Смотрю на node.js. Вот там, надеюсь, будет "сразу".>>> Остаётся надеется на отдельные сервера специально запущенные под 5.4.x
>> CGI.
>> Хотя даже под CGI и то появится это чудо на хостингах не
>> раньше года-двух спустя...
> На моём хостинге он будет сразу же как его или в зелёнке
> собирут, или я на Arch Linux перейду, а там уже если
> серьёзные заказы у меня будут то поиск сервера с 5.4.х будет
> проблема моего менеджера а не моя :)Если бы в мире был только один хостинг и только ваш :) Увы, это не так.
>>>> Остаётся надеется на отдельные сервера специально запущенные под 5.4.x
>>> CGI.
>>> Хотя даже под CGI и то появится это чудо на хостингах не
>>> раньше года-двух спустя...
>> На моём хостинге он будет сразу же как его или в зелёнке
>> собирут, или я на Arch Linux перейду, а там уже если
>> серьёзные заказы у меня будут то поиск сервера с 5.4.х будет
>> проблема моего менеджера а не моя :)
> Если бы в мире был только один хостинг и только ваш :)
> Увы, это не так.Ну, как говорится, хочешь изменить мир - начни с себя!
Я начал :))
> версия 5.4 не обеспечивает полную совместимость на уровне API и конфигурации. При использовании PHP 5.4 может потребоваться модификация приложений и серверных настроекЯ так понимаю, на такие понятия, как "совместимость" и "поддержка старых версий" забили напрочь.
Уже сейчас детища zend optimizer делятся на "закодированные в php5.2" и "закодированные в php5.3".
Я так понимаю, к ним добавится "закодированные в php5.4".
5 баллов.
Хотя это, естественно, не так смертельно.
Есть сейчас файл /opt/php52/bin/php-cgi + zendoptimizer.so.
Добавится /opt/php53/bin/php-cgi + zendloader.so.
А php54 будет, как основная в системе.Кстати, кто там ругался на говнохостинги с php-cgi?
Вот если бы в php больше заботились о совместимости, сейчас везде использовали бы 1(одну) версию php-fpm (с возможностью переключиться на mod_php, ради .htaccess).
И все просто обновили бы php до последней версии.
А так... mod_php4/php4-cgi/mod_php52/php52-cgi/mod_php53/php53-cgi/mod_php54/php54-cgi.
А когда выйдет php6.. ну, вы поняли)
> Кстати, кто там ругался на говнохостинги с php-cgi?кто ругался, не знаю, лично я всеми руками за хостинги с php-cgi
> Вот если бы в php больше заботились о совместимости
хм, уж нет уж. Пусть ломают всё к чёрту! Не нужна мне такая совместимость, при которой я должен буду в 21 веке писать код без нормальной работы с ООП и массивами, зато с уёжским magic_quotes и всем-всем-всем.
Хотя, честно, РНР уже задрал. И не меня одного. Почему-то в его светлое будущее уже совсем не верится, и даже скорее, желается ему подохнуть поскорее)))
>Хотя, честно, РНР уже задрал. И не меня одного. Почему-то в его светлое будущее уже совсем
>не верится, и даже скорее, желается ему подохнуть поскорее)))Это вы еще не видели встроенный язык 1С.
>>Хотя, честно, РНР уже задрал. И не меня одного. Почему-то в его светлое будущее уже совсем
>>не верится, и даже скорее, желается ему подохнуть поскорее)))
> Это вы еще не видели встроенный язык 1С.Да уж, в точку.
Потому всё-таки перл, как бы его не ругали. Вполне себе решение.
>>>Хотя, честно, РНР уже задрал. И не меня одного. Почему-то в его светлое будущее уже совсем
>>>не верится, и даже скорее, желается ему подохнуть поскорее)))
>> Это вы еще не видели встроенный язык 1С.
> Да уж, в точку.
> Потому всё-таки перл, как бы его не ругали. Вполне себе решение.Если учесть, что на подходе perl6, который несколько отличается от perl5, там тоже будет веселый переход)
а зачем вам optimizer?
Если ваш продукт хорош (а он должен быть хорош, ведь не будете же вы защищать убогое поделие:), его всё-равно купят. Ради поддержки хотя бы. А если кто-то зажмотился и скопировал - вам от этого ни холодно и не жарко - он всё-равно вам не заплатил бы. Это как с любым софтом. Какие либо системы защиты лишь усложняют (увеличивают стоимость) продукт, и не несут никакой пользы - всё ломается за разумное время. А если вы в ульранизкобюджетном секторе - вы всё-равно работаете за еду и стоимость копии и защиты равна стоимости тарелки супа.
> а зачем вам optimizer?Представьте, что вы - хостер.
Ваш пользователь купил у вас хостинг по дорогому тарифу, заплатил сразу за год.
И ставит какой-то движок, закодированный zend optimizer под php5.2.
Спросите у него, зачем ему optimizer.
Предложите забить на движок, как на устаревший.
А он забьет на ваш хостинг.