Порядок вызова плагинов при обработке хука
Ситуация:
Два плагина (ExpWall и Page) регистрируют функции на один и тот же хук:
и
Как определить, в каком порядке будут вызываться обработчики хуков у каждого плагина (я полагаю, по алфавиту — ExpWall, потом Page)?
Как переопределить очередность вызова плагинов при обработке одного хука? Мне нужно, чтобы сначала отработал плагин Page, а потом ExpWall.
РЕШЕНО:
Метод Hook->AddHook() имеет 4-ым параметром int-значение — очередность обработки кука. Чем она выше — тем раньше отработает обработчик.
Многие плагины этот параметр игнорируют — он принимает значение по умолчанию 1 и тогда плагины вызываются по алфавиту.
Два плагина (ExpWall и Page) регистрируют функции на один и тот же хук:
$this->AddHook('template_main_menu_item', 'MenuMain', __CLASS__);
и
$this->AddHook('template_main_menu_item', 'Menu');
Как определить, в каком порядке будут вызываться обработчики хуков у каждого плагина (я полагаю, по алфавиту — ExpWall, потом Page)?
Как переопределить очередность вызова плагинов при обработке одного хука? Мне нужно, чтобы сначала отработал плагин Page, а потом ExpWall.
РЕШЕНО:
Метод Hook->AddHook() имеет 4-ым параметром int-значение — очередность обработки кука. Чем она выше — тем раньше отработает обработчик.
Многие плагины этот параметр игнорируют — он принимает значение по умолчанию 1 и тогда плагины вызываются по алфавиту.
18 комментариев
plugins.dat
Как изменить какой-то из параметров темы, не внося изменения в /template/skin//settings/config/config.php?
Сделал после загрузки конфигов dump конфига, но настройки темы в него не подгрузились.
Необходимо вносить изменения в конфиг шаблона(Config::Set()) после первого вызова модуля viewer.
/engine/modules/viewer/Viewer.class.php
Оно?
/engine/modules/viewer/Viewer.class.php
Загружаем конфиг, говорим НЕ ПЕРЕЗАПИСЫВАТЬ имеющийся конфиг полученным.
Все верно? Верно.
Идем дальше по цепочке вызовов…
… и приходим к
engine/lib/internal/ConfigSimple/Config.class.php
Идем в код ArrayEmerge (точнее в func_array_merge_assoc()
… и обнаружием удивительную вещь:
Массив arr1 перезаписывается ключами массива arr2, хотя это поведение НЕ ОЖИДАЕТСЯ.
Ясно же сказано — не перезаписывать конфиги? Ясно.
А данные херятся.
Где логика?
/config/config.php
Тут max_tree определен, допустим, как 7.
Этот конфиг загуржается с перезаписью (true) (перезаписываем пустой конфиг)
/config/config.local.php
При его загрузке стоит «НЕ ПЕРЕЗАПИСЫВАТЬ»
Тут max_tree определен как 10
… и значение успешно меняется на 10.
/templates/skin/synio/settings/config/config.php
При загрузке стоит опять «НЕ ПЕРЕЗАПИСЫВАТЬ»
Тут max_tree определен как 5
… значение в конфиге меняется на 5.
/engine/modules/viewer/Viewer.class.php
И, к слову, зачем такая сложная функция слияния массивов?
чем не угодил
php.net/manual/ru/function.array-replace-recursive.php
?
Мне несложно изменить конфиг конкретно шаблона Synio.
Но у меня автоматический деплой кода и вносить изменения в репозитории плагинов — те, которые могут быть заданы в основном конфиге приложения — я не хочу.
В идеале — консольный.
А если нужно «между», 2-м по сету, 3-м и т.п.?
Я просто добавил хуков и поправил плагины: template_main_menu_item_1, ...2 и т.д.
Да, это не решает проблему полностью, но я могу в локальном конфиге прописать:
Теперь плагин page отработает раньше, чем ExpWall
Правда если какой-то плагин решит повесить на один и тот же хук два обработчика — эта схема сломается, но я думаю, это нереальный случай.