Как создать автоматическое наступление событий после публикации в WordPress

В этой статье мы рассмотрим, как автоматически запускать определённые действия сразу после публикации записи в WordPress. Такая задача часто встречается при необходимости интеграции с внешними сервисами, обновления кэша, отправки уведомлений и многого другого. Мы разберём низкочастотный, но практический сценарий, показывающий, как с помощью хуков WordPress можно создавать автоматизацию на основе момента публикации записи.

Почему важно реагировать именно на публикацию записи

WordPress предоставляет множество хуков, которые срабатывают при сохранении записи, обновлении или её публикации. Однако часто достаточно реагировать только на момент, когда запись становится публичной (статус становится publish). Это позволяет избежать лишних действий при черновиках или обновлениях без изменения статуса.

Например, если вы хотите отправить уведомление в чат или обновить кэш, нет смысла делать это при каждом сохранении записи. Логично запускать процесс только при первом переходе в статус «опубликовано».

Для решения этой задачи в WordPress существует хук transition_post_status, который позволяет отследить смену статуса записи и выполнить нужный код.

Как работает хук transition_post_status

Этот хук вызывается при любом изменении статуса записи. Ваша задача — проверить, что старый статус был не publish, а новый — publish. Это и будет моментом публикации.

Сигнатура функции выглядит так:

do_action( 'transition_post_status', $new_status, $old_status, $post );

Где $new_status и $old_status — новые и старые статусы записи, а $post — объект записи.

Пример: отправка уведомления после публикации записи

Рассмотрим пример, как при публикации записи отправлять уведомление в лог-файл. Такой способ полезен для отладки перед интеграцией с внешними API.

function wphelper_after_publish_notification( $new_status, $old_status, $post ) {
    if ( 'publish' === $new_status && 'publish' !== $old_status && 'post' === $post->post_type ) {
        $message = sprintf( "Запись '%s' (ID %d) только что опубликована.", $post->post_title, $post->ID );
        error_log( $message );
    }
}
add_action( 'transition_post_status', 'wphelper_after_publish_notification', 10, 3 );

Здесь мы проверяем, что статус сменился с любого, кроме publish на publish, и что это именно обычная запись (тип post), а не страница или другой тип записи.

В реальном проекте вместо error_log можно использовать отправку webhook, вызов API или запуск других задач.

Автоматическое обновление кэша после публикации

Часто после публикации записи требуется обновить кэш страниц или сбросить кеш-память CDN. Рассмотрим, как интегрировать такую логику.

Допустим, у вас есть функция wphelper_clear_cache(), которая очищает кеш сайта. Её можно вызвать из того же хука:

function wphelper_clear_cache_after_publish( $new_status, $old_status, $post ) {
    if ( 'publish' === $new_status && 'publish' !== $old_status ) {
        wphelper_clear_cache();
    }
}
add_action( 'transition_post_status', 'wphelper_clear_cache_after_publish', 20, 3 );

function wphelper_clear_cache() {
    // Пример: удаление опции с кешем
    delete_transient( 'wphelper_site_cache' );
    // Здесь можно добавить вызов API CDN или других систем
}

Такой подход позволяет централизованно управлять автоматическими процессами, которые должны происходить после публикации.

Использование плагинов для расширения автоматизации

Если вы не хотите писать код самостоятельно, можно использовать плагины, которые расширяют возможности хуков и автоматизации WordPress. Например:

• Clearfy Pro — позволяет гибко управлять оптимизацией и автоматическими процессами, включая очистку кэша и интеграцию с внешними сервисами. Подробнее о плагине — https://wpshop.ru/clearfy-pro/.
• WPCron Control — помогает управлять задачами WP-Cron, которые могут запускаться по расписанию и после событий.

Однако для вашей задачи срабатывание на transition_post_status — самое надёжное и точное решение.

Отладка и проверка работы кода

Чтобы убедиться, что ваш код срабатывает корректно, используйте несколько приёмов:

• Логирование через error_log или плагины для отладки, например Debug Bar.
• Тестирование на разных типах записей, чтобы не запускать процесс для страниц или кастомных типов, если это не нужно.
• Проверка условий для предотвращения повторных срабатываний при обновлении уже опубликованных записей.

Обязательно тестируйте на тестовом сайте перед внедрением на продакшен.

Дополнительные методы реагирования на публикацию

Помимо transition_post_status, есть и другие хуки, которые можно использовать:

• publish_post — срабатывает при публикации записи, но не позволяет отследить переход статуса.
• save_post — срабатывает при сохранении записи, требует дополнительной проверки статуса.

Однако именно transition_post_status предоставляет полный контроль и гибкость.