Článek je ve WordPressu nastavený na ráno, ale po poledni stále svítí „Zmeškaný plán“. Jindy se newsletterová nebo zálohovací úloha spustí až po další návštěvě webu. Často nejde o chybný článek, nýbrž o způsob fungování WP-Cronu: WordPress při návštěvách kontroluje, zda má vykonat naplánované úlohy. U málo navštěvovaných magazínů může proto čas publikace kolísat. Řešením je nejprve diagnostika a až pak případný systémový plánovač.
Co WP-Cron dělá a co nedělá
WP-Cron je interní systém časovaných úloh WordPressu. Zajišťuje mimo jiné naplánované příspěvky, kontrolu aktualizací a úlohy některých pluginů. Není to proces běžící nepřetržitě jako systémový cron serveru. WordPress kontroluje splatné úlohy v souvislosti s požadavkem na web. Pokud má magazín návštěvy nepravidelně, plánované vydání nemusí nastat přesně v minutě, kterou jste zadali. Naopak u zatíženého webu se opakované spouštěcí kontroly podílejí na provozu, i když jednotlivá kontrola může být malá.
To neznamená, že každý web musí ihned přejít na serverový plánovač. Nejprve zkontrolujte, zda se úloha pouze zpozdila, nebo se nespustila vůbec. U webů s častými návštěvami a bez problémů může výchozí režim vyhovovat. Pokud publikujete na více magazínech v přesném kalendáři, smysl pravidelného spouštění roste. Obecný přehled dostupnosti a publikace najdete v článku monitoring WordPressu.
| Projev | Možná příčina | Co ověřit jako první |
|---|---|---|
| Článek vyšel po první pozdější návštěvě | Málo provozu na webu | Čas plánování a návštěvy kolem něj |
| Více úloh stojí současně | Selhává spouštění WP-Cronu | Site Health, loopback a chybový log |
| Úloha se opakuje nebo běží dlouho | Plugin, externí služba či timeout | Konkrétní hook a jeho trvání |
| Po změně hostingu přestaly vycházet články | Nedokončené cron nastavení | Plánovač hostingu a nastavení WordPressu |
První kontrola zmeškaného článku
Podívejte se na stav příspěvku, plánované datum a časovou zónu webu. REST API u příspěvku rozlišuje místní date a date_gmt; nesoulad mezi nimi může v automatizaci vyvolat jiné očekávání než má redaktor. Zkontrolujte, zda článek není koncept, zda se náhodou nevydal na jiné doméně a jestli už ho pouze neskrývá cache. U jednoho problematického příspěvku se vyhněte hromadnému přepisu celého kalendáře.
Potom prověřte Nástroje → Zdraví webu a dostupný protokol chyb. Máte-li WP-CLI, příkaz wp cron test pomůže prověřit spouštění a wp cron event list ukáže plánované události. Na sdíleném hostingu nemusí být WP-CLI dostupné; požádejte podporu o zjištění, zda interní požadavek na wp-cron.php neblokuje firewall, autentizace nebo nastavení serveru. Jedno „zmeškané“ vydání nemusí samo prokazovat konkrétní příčinu.
- Uložte URL webu, ID článku, zamýšlené datum a skutečně pozorovaný stav.
- Ověřte místní časové pásmo WordPressu, stav příspěvku a veřejnou stránku.
- Zkontrolujte další splatné cron události; jestli stojí také, jde spíše o obecný problém spouštění.
- Prohlédněte Site Health, chyby PHP a odpověď hostingu podle dostupných přístupů.
- Opravte příčinu a vyzkoušejte bezpečnou budoucí testovací publikaci na schváleném webu.
Kdy použít systémový plánovač
Pokud hosting nabízí cron úlohy, můžete pravidelně volat WordPressový wp-cron.php nezávisle na náhodné návštěvnosti. To je vhodné pro předvídatelnější vydávání na málo navštěvovaných webech. Nejprve zjistěte limity hostingu: nejkratší interval, počet úloh, způsob volání a spotřebu zdrojů. Nastavení pro jednu doménu nepřenášejte bezmyšlenkovitě na čtyřicet dalších. Čtyřicet úloh spuštěných ve stejnou minutu může vytvořit špičku, i když každý jednotlivý web má malou návštěvnost.
Oficiální dokumentace WordPressu popisuje postup: nastavte systémové spouštění a teprve když běží, zvažte vypnutí automatického spouštění při návštěvách pomocí define( 'DISABLE_WP_CRON', true ); v wp-config.php. Opačné pořadí může zastavit plánované úlohy. Změna konfiguračního souboru je technický zásah, který nejprve proveďte na jedné instalaci a ověřte ho. Na spravovaném hostingu může poskytovatel používat vlastní řešení; jeho návod má pro danou platformu přednost.
| Varianta | Výhoda | Omezení |
|---|---|---|
| Výchozí WP-Cron | Bez správy serverového plánovače | Čas závisí na návštěvách a dostupnosti spouštění |
| Systémový cron hostingu | Pravidelný pokus v zadaném intervalu | Vyžaduje nastavení a kontrolu chyb |
| Externí volání URL | Možnost mimo hosting | Závislost na externí službě a dostupnosti URL |
| Spravovaný plánovač poskytovatele | Jedna provozní odpovědnost | Vlastní limity a způsob diagnostiky |
Jak rozložit zátěž celé sítě
U více webů nejdříve sepište, které skutečně potřebují přesné vydání a jaké další úlohy spouštějí. Pak nastavte rozdílné minuty pro jednotlivé instalace, například po skupinách, a sledujte, zda se ve špičce nehromadí PHP procesy. Tato distribuce je provozní doporučení, ne univerzální časový interval. Příliš častý cron může zvýšit náklady; příliš řídký zpozdí články. Správný kompromis vyplývá z potřeby publikace a limitů hostingu.
Pokud poskytovatel nahlásí přetěžování, potřebujete rozlišit veřejnou návštěvnost, boty, editor, REST API a naplánované úlohy. Diagnostický postup nabízí článek WordPress přetěžuje hosting. Vlastní plánovač nepovažujte za jediné řešení; stejnou špičku mohou vyvolat zálohy nebo dávka automatických publikací.
Test po změně a provozní evidence
Po přechodu zkontrolujte nejen samotný příkaz, ale skutečný výsledek: budoucí článek se vydá ve zvoleném okně, periodické úlohy se nevrší a web zůstává dostupný. Uložte datum změny, doménu, interval, odpovědnou osobu a způsob návratu k předchozímu nastavení. Pokud plánovač přestane fungovat, musíte vědět, které instalace mají zakázané spouštění při návštěvách.
Pro články publikované přes API ještě ověřujte oba stavy: zda CMS zapsalo future a zda se následně změnil na publish. Popis bezpečného zápisu je v článku REST API pro redakci. Místní náhled naplánovaného článku není veřejný důkaz vydání.
Dva rozdílné incidenty: jeden zpožděný článek a stojící fronta
První situace: jeden příspěvek se vydal o čtvrt hodiny později, ale ostatní úlohy fungují. Zkontrolujte datum, časovou zónu, návštěvnost ve správném okně a možnou cache. Může jít o vlastnost výchozího spouštění na malém webu. Nepřenastavujte kvůli tomu bez rozmyslu všech 40 instalací.
Druhá situace: během několika hodin stojí naplánované příspěvky, zálohy i další úlohy a Site Health hlásí problém s loopback požadavky. To už ukazuje na společný mechanismus. Shromážděte chybové kódy a časy, zkontrolujte firewall či změny hostingu a ověřte, zda plánovač skutečně volá správnou doménu. Po opravě sledujte backlog. Náhlé spuštění dlouho odložených úloh může samo vytvořit novou špičku, takže průběh sledujte, ne pouze výsledek jednoho testu.
Jak přejít bez ztráty plánovaných úloh
Na jedné zkušební instalaci nejprve inventarizujte naplánované události a jejich přibližné frekvence. V hostingu vytvořte nový plánovač a vyžádejte si jeho log či potvrzení běhu. Otestujte přístup ke skriptu a jednu neškodnou splatnou úlohu. Až poté změňte WordPress konfiguraci tak, aby se cron nespouštěl při návštěvě. Po několika intervalech ověřte plánovaný článek a chování dalších pluginů. Pokud něco nefunguje, vraťte konfiguraci a pokračujte v diagnostice; nenechávejte účet se zakázanými návštěvními triggery a nefunkčním systémovým plánovačem.
U sdíleného hostingu může plánovač volat webovou URL, PHP binárku nebo jiný podporovaný postup. Příkazy z cizího serveru nekopírujte doslova: liší se cesty, verze PHP i přístupové restrikce. Pokud používáte externí službu, zvažte, co se stane při výpadku či změně domény. Odpovědnost za dohled nad plánovačem musí být stejně jasná jako odpovědnost za publikaci článků.
| Kontrola | Úspěšný výsledek | Při neúspěchu |
|---|---|---|
| Plánovač hostingu | Pravidelný běh bez chyby | Prověřit příkaz, cestu, blokování |
| Fronta WordPressu | Splatné úlohy nezůstávají viset | Prověřit konkrétní hook a log |
| Testovací článek | Veřejná URL ve správném čase | Porovnat datum, GMT a cache |
| Serverová zátěž | Bez nové špičky při souběhu | Rozložit časy a proměřit úlohy |
Časté otázky
Je WP-Cron vadný, když se článek opozdí?
Ne nutně. Výchozí mechanismus není nepřetržitý časovač; při nízké návštěvnosti může úlohu spustit až pozdější návštěva. Zkontrolujte i časové pásmo a stav článku.
Stačí přidat systémový cron a nic dalšího neměnit?
Může fungovat souběžně s výchozím spouštěním, ale má smysl posoudit zbytečné spouštěcí kontroly a podle oficiálního postupu případně nastavit DISABLE_WP_CRON. Nejprve musí být nový plánovač ověřený.
Jaký interval je nejlepší?
Jedna univerzální hodnota není. Vyplývá z požadované přesnosti vydání, limitu hostingu a počtu instalací. U sítě webů časy rozložte.
Pomůže cron i při výpadku celého hostingu?
Ne. Když je nedostupný web nebo server, plánovač nemá kam spolehlivě volat. Sledujte dostupnost odděleně od stavu fronty úloh.
Jak poznám, že problém způsobuje konkrétní plugin?
Hledejte jeho hooky a chyby v logu, porovnejte čas spouštění s vytížením. Před vypnutím pluginu ověřte dopad na funkce webu a připravte návrat.
