Ви ставите будильник на восьму ранку, у понеділок у вас виходить важливий допис. Ви підготували його за вихідні, прописали розклад в адмінці WordPress і лягли спати спокійно. Вівторок, ви відкриваєте сайт, нічого. В адмінці навпроти заголовка світиться: «Публікацію прострочено».

Знайомо? Лише за останній рік у російськомовному сегменті форумів підтримки WordPress цю проблему обговорювали понад триста разів. І річ не у вашій адмінці, не в хостингу і не в плагінах, річ в архітектурній особливості самого WordPress.

Нижче три способи закрити питання раз і назавжди, від найшвидшого до найнадійнішого. Без cron-заклинань, без сліпого редагування wp-config.php і без пози «я просто публікуватиму вручну».

💡 Швидкий огляд:

• Встановити Missed Schedule Post Publisher, автоматична публікація прострочених дописів, дві хвилини на встановлення
• Замінити WP-Cron на серверний cron, радикальне рішення, не залежить від відвідуваності
• Встановити WP Crontrol для ручного контролю, показує всі cron-події, дозволяє запустити будь-яку вручну

Чому WordPress пропускає заплановані публікації

WordPress не використовує справжній системний cron. Натомість він покладається на механізм WP-Cron, псевдо-cron, який спрацьовує не за таймером сервера, а за фактом заходу відвідувача на сайт.

Працює це так. Коли ви призначаєте публікацію на 09:00, WordPress записує задачу в базу даних. Але виконати її він зможе, тільки якщо близько 09:00 на сайт хтось зайде. Зайшов відвідувач, WordPress пробігся за списком задач і опублікував допис. Не зайшов, задача зависає мертвим вантажем, а ви бачите повідомлення «Публікацію прострочено».

Для сайтів із трафіком від 500-1000 відвідувачів на добу WP-Cron працює прийнятно: хтось майже напевно клікне в потрібний момент. Але якщо у вас молодий блог, нішевий проєкт або ви публікуєте дописи вночі (за вашим часовим поясом), WP-Cron підводить регулярно. Додайте сюди кешувальні плагіни: WP Rocket, W3 Total Cache або Cloudflare можуть віддавати закешовану сторінку, взагалі не смикаючи WordPress, і cron-задачі не запускаються годинами.

Саме тому помилка «Публікацію прострочено» є системною, а не випадковою. І лікується вона не переплануванням допису вручну, а одним із трьох підходів нижче.

Три способи закривають різні сценарії. Перший, встановлення легкого плагіна-автомата, вирішує проблему в абсолютної більшості користувачів за дві хвилини. Другий, перехід на серверний cron, дає інфраструктурну гарантію незалежно від трафіку. Третій, ручна панель контролю, стане в пригоді тим, хто хоче бачити кожну cron-задачу поіменно і запускати її вручну. Ви можете почати з першого, а пізніше додати третій для повного спокою.

Спосіб 1: плагін Missed Schedule Post Publisher, простий і надійний

Найшвидший спосіб закрити проблему, поставити спеціалізований плагін. Історично для цього використовували WP Missed Schedule, але його видалено з каталогу WordPress.org ще у 2017 році, а версія з GitHub містила бекдор. Навіть не думайте його ставити.

Актуальна заміна, Missed Schedule Post Publisher. Плагін з одним-єдиним призначенням: перевіряє, чи не зависла запланована публікація, і випускає її в момент виявлення.

Чим він відрізняється від мертвого попередника:

• Працює через WP-Cron і водночас через заходи відвідувачів, якщо WP-Cron вимкнено хостингом, плагін перемикається автоматично

• Налаштовуваний інтервал перевірки: 5, 10, 15, 20, 30 або 60 хвилин

• Нульовий вплив на продуктивність, один легкий запит до бази даних

• Сумісний з WP Rocket, W3 Total Cache і Cloudflare

• Не створює «воронку» зайвих подій cron, перевіряє тільки пропущені публікації

Встановлення стандартне: Plugins → Add New → пошук «Missed Schedule Post Publisher» → Install → Activate. Після активації зайдіть у Settings → Missed Schedule Post Publisher і виберіть інтервал перевірки. Для більшості сайтів 10-15 хвилин є оптимальним.

Плагін не потребує ручного контролю. Поставили, налаштували інтервал, і можете перевірити результат через добу: зайдіть у Posts → All Posts і переконайтеся, що позначка «Публікацію прострочено» зникла. Далі він працює сам, мовчки й безвідмовно.

Для порівняння: старий WP Missed Schedule (закритий у каталозі WordPress.org з 2017 року, версія з GitHub містила бекдор) виглядав в адмінці ось так. Якщо ви раптом бачите цей плагін у себе в списку встановлених, видаліть негайно і замініть на Missed Schedule Post Publisher.

Спосіб 2: серверний cron замість WP-Cron, радикальне рішення

Спосіб глибший технічно, але дає стовідсоткову надійність: ви вимикаєте WP-Cron і вішаєте виклик wp-cron.php на системний cron сервера.

Системний cron запускається за розкладом операційної системи, незалежно від відвідуваності сайту. Задали інтервал у 5 хвилин, задача виконається рівно через 5 хвилин, навіть якщо на сайті нуль відвідувачів.

Що потрібно зробити:

• Відкрийте wp-config.php і додайте рядок до /* That's all, stop editing! */:

1
define('DISABLE_WP_CRON', true);

Це забороняє WordPress запускати cron-задачі при заході відвідувачів. Самі задачі нікуди не зникають, вони залишаються в базі й чекають виклику ззовні.

• У панелі хостингу знайдіть розділ «Cron-задачі» (cPanel → Cron Jobs, ISPmanager → Планувальник, або аналогічний). Створіть задачу з інтервалом 5-10 хвилин і командою:

1
wget -q -O - https://ваш-сайт.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Якщо сервер підтримує PHP CLI, альтернативний варіант, швидший і без навантаження на вебсервер:

1
php /home/username/public_html/wp-cron.php

• Збережіть задачу. Через 10 хвилин перевірте логи cron, якщо помилок немає, система працює.

Бонус: вимкнення WP-Cron через DISABLE_WP_CRON прибирає паразитну затримку під час завантаження сторінок для відвідувачів. WordPress більше не смикає cron-задачі під час звичайного перегляду, сторінки відкриваються трохи швидше.

Мінус у цього способу один: доступ до налаштувань cron є не на всіх хостингах. Дешевий shared-хостинг іноді блокує створення cron-задач. У цьому випадку повертайтеся до способу 1, Missed Schedule Post Publisher спроєктований саме під такі обмеження і працює без системного cron.

Спосіб 3: ручна перевірка через WP Crontrol, повний контроль

Третій спосіб, для тих, хто хоче бачити все, що відбувається під капотом WordPress. WP Crontrol — це диспетчер cron-подій прямо в адмінці. Він не публікує дописи сам, але показує, які задачі заплановані, коли вони мали спрацювати і що пішло не так.

Що дає WP Crontrol:

• Повний список усіх подій cron з хуком, аргументами і часом наступного запуску

• Можливість запустити будь-яку подію вручну, негайно, одним кліком

• Редагування і видалення подій cron

• Додавання нових подій і користувацьких розкладів

• Попередження, якщо система cron не працює (сервер не може підключитися сам до себе)

Після встановлення зайдіть у Tools → Cron Events. Ви побачите таблицю всіх задач. Якщо публікація «зависла», знайдіть подію з хуком publish_future_post, натисніть «Run Now», і допис піде в стрічку за секунду.

WP Crontrol особливо корисний для налагодження: ви бачите, чи не створив якийсь плагін сотню зайвих cron-подій (буває), чи не забилася черга задач, чи немає конфлікту між плагінами. Колонка «Next Run» показує, коли подія має спрацювати наступного разу, якщо дата в минулому, задача зависла. Колонка «Recurrence» підкаже, як часто подія повторюється, нестандартно часті повтори (щохвилини) майже завжди вказують на проблемний плагін.

Але сам по собі WP Crontrol помилку «Пропущеного розкладу» не запобігає, тільки допомагає діагностувати і вручну закрити наслідки. Після ручного запуску завислої публікації допис виходить миттєво, однак наступного разу ситуація повториться, якщо не закрити причину на рівні способу 1 або 2.

Найкраща зв'язка: спосіб 1 (плагін-автомат) + спосіб 3 (WP Crontrol для контролю). Автомат публікує пропущене, а WP Crontrol дозволяє одним поглядом переконатися, що черга cron-задач чиста і все працює штатно.

⁉️🤔 Часті питання

Чому WordPress не використовує нормальний cron, як усі нормальні системи?

Розробники WordPress свідомо обрали модель псевдо-cron, тому що вона не потребує налаштування на стороні сервера. Користувач ставить WordPress на будь-який хостинг, і планування публікацій працює «з коробки» без SSH і правки конфігів. Ціною цієї зручності стала ненадійність на сайтах з низьким трафіком. WP-Cron запускається при кожному запиті до сайту, і якщо запитів немає в потрібний момент, задача не виконується. Це архітектурний компроміс, і для критичних за часом публікацій його недостатньо.

Який спосіб обрати, якщо я не розбираюся в серверах?

Missed Schedule Post Publisher (спосіб 1). Встановлення, дві хвилини через адмінку, налаштування, вибір інтервалу з випадного списку. Жодного коду, жодного SSH, жодних правок wp-config.php. Плагін сам визначає, чи ввімкнено WP-Cron на сервері, і підлаштовується.

Чи може помилка бути пов'язана з часовим поясом WordPress?

Так, і перевірте це першим ділом. Зайдіть у Settings → General → Timezone і переконайтеся, що вибрано правильний міський часовий пояс, а не зміщення UTC вручну. Зміщення UTC+X не враховує літній/зимовий час, раз на пів року розклад «з'їжджає» на годину, і дописи публікуються не тоді, коли ви очікували.

Чи впливає кешування на пропуск публікацій?

Безпосередньо, так. Плагіни кешування (WP Rocket, W3 Total Cache, WP Super Cache) і CDN (Cloudflare) можуть віддавати відвідувачу готову HTML-сторінку, взагалі не запускаючи PHP-ядро WordPress. Якщо WP-Cron не викликається, задачі не виконуються. Missed Schedule Post Publisher (спосіб 1) обходить цю проблему, працюючи і через cron, і через заходи відвідувачів в обхід кешу. Серверний cron (спосіб 2) не залежить від кешу в принципі.

Що робити, якщо хостинг заблокував можливість створювати cron-задачі?

Використовуйте спосіб 1, Missed Schedule Post Publisher. Він проєктувався саме для таких ситуацій: працює через вбудований WP-Cron, а якщо той вимкнено, автоматично перемикається на перевірку при заходах відвідувачів. Ви не втрачаєте функціональність, просто перевірка відбувається трохи рідше (за фактом візиту, а не строго за таймером).

Що ставити прямо сьогодні

Проблема «Публікацію прострочено» не лікується ручним переплануванням — це як підфарбовувати тріщину на трубі. Потрібно або поставити плагін-автомат (дві хвилини, і забули), або перейти на серверний cron (трохи довше, і забули назавжди).

Якщо у вас типовий блог або сайт компанії на середньому хостингу, почніть із Missed Schedule Post Publisher. Інтервал 10 хвилин, п'ять кліків в адмінці, і питання закрите. Хочете гарантій на рівні інфраструктури, підніміть системний cron. Додайте WP Crontrol для контролю, і про пропущені публікації можна буде згадувати тільки в розмовах про те, «як воно було раніше».

Через добу після встановлення зайдіть в адмінку і перевірте найближчий запланований допис. Якщо він вийшов вчасно, система працює. Якщо ні, відкрийте WP Crontrol і подивіться, чи не висить задача publish_future_post без виконання — це вкаже на глибшу проблему з cron на сервері, яку вирішить спосіб 2.