PHP Fatal error: ob_end_clean(): Cannot use output buffering in output buffering display handlers in /home/bitrix/ext_www/_____________/bitrix/modules/main/classes/general/main.php on line 3113
UPD ошибка оказалась в:
использовании функций буферизации ob_* в шаблоне компонента breadcrumb
в init.php подключался файл, где использовался $cache->StartDataCache, который использует буферизацию (ob_start и ob_end_clean).
в событии OnEndBufferContent нельзя использовать конструкции вида ob_start(), вызывающую ошибку при этом: ob_start(): Cannot use output buffering in output buffering display handlers (0) - а следовательно в обработчике событий OnEndBufferContent не допускается использовать старый d0 класс CPHPCache, который вызывает ob_start() у себя под капотом.
Решение - использовать класс d7 \Bitrix\Main\Data\Cache с вызовом \Bitrix\Main\Data\Cache::noOutput() перед запуском \Bitrix\Main\Data\Cache::startDataCache() ну или использовать хак-магию доступа к приватному члену класса CPHPCache
Обратите внимание, что в событии OnEndBufferContent нельзя использовать конструкции вида ob_start(), вызывающую ошибку при этом: ob_start(): Cannot use output buffering in output buffering display handlers (0)
а следовательно в обработчике событий OnEndBufferContent не допускается использовать старый d0 класс CPHPCache, который вызывает ob_start() у себя под капотом.
Решение - использовать класс d7 \Bitrix\Main\Data\Cache с вызовом \Bitrix\Main\Data\Cache::noOutput() перед запуском \Bitrix\Main\Data\Cache::startDataCache()
Задача тривиальная и решений у нее много. В основном все "по старинке" дергают событие поступления почтового события и в нем что-то делают с массивом письма шаблона (дописывают недостающие и/или модифицируют имеющиеся).
Я набросал решение с класса \Bitrix\Sale\Notify, который не особо документирован, но с него накопировал кода под заполнение плейсхолдеров, как в шаблоне SALE_NEW_ORDER.
Ниже код, как пример использования, собрал на "быструю руку":
В статье будут рассмотрены темы: — Развитие синтаксиса PHP — Будет дан ответ на аксиому "почему только 5.3, не выше?" и что из нового синтаксиса можно. — Вопрос совместимости, "исторические хвосты"
Мы в данный момент работаем по версии 5.3. Ниже я описываю новые улучшения в 5.4 и 5.5. К сожалению, возможности из этих версий пока использовать НЕЛЬЗЯ. Можно использовать только возможности 5.3.
Важно! Пиши на PHP 5.3! Все вещи, которые доступны выше 5.3 необходимо решать путем создания промежуточных вспомогательных переменных!
Итак, чтобы рассмотреть эту аксиому подробнее, рассмотрим эволюцию синтаксиса PHP, что же появилось в новых версиях (будут рассмотрены не все улучшения, а только вопросы коротких разыменований, и важных в связи с выходом D7).
Сталкивались ли вы с тем, что клиенты используют обновления битрикс как манипулятивный рычаг давления, чтобы спихнуть ошибки предыдущих разработчиков на тех, кто произвел обновление ядра (ядро не модифицировалось предыдущим разработчиком)?
(доводы клиента: до обновления все работало и прочее, верните все как было)
или это классическая ментальная ошибка, когда произошедшие одновременно вещи считают связанными?
или все-таки есть риски и большие при обновлении ядра?
хотя обновления ядра объективно - это ресурс, причем платный.
Чебан Валерий, ну пусть сам нажмет, а если без шуток, то он платит за минимизацию рисков.
Сложно объяснять это только в тех случаях, когда сайт генерирует 10 заказов, когда на сайте 1000 заказов в сутки - все вопросы отпадают, так как ошибка, которая может масштабировать убытки или простой сайта в результате ошибки - это всегда дороже.
Всегда найдется тот, кто сделает дешевле и вообще не учитывает всяких особенностей по предыдущему опыту, так как у него его просто нет. Где-то общался на fb и обсуждали тему сроков запуска интернет-магазина. Все пишут что недели 2 надо, но тут же пишут, что никогда такого не было. 2 недели типа это в идеальном сценарии, которого на их памяти не было практически никогда. Ну и встречный вопрос им - зачем тогда вы вообще озвучиваете сроки в 2 недели если это неправда?
Белокрылов Виталий, мы с вами полностью совпадаем в понимании и рисков и ожиданий клиентов, а эту тему я тут поднял, чтобы кидать на нее ссылку и, возможно, сэкономить собственные силы и время. вам спасибо за развернутые ответы!
SEL ECT `ID`, `IBLOCK_ID`, `NAME` FR OM `b_iblock_element`
WHERE `ID` IN (115, 120, 117, 109, 128) AND `IBLOCK_ID` = 5
ORDER BY FIELD(`ID`, 115, 120, 117, 109, 128);
Успешно запустил свой домашний блог, написанный на bitrix, на версии php7. Версия bitrix – последняя beta. Замерил утилитой ab-тестирования (из комплекта с Апатчем) скорость работы в первом и втором случаях:
Методика тестирования: Меняем версию PHP в настройках апатча и прогоняем тесты ab-утилитой. Также смотрим на время генерации страницы модулем производительности. Ничего особенно, но для ответа на вопрос: а быстрее ли bitrix с php7? и примерно на сколько быстрее?
Usage: ab [options] [http://]hostname[:port]/path
Options are:
-n requests Number of requests to perform
-c concurrency Number of multiple requests to make at a time
-s timeout Seconds to max. wait for each response
Default is 30 seconds
-k Use HTTP KeepAlive feature
…
Результаты следующие:
PHP 5.6 on Bitrix Vs.
PHP7 (Zend Engine v3.0.0) on Bitrix
Apache/2.4.20 (Win64) PHP/5.6.20
Document Length: 2987 bytes
Concurrency Level: 10
Time taken for tests: 134.852 seconds
Complete requests: 5000
Failed requests: 2
Requests per second: 37.08 [#/sec]
Time per request: 269.703 [ms]
Time per request: 26.970 [ms] (mean, across all concurrent requests)
Transfer rate: 130.68 [Kbytes/sec] received
Apache/2.4.20 (Win64) PHP/7.0.5
Document Length: 2987 bytes
Concurrency Level: 10
Time taken for tests: 130.592 seconds
Complete requests: 5000
Failed requests: 2
Requests per second: 38.29 [#/sec]
Time per request: 261.183 [ms]
Time per request: 26.118 [ms] (mean, across all concurrent requests)
Transfer rate: 133.86 [Kbytes/sec] received
Percentage of the requests served within a certain time (ms)
50% 98
66% 104
75% 108
80% 111
90% 120
95% 131
98% 151
99% 215
100% 42081 (longest request)
Percentage of the requests served within a certain time (ms)
50% 77
66% 83
75% 88
80% 91
90% 105
95% 123
98% 148
99% 187
100% 42048 (longest request)
Как видно, местами процентов на 40% быстрее. Что интересно, что и скорость отдачи контента сервером увеличилась (см. transfer rate). Как мне кажется, это хороший показатель.
PS\2 в момент запуска php7 столкнулся со следующей ошибкой компонента:
Лечится более четким указанием определяемого значения переменной через {}:
// \bitrix\components\bitrix\blog.blog\component.php
global ${$arParams["FILTER_NAME"]};
$arFilter = ${$arParams["FILTER_NAME"]}; // вот так мы явно указываем имя переменной
if(!is_array($arFilter))
$arFilter = array();
PS Выходит очень круто, что просто обновляя версию php, получаем прирост! Очень радует, что битрикс понимает важность перехода на php7, и что уже даже что-то работает
2/ Имеем еще одну защиту нашего апатча от DDoS-атак.
Интересно было бы, если кто-то еще поделился своим опытом использования модуля, в принципе, при наличии прямых рук легко прикручивается к апатчу на bitrix VM.
Либо может еще есть удобные какие-то способы у вас.
[для врезки вправо]
На последок для выявления перегруза слотов апатча, команды через SSH:
ddos в идеале отлавливать до хостера... в случае похуже – на хостере... в еще более худшем случае – до nginx/apache... Но отлавливать на апаче – это, извините, стыд... Хотя, если атака слабенькая, то пост имеет место быть.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».