14 августа 2026 года я выложил на GitHub MAX Autopost 1.11.8. Новых функций в нём нет. Воркер снова прогонял уже отправленные записи: в логах крутились одни и те же шаги, картинка загружалась заново, а новых сообщений в MAX не появлялось.
MAX Autopost публикует записи WordPress в мессенджер MAX, подробнее о нём на странице проекта. Предыдущий выпуск я разбирал в заметке про 1.11.7 и ошибку «0/1 target».
Что было видно в логах
Каждые несколько минут по уже отправленным постам повторялись шаги send_mode, send_payload и send_attachments. Картинка снова уходила на загрузку, статус записи оставался sent, очередь в админке была пустой. Казалось, что старые записи публикуются сами.
На деле они не публиковались. Воркер вызывал send() для постов, которых в очереди уже не было. Проверка по _krv_max_sent_hash не пускала дубль в MAX, но загрузка картинки и отладочные записи успевали пройти. Если системный cron дёргает wp-cron.php раз в пять минут, цикл повторялся с тем же шагом.
Чем это мешало
Дублей в MAX не было, и снаружи сайт выглядел нормально. Но каждый проход давал лишний трафик на загрузку картинок, засорял логи и нагружал PHP, даже когда отправлять было нечего. Больше всего доставалось закреплённым записям с картинками.
Что ломалось на самом деле
process_queue() строил WP_Query без ignore_sticky_posts. Когда в очереди никого нет, WordPress считает такой запрос запросом главной страницы и подмешивает в результат все закреплённые записи. Это происходит уже после SQL, поэтому условие _krv_max_status = queued их не отсекает. В документации WP_Query сказано, что по умолчанию закреплённые записи не игнорируются.
Дальше по цепочке: воркер получал закреплённые посты без статуса queued и вызывал send(). Картинка загружалась до проверки хеша, хеш совпадал, в MAX ничего не уходило, а в логах оставался полный набор шагов. Cron, отсечка по дате и метка установки тут ни при чём.
Что я поправил
В process_queue() добавлен флаг ignore_sticky_posts. Пустая очередь теперь остаётся пустой, даже если на сайте есть закреплённые записи:
$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'],
],
]);
Перед send() статус проверяется ещё раз. Если он не queued, воркер пропускает запись, а при включённой отладке пишет шаг skip_not_queued:
$qstatus = (string) get_post_meta($post_id, '_krv_max_status', true);
if ($qstatus !== 'queued') {
continue;
}
$res = self::send($post_id);
Проверку хеша я перенёс до загрузки картинки. Если запись уже отправлялась, плагин сразу отвечает «Уже отправлено ранее», без загрузки и без лишних шагов в логе. В отладке остаётся короткий dedupe_skip.
И мелочь: в поле «Текст после записи» теперь можно использовать b и strong, в том числе внутри ссылки. Раньше там разрешались только a и br. Очередь, повторы, отправка в несколько чатов и режим title_only работают как раньше.
Что сделать вам
Обновите плагин до 1.11.8. С включённым обновлением через GitHub релиз приедет сам, или скачайте ZIP со страницы релиза. SHA-256 архива: 63666a173ca9367675603ae2b326ec8428fe9292852bda5965431f4b6ae40687.
Если воркер сейчас гоняет закреплённые записи, выключите и включите его на вкладке «Очередь» или дождитесь следующего прохода. Мусор от старых циклов уберите кнопкой «Очистить логи».
Как и раньше, после любого обновления MAX Autopost выключает автоворкер и блокирует старую очередь, чтобы не устроить массовую рассылку. Проверьте настройки, нажмите «Отправить тест» и включите воркер, если нужна автоотправка. Откуда взялась эта защита, рассказано в заметке про 1.11.4.
Ошибка выглядела как сломанный cron, а оказалась особенностью WP_Query, который подмешивает закреплённые записи в пустой запрос. Теперь защита двойная: запрос их не берёт, а запись без статуса queued до отправки не доходит. Вопросы присылайте на aleksey@krivoshein.site или в Issues на GitHub.
