regex — Concrete5.7 Stacks — PHP Превышено максимальное время выполнения
У нас возникает странная проблема со стеками в Concrete5.7: мы начинаем собирать довольно много стеков (64 в настоящее время), и наш сервер начал выдавать ошибки сервера (PHP Fatal error: Maximum execution time of 30 seconds exceeded in /example/path/to/website/concrete/blocks/html/controller.php on line 89) при редактировании страниц, особенно при получении /ccm/system/panels/add?cID=2468&tab=stacks через XHR.
Я временно решил это, увеличив max_execution_time от 30 до 60 в php.ini, но это похоже на плохой обходной путь, который мне придется снова поднять после добавления большего количества контента в стеки.
Отслеживание в blocks/html/controller.php:89то есть в xml_highlight() функция; конкретно эта строка (увидеть код в контексте здесь):
$s = preg_replace(
"#<(.*)(\[)(.*)(\])>#isU",
"<\\1<font color=\"#800080\">\\2\\3\\4</font>>",
$s
);
Это кажется довольно простым выражением для меня; я что-то пропустил?
Мне также кажется, что я могу удалить все preg_replace звонки из xml_highlight() и проверить производительность, но я не уверен, какую функциональность я бы потерял при этом.
Для справки, из dashboard/system/environment/info:
# concrete5 Version
Core Version - 5.7.5.2
Version Installed - 5.7.5.2
Database Version - 20150731000000
Решение
Проблема с этим регулярным выражением состоит в том, что у него есть два экземпляра .* в этом, и s вариант в конце, который позволяет . соответствовать новым строкам.
Это означает, что после того, как он находит < он должен сканировать потенциально весь остальной текст в поисках [, а затем снова ищет ]>, U Параметр option означает, что сначала он попытается найти самые короткие совпадения, но будет продолжать попытки, пока не найдет совпадение или не исключит все возможности. И это будет делать для каждого < в документе.
Изменение регулярного выражения как Виктор предложил Я должен решить проблему, но я бы сделал еще один шаг и использовал квантификаторы притяжений:
"#<([^[]*+)(\[)([^]]*+)(\])>#i"Другие регулярные выражения в этой функции написаны так же плохо, но содержат не более одного .* каждый, поэтому они не пытаются сбить систему.
Другие решения
Других решений пока нет …