Поговорим о ситуациях, когда hook_node_insert, hook_node_update гибки не на столько хорошо, и нужны альтернативные способы выполнения кода после полного завершения транзакций или даже после отправки ответа браузеру.
Проблема
Стандартные хуки hook_node_insert / hook_node_update вызываются внутри той же транзакции, что и само сохранение узла. Это значит:
- Если внутри этих хуков вы сохраняете другую сущность (например, комментарий, термин таксономии, пользователя), изменения могут быть ещё не зафиксированы до окончания всего вызова
node_save(). - Другие модули, реализующие
hook_entity_update()для этих сущностей, могут не увидеть обновлённый узел (например, если они пытаются прочитать его свежие данные черезnode_load()внутри своей логики). - В случае отката транзакции (исключения) весь код из хуков тоже будет откачен.
Решения
Использовать hook_node_update_index()
Этот хук вызывается не сразу после сохранения, а во время работы cron при индексации узла поисковой системой. Он идеально подходит для фоновых задач, которые:
- не требуют мгновенного выполнения;
- должны видеть полностью сохранённый узел (включая поля и связанные данные).
|
1 2 3 4 5 6 7 |
function mymodule_node_update_index($node) { // Добавляем в поисковый индекс текст из связанной сущности. if ($node->type == 'article') { $extra = mymodule_get_extra_text($node); search_preprocess($extra); } } |
Зарегистрировать shutdown‑функцию
Эта функция выполняется после того, как PHP завершил обработку запроса (но до того, как соединение с БД окончательно закроется). Она гарантирует, что:
- транзакция уже зафиксирована;
- можно безопасно отправлять почту, писать в лог, вызывать внешние API без риска нарушить сохранение узла.
|
1 2 3 4 5 6 7 8 9 10 |
function mymodule_node_update($node) { drupal_register_shutdown_function('mymodule_after_save', $node->nid); } function mymodule_after_save($nid) { // Здесь node уже точно сохранён. $node = node_load($nid, NULL, TRUE); // принудительно сбросим кэш. // Отправляем письмо, вызываем API и т.д. ... } |
Есть нюанс в том, что shutdown‑функция не должна полагаться на состояние глобальных переменных, которые могли быть уничтожены. Лучше передавать явные примитивы (nid, uid, timestamp).
Использовать очередь (Queue API) для отложенной обработки
Самый надёжный способ для тяжёлых или долгих задач – поместить их в очередь:
|
1 2 3 4 |
function mymodule_node_update($node) { $queue = DrupalQueue::get('mymodule_post_save'); $queue->createItem(['nid' => $node->nid, 'changed' => REQUEST_TIME]); } |
Затем в крон‑обработчике:
|
1 2 3 4 5 6 7 |
function mymodule_cron() { $queue = DrupalQueue::get('mymodule_post_save'); while ($item = $queue->claimItem()) { mymodule_process_post_save($item->data); $queue->deleteItem($item); } } |
Изменить порядок вызова хуков
Если вам нужно, чтобы ваш модуль реагировал на сохранение после того, как это сделали другие модули, можно изменить приоритет:
|
1 2 3 4 5 6 7 8 |
function mymodule_module_implements_alter(&$implementations, $hook) { if ($hook == 'node_update') { // Перемещаем mymodule в конец списка. $group = $implementations['mymodule']; unset($implementations['mymodule']); $implementations['mymodule'] = $group; } } |
Это не решает проблему транзакций, а только влияет на последовательность вызова модулей.