MAX Autopost 1.11.8: почему воркер снова гонял уже отправленные посты • ИТ Решения, ИП Кривошеин Алексей Сергеевич

14 августа 2026 я выложил MAX Autopost 1.11.8. Это не новая фича очереди и не правка cron. Воркер снова прогонял уже отправленные записи: в логах крутились одни и те же шаги, картинка заливалась повторно, а в MAX новых сообщений не было.

Плагин: MAX Autopost (Free). Предыдущий разбор: 1.11.7 и ошибка «0/1 target».

Что было видно в логах

Каждые несколько минут повторялись одни и те же шаги по уже отправленным постам:

send_mode (часто title_only)
send_payload
send_attachments

Картинка уходила на upload заново. Статус записи оставался sent. Очередь в админке выглядела пустой. Создавалось ощущение, что «старые записи сами публикуются».

Публиковались не они. Воркер снова вызывал send() для постов, которые в очередь уже не входили. Dedupe по _krv_max_sent_hash в MAX ничего не отправлял, но upload и debug-логи успевали отработать. На площадках, где системный cron бьёт wp-cron.php раз в 5 минут, цикл виден с таким же шагом.

Почему это важно

В MAX дублей нет, сайт «как будто» в порядке. Цена другая: лишний трафик на CDN при каждом тике, засорённые логи и постоянная нагрузка на PHP, даже когда слать нечего. Если на главной висят закреплённые записи с картинками, воркер гоняет именно их.

Что на самом деле ломалось

process_queue() строил WP_Query без ignore_sticky_posts. Когда в очереди никого нет, WordPress видит такой запрос как «домашний» (is_home = 1) и подмешивает в результат все закреплённые записи. Sticky попадают в выборку уже после SQL, поэтому фильтр _krv_max_status = queued их не отсекает.

Дальше по цепочке:

Воркер получает sticky-посты, хотя статуса queued у них нет.
Вызывается send().
Upload картинки шёл до проверки _krv_max_sent_hash.
Hash совпадал, dedupe отрабатывал, в MAX ничего не уходило.
В логах оставались send_mode, send_payload, send_attachments и повторный upload.

Проблема не в cron, не в cutoff и не в install-stamp. Классический подводный камень WP_Query без явного ignore_sticky_posts. Это прямо описано в документации WP_Query: по умолчанию sticky не игнорируются.

Что я поправил в 1.11.8

1. Query больше не берёт sticky

В process_queue() я добавил флаг ignore_sticky_posts => true. Пустая очередь остаётся пустой, даже если на сайте есть закреплённые записи.

$q = new WP_Query([
    'post_type'           => self::supported_post_types(),
    'post_status'         => 'publish',
    'posts_per_page'      => self::BATCH_LIMIT,
    'ignore_sticky_posts' => true,
    'meta_query'          => [
        ['key' => '_krv_max_status', 'value' => 'queued'],
        // cutoff и install stamp без изменений
    ],
]);

2. Перед send() ещё раз проверяю статус

Даже если в выборку когда-то попадёт чужой пост, send() не вызовется. Если _krv_max_status не равен queued, воркер делает continue. При включённой отладке в логах будет шаг skip_not_queued.

$qstatus = (string) get_post_meta($post_id, '_krv_max_status', true);
if ($qstatus !== 'queued') {
    // debug: skip_not_queued, status=...
    continue;
}
$res = self::send($post_id);

3. Dedupe до upload картинки

Проверку _krv_max_sent_hash я перенёс выше загрузки изображения. При совпадении hash плагин сразу возвращает success («Уже отправлено ранее»), без upload и без debug-шагов send_mode / send_payload / send_attachments. Если отладка включена, остаётся короткий dedupe_skip.

4. Жирный текст в подписи

В поле «Текст после записи» я разрешил <b> и <strong>, в том числе внутри ссылки <a>. Раньше whitelist оставлял только a и br.

Очередь, retry, multi-chat и режим title_only по поведению не менялись. Новые публикации уходят как раньше.

Что сделать вам

Обновите плагин до 1.11.8. С включённым GitHub updater релиз подтянется сам. Либо скачайте ZIP с GitHub Releases.
Если воркер сейчас крутит старые sticky, выключите и включите его на вкладке «Очередь», либо дождитесь следующего тика: после обновления петля останавливается сама.
Мусор от старых циклов уберите кнопкой «Очистить логи».

После любого обновления MAX Autopost по-прежнему выключает автоворкер и блокирует старую очередь. Это защита от массовой рассылки, не регресс 1.11.8. Проверьте настройки и нажмите «Отправить тест», затем включите воркер, если автоотправка нужна.

SHA-256 архива релиза: 63666a173ca9367675603ae2b326ec8428fe9292852bda5965431f4b6ae40687.

Для тех, кто копает глубже

Симптом легко спутать с «сломанным cron» или с cutoff/stamp после апгрейда. Смотреть нужно не туда. WordPress «помогает» и подмешивает sticky в пустой query. Защита теперь двойная: query sticky не берёт, а статус, который уже не queued, до send() не доходит.

Полный список правок: CHANGELOG.md. Страница проекта: MAX Autopost на krivoshein.site.

Поддержка: aleksey@krivoshein.site · Issues на GitHub.

MAX Autopost (Free): автопостинг записей WordPress в мессенджер MAX. MIT.

Источники

Релиз MAX Autopost 1.11.8 Официальные notes от 14 августа 2026: sticky в process_queue, dedupe до upload, <b>/<strong> в подписи, SHA-256 архива. CHANGELOG.md Полный список изменений, включая пункт 1.11.8 про ignore_sticky_posts и sent_hash. Репозиторий MAX Autopost Исходный код process_queue() / send(), Issues и все релизы плагина. WP_Query, developer.wordpress.org Параметр ignore_sticky_posts: по умолчанию false, sticky могут попасть в выборку. MAX Autopost 1.11.7 на krivoshein.site Предыдущий релиз: channel-notify и ошибка теста «0/1 target».

Свежие записи

Рубрики