Kort svar: WordPress’ indbyggede wp-cron er ikke et ur – det er en gratist, der kun arbejder, når nogen besøger sitet. På stille sites betyder det forsinkede planlagte indlæg, udeblevne mails og abonnementsfornyelser i utide; på travle sites koster det ydelse ved tilfældige sidevisninger. Løsningen er klassisk og enkel: slå den besøgsdrevne udløser fra (
DISABLE_WP_CRON), og lad SERVERENS rigtige cron kalde jobkøen hvert femte minut. Fem minutters opsætning – og planlagte opgaver kører præcist, forudsigeligt og uden at lægge sig i vejen for kunderne.
Næsten al automatisering ender med at læne sig op ad planlagte opgaver: rapporter, synkroniseringer, oprydning, fornyelser. Og næsten alle WordPress-sites kører dem på et fundament, der er designet til noget andet. Denne guide forklarer, hvordan wp-cron FAKTISK virker, hvornår det bliver et reelt problem – og den fem-minutters opsætning, der gør planlagte opgaver til noget, du aldrig tænker på igen. (Står du med jobs, der allerede ER gået i stå, så start i fejlsøgningsguiden.)
Misforståelsen ligger i navnet: rigtig cron er serverens urværk, der udløser opgaver på klokkeslæt – wp-cron er derimod en TJEKLISTE, WordPress kigger på, hver gang en side indlæses: „er der jobs, hvis tid er overskredet? Så kør dem nu.“ Elegant, fordi det virker på al slags hosting uden opsætning – og skrøbeligt af præcis samme grund: ingen besøg, ingen jobs. Et planlagt indlæg klokken 8 udgives først, når dagens første besøgende kommer forbi 9.14. Og omvendt: på et travlt site er det en tilfældig kundes sidevisning, der får lov at trække oprydningsjobbet – med langsommere svar til netop hende. Caching-lag forværrer det stille: besøg, der serveres fra cache, vækker slet ikke WordPress, så selv pæne besøgstal kan dække over en jobkø, der kun tømmes sjældent.
For en lille blog er forsinkede jobs harmløse. Men listen over tidskritiske opgaver vokser med forretningen: abonnementsfornyelser (skal trækkes på dagen – jf. abonnementsguiden), ordre-webhooks og integrationskøer (regnskab og fragt venter på dem), planlagte kampagnepriser (udsalget skal starte OG stoppe til tiden), backup- og vedligeholdelsesjobs, og mails i kø. Tommelfingerreglen: hvis et job, der kører tre timer for sent, kan koste penge, tillid eller data – så er besøgsdrevet cron det forkerte fundament. Og de fleste opdager det baglæns: en kunde spørger, hvorfor fornyelsen ikke blev trukket, eller udsalgsprisen hængte til klokken ti. Regningen for de fem sparede opsætningsminutter kommer bare senere – og altid på et dårligt tidspunkt.
To greb, i denne rækkefølge: 1) Fortæl WordPress, at besøg ikke længere skal udløse jobs – tilføj define('DISABLE_WP_CRON', true); i wp-config.php. 2) Sæt serverens cron til at kalde jobkøen hvert femte minut – i hostingpanelet (på Hostious ligger cron-jobs som et menupunkt) eller i crontab: enten et kald til wp-cron.php?doing_wp_cron eller – pænest – WP-CLI-kommandoen wp cron event run --due-now, som kører køen uden om webserveren. Fem minutter er standardintervallet: tæt nok til alt normalt, sjældent nok til aldrig at belaste. Det er hele opsætningen – planlagte indlæg udgives på sekundet, køer tømmes i rytme, og ingen kunde trækker læsset. Har du flere sites, så gør det til en del af standardopsætningen: det er præcis den slags usynlige kvalitet, der adskiller professionel drift.
To situationer kræver et ekstra lag. Store jobkøer: WooCommerce og mange plugins kører deres opgaver gennem Action Scheduler (se status under Værktøjer → Planlægning af handlinger) – hober ventende handlinger sig op i tusindvis, er det tegn på, at cron-fundamentet halter, eller at et enkelt job fejler i løkke; med server-cron på plads tømmes køen støt. Rigtig tunge opgaver (eksporter, billedbehandling, store synkroniseringer): kør dem som selvstændige WP-CLI-kommandoer i deres EGET cron-job på skæve tidspunkter (kl. 03), så de hverken slås med hinanden eller med dagens drift – og giv langkørende jobs en simpel lås, så to kørsler aldrig overlapper. Mønstret er det samme som i resten af hubben: forudsigelighed slår held.
Planlagte opgaver fejler stille – så giv dem en stemme: tjek efter opsætningen med wp cron event list, at næste-kørsel-tiderne rykker sig som forventet, og sæt derefter én varig kontrol op – fx et lille dagligt job, der melder „jeg kørte“ til en overvågningstjeneste (dead man’s switch: alarmen går, når beskeden UDEBLIVER – præcis den måde, cron-død opdages på). Kig også efter symptomer i hverdagen: planlagte indlæg med status „udeblevet“, mails der klumper sig i bundter, integrationskøer der kun rører sig i åbningstiden. Hele overvågningsdisciplinen – for cron SÅVEL som flows – er samlet i overvågningsguiden; pointen her er blot: et urværk, ingen hører tikke, skal have en klokke, der ringer, når det står stille.
Nej – DISABLE_WP_CRON slukker kun den BESØGSDREVNE udløser. Jobsene ligger urørt i køen og køres af server-cronen i stedet. Farligt er kun at slukke uden at sætte server-cron op.
Hvert femte minut er standarden: tæt nok til planlagte indlæg, mails og fornyelser – og så let en belastning, at den ikke kan mærkes. Tidskritiske specialbehov kan få eget job med eget interval.
Typisk fordi cron-fundamentet er besøgsdrevet på et stille eller hårdt cachet site – eller fordi ét job fejler igen og igen. Sæt server-cron op, og undersøg derefter fejlene i køens log.
