Asetat herätyksen kahdeksaksi aamulla, koska tärkeä julkaisu menee ulos maanantaina. Valmistelit sen viikonloppuna, ajastit sen WordPressin hallintapaneelissa ja menit nukkumaan huoletta. Tiistai koittaa, avaat sivuston, eikä mitään näy. Hallintapaneelissa otsikon vieressä lukee: "Ajastus epäonnistui."

Kuulostaako tutulta? Pelkästään viime vuonna venäjänkielisillä WordPress-tukifoorumeilla tästä ongelmasta keskusteltiin yli kolmesataa kertaa. Vika ei ole hallintapaneelissasi, ei palveluntarjoajassasi eikä lisäosissasi. Kyse on WordPressin itsensä arkkitehtuurin erikoisuudesta.

Alla on kolme tapaa ratkaista tämä lopullisesti, nopeimmasta luotettavimpaan. Ei cron-loitsuja, ei sokeita muokkauksia wp-config.php-tiedostoon eikä "julkaisen sitten käsin" -ajattelua.

💡 Nopea yleiskatsaus:

• Asenna Missed Schedule Post Publisher ajastettujen julkaisujen automaattiseen julkaisuun (kaksi minuuttia käyttöönottoon)
• Korvaa WP-Cron palvelimen cronilla, niin saat liikenteestä riippumattoman, perusteellisen ratkaisun
• Asenna WP Crontrol manuaalista valvontaa varten (näyttää kaikki cron-tapahtumat ja antaa ajaa ne käsin)

Miksi WordPress ei julkaise ajastettuja kirjoituksia

WordPress ei käytä oikeaa järjestelmän cronia. Sen sijaan se turvautuu mekanismiin nimeltä WP-Cron, pseudocroniin, joka laukeaa palvelimen ajastimen sijaan silloin, kun kävijä saapuu sivustolle.

Näin se toimii. Kun ajastat kirjoituksen kello 09:00, WordPress kirjoittaa tehtävän tietokantaan. Mutta se voi suorittaa tehtävän vain, jos joku vierailee sivustolla noin kello 09:00. Kävijä saapuu, WordPress käy läpi tehtävälistan ja julkaisee kirjoituksen. Jos kävijää ei tule, tehtävä roikkuu, ja sinä näet viestin "Ajastus epäonnistui."

Sivustoilla, joilla on 500-1000 päivittäistä kävijää, WP-Cron toimii hyväksyttävästi: joku lähes varmasti klikkaa oikealla hetkellä. Mutta jos sinulla on nuori blogi, niche-projekti tai julkaiset kirjoituksia öisin (omalla aikavyöhykkeelläsi), WP-Cron pettää säännöllisesti. Lisää yhtälöön vielä välimuistilisäosat: WP Rocket, W3 Total Cache tai Cloudflare voivat tarjota välimuistitettuja sivuja käynnistämättä WordPressiä lainkaan, jolloin cron-tehtävät eivät suoritu tuntikausiin.

Siksi "Ajastus epäonnistui" -virhe on järjestelmällinen, ei satunnainen. Korjaus ei ole kirjoituksen uudelleenajastaminen käsin, vaan yksi alla olevista kolmesta lähestymistavasta.

Kolme menetelmää kattavat eri tilanteet. Ensimmäinen, kevyen automaattisen julkaisulisäosan asentaminen, ratkaisee ongelman valtaosalle käyttäjistä kahdessa minuutissa. Toinen, palvelimen croniin siirtyminen, tarjoaa infrastruktuuritason luotettavuuden liikenteestä riippumatta. Kolmas, manuaalinen hallintapaneeli, on hyödyllinen niille, jotka haluavat nähdä jokaisen cron-tehtävän nimeltä ja ajaa sen käsin. Voit aloittaa ensimmäisestä ja lisätä kolmannen myöhemmin täyden mielenrauhan saavuttamiseksi.

Tapa 1: Missed Schedule Post Publisher -lisäosa, yksinkertainen ja luotettava

Nopein tapa hoitaa tämä ongelma on asentaa erikoistunut lisäosa. Aiemmin käytettiin WP Missed Schedulea, mutta se poistettiin WordPress.org-hakemistosta jo vuonna 2017, ja GitHub-versio sisälsi takaoven. Älä asenna sitä missään olosuhteissa.

Nykyinen korvaaja on Missed Schedule Post Publisher. Tällä lisäosalla on yksi tehtävä: tarkistaa, onko ajastettu kirjoitus jumissa, ja julkaista se heti, kun se havaitaan.

Miten se eroaa lakkautetusta edeltäjästään:

• Toimii WP-Cronin kautta ja samanaikaisesti kävijäosumien kautta; jos palveluntarjoaja poistaa WP-Cronin käytöstä, lisäosa vaihtaa automaattisesti

• Säädettävä tarkistusväli: 5, 10, 15, 20, 30 tai 60 minuuttia

• Ei lainkaan suorituskykyvaikutusta (yksi kevyt tietokantakysely)

• Yhteensopiva WP Rocketin, W3 Total Cachen ja Cloudflaren kanssa

• Ei luo ylimääräisten cron-tapahtumien tulvaa; se tarkistaa vain julkaisematta jääneet

Asennus on tavanomainen: Lisäosat → Lisää uusi → hae "Missed Schedule Post Publisher" → Asenna → Ota käyttöön. Aktivoinnin jälkeen mene kohtaan Asetukset → Missed Schedule Post Publisher ja valitse tarkistusväli. Useimmille sivustoille 10-15 minuuttia on optimaalinen.

Lisäosa ei vaadi manuaalista valvontaa. Asenna se, aseta väli ja tarkista tulos päivän kuluttua: mene kohtaan Artikkelit → Kaikki artikkelit ja varmista, että "Ajastus epäonnistui" -merkintä on poissa. Sen jälkeen se toimii hiljaisesti ja luotettavasti.

Vertailun vuoksi, vanha WP Missed Schedule (poistettiin WordPress.org-hakemistosta vuonna 2017, ja GitHub-versio sisälsi takaoven) näytti hallintapaneelissa tältä. Jos satut näkemään tämän lisäosan asennettujen listallasi, poista se välittömästi ja korvaa se Missed Schedule Post Publisherilla.

Tapa 2: palvelimen cron WP-Cronin sijaan, perusteellinen ratkaisu

Tämä menetelmä on teknisempi, mutta tarjoaa 100 prosentin luotettavuuden: otat WP-Cronin pois käytöstä ja liität wp-cron.php-kutsun palvelimen järjestelmän croniin.

Järjestelmän cron toimii käyttöjärjestelmän aikataulun mukaan, sivuston liikenteestä riippumatta. Jos asetat 5 minuutin välin, tehtävä suoritetaan tasan 5 minuutin kuluttua, vaikka sivustolla ei olisi yhtään kävijää.

Mitä sinun tulee tehdä:

• Avaa wp-config.php ja lisää seuraava rivi ennen riviä /* That's all, stop editing! */:

1
define('DISABLE_WP_CRON', true);

Tämä estää WordPressiä ajamasta cron-tehtäviä kävijäosumien yhteydessä. Itse tehtävät eivät katoa; ne jäävät tietokantaan ja odottavat ulkoista kutsua.

• Etsi palveluntarjoajasi hallintapaneelista "Cron-työt" -osio (cPanel → Cron-työt, ISPmanager → Ajastin tai vastaava). Luo tehtävä 5-10 minuutin välein ja tällä komennolla:

1
wget -q -O - https://your-site.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Jos palvelin tukee PHP CLI:tä, tässä on vaihtoehto, joka on nopeampi eikä kuormita verkkopalvelinta:

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

• Tallenna tehtävä. Tarkista 10 minuutin kuluttua cron-lokit; jos virheitä ei ole, järjestelmä toimii.

Bonus: WP-Cronin poistaminen käytöstä DISABLE_WP_CRON-määrityksellä poistaa loishävikin sivulatauksilta kävijöiden osalta. WordPress ei enää käynnistä cron-tehtäviä normaalin selailun aikana, joten sivut avautuvat hieman nopeammin.

Tällä menetelmällä on yksi haittapuoli: cron-asetuksiin ei ole pääsyä kaikilla palveluntarjoajilla. Halvat jaetut palveluntarjoajat estävät joskus cron-tehtävien luomisen. Siinä tapauksessa palaa tapaan 1; Missed Schedule Post Publisher suunniteltiin juuri tällaisia rajoituksia varten ja toimii ilman järjestelmän cronia.

Tapa 3: manuaalinen tarkastus WP Crontrolilla, täysi hallinta

Kolmas tapa on niille, jotka haluavat nähdä kaiken, mitä konepellin alla tapahtuu. WP Crontrol on cron-tapahtumien hallintatyökalu suoraan hallintapaneelissa. Se ei julkaise kirjoituksia itse, mutta näyttää, mitkä tehtävät on ajastettu, milloin niiden olisi pitänyt laueta ja mikä meni pieleen.

Mitä WP Crontrol tarjoaa:

• Täydellinen lista kaikista cron-tapahtumista, jossa näkyy koukku, argumentit ja seuraava suoritusaika

• Mahdollisuus ajaa mikä tahansa tapahtuma välittömästi yhdellä klikkauksella

• Cron-tapahtumien muokkaus ja poistaminen

• Uusien tapahtumien ja mukautettujen aikataulujen lisääminen

• Varoitus, jos cron-järjestelmä ei toimi (palvelin ei saa yhteyttä itseensä)

Asennuksen jälkeen mene kohtaan Työkalut → Cron-tapahtumat. Näet taulukon kaikista tehtävistä. Jos kirjoitus on "jumissa", etsi tapahtuma, jonka koukku on publish_future_post, klikkaa "Suorita nyt", ja kirjoitus ilmestyy syötteeseen sekunnissa.

WP Crontrol on erityisen hyödyllinen vianetsinnässä: näet, onko jokin lisäosa luonut satoja ylimääräisiä cron-tapahtumia (näin käy), onko tehtäväjono tukossa vai onko lisäosien välillä ristiriita. "Seuraava suoritus" -sarake näyttää, milloin tapahtuman pitäisi laueta seuraavaksi; jos päivämäärä on menneisyydessä, tehtävä on jumissa. "Toistuvuus"-sarake kertoo, kuinka usein tapahtuma toistuu; epätavallisen tiheät toistot (joka minuutti) viittaavat lähes aina ongelmalliseen lisäosaan.

WP Crontrol ei kuitenkaan yksinään estä "Ajastus epäonnistui" -virhettä; se auttaa vain diagnosoimaan ja korjaamaan seuraukset käsin. Kun ajat jumiutuneen julkaisun käsin, kirjoitus menee ulos välittömästi, mutta tilanne toistuu seuraavalla kerralla, ellet puutu syyhyn tavan 1 tai 2 tasolla.

Paras yhdistelmä: tapa 1 (automaattinen julkaisulisäosa) + tapa 3 (WP Crontrol valvontaan). Automaattinen julkaisija hoitaa ajastamatta jääneet kirjoitukset, ja WP Crontrolilla voit yhdellä silmäyksellä varmistaa, että cron-jono on puhdas ja kaikki toimii normaalisti.

⁉️🤔 Usein kysytyt kysymykset

Miksi WordPress ei käytä normaalia cronia kuten kaikki muut normaalit järjestelmät?

WordPressin kehittäjät valitsivat tietoisesti pseudocron-mallin, koska se ei vaadi palvelinpuolen konfigurointia. Käyttäjä asentaa WordPressin mille tahansa palveluntarjoajalle, ja ajastettu julkaiseminen toimii suoraan ilman SSH:ta tai konfiguraatiotiedostojen muokkausta. Tämän mukavuuden hinta on epäluotettavuus vähäliikenteisillä sivustoilla. WP-Cron suoritetaan jokaisella sivustopyynnöllä, ja jos pyyntöjä ei tule oikealla hetkellä, tehtävä ei suoritu. Tämä on arkkitehtoninen kompromissi, eikä se riitä aikakriittisille julkaisuille.

Mikä tapa minun kannattaa valita, jos en ymmärrä palvelimista?

Missed Schedule Post Publisher (tapa 1). Asennus kestää kaksi minuuttia hallintapaneelin kautta; konfigurointi tarkoittaa välin valitsemista pudotusvalikosta. Ei koodia, ei SSH:ta, ei wp-config.php-muokkauksia. Lisäosa tunnistaa itse, onko WP-Cron käytössä palvelimella, ja mukautuu.

Voiko virhe liittyä WordPressin aikavyöhykkeeseen?

Kyllä, ja tarkista tämä ensin. Mene kohtaan Asetukset → Yleiset → Aikavyöhyke ja varmista, että olet valinnut oikean kaupungin aikavyöhykkeen manuaalisen UTC-poikkeaman sijaan. UTC+X-poikkeama ei huomioi kesäaikaa; kahdesti vuodessa aikataulu "ryömii" tunnilla, ja kirjoitukset julkaistaan odottamattomiin aikoihin.

Vaikuttaako välimuistitus ajastamatta jääneisiin kirjoituksiin?

Suoraan, kyllä. Välimuistilisäosat (WP Rocket, W3 Total Cache, WP Super Cache) ja CDN:t (Cloudflare) voivat tarjota kävijöille valmiin HTML-sivun käynnistämättä WordPressin PHP-ydintä lainkaan. Jos WP-Cronia ei kutsuta, tehtävät eivät suoritu. Missed Schedule Post Publisher (tapa 1) kiertää tämän ongelman toimimalla sekä cronin kautta että välimuistin ohittavien kävijäosumien kautta. Palvelimen croniin (tapa 2) välimuistitus ei vaikuta lainkaan.

Mitä teen, jos palveluntarjoajani estää cron-tehtävien luomisen?

Käytä tapaa 1: Missed Schedule Post Publisher. Se suunniteltiin juuri tähän tilanteeseen; se toimii sisäänrakennetun WP-Cronin kautta, ja jos se on poistettu käytöstä, se vaihtaa automaattisesti tarkistamaan kävijäosumien yhteydessä. Et menetä toiminnallisuutta; tarkistus tapahtuu vain hieman harvemmin (käyntien yhteydessä tiukan ajastimen sijaan).

Mitä asentaa tänään

"Ajastus epäonnistui" -ongelma ei korjaannu manuaalisella uudelleenajastuksella; se on kuin putken halkeaman maalaamista päälle. Tarvitset joko automaattisen julkaisulisäosan (kaksi minuuttia, sitten unohdat koko asian) tai palvelimen cronin (hieman kauemmin, sitten unohdat sen ikuisesti).

Jos sinulla on tyypillinen blogi tai yrityssivusto keskiverto palveluntarjoajalla, aloita Missed Schedule Post Publisherista. Aseta 10 minuutin väli, viisi klikkausta hallintapaneelissa, ja ongelma on hoidettu. Jos haluat infrastruktuuritason takeet, määritä järjestelmän cron. Lisää WP Crontrol valvontaan, niin muistat ajastamatta jääneet julkaisut vain keskusteluissa "miten asiat ennen olivat".

Päivä asennuksen jälkeen mene hallintapaneeliin ja tarkista lähin ajastettu kirjoitus. Jos se meni ulos ajallaan, järjestelmä toimii. Jos ei, avaa WP Crontrol ja katso, roikkuuko publish_future_post-tehtävä suorittamatta; se viittaa syvempään cron-ongelmaan palvelimella, jonka tapa 2 ratkaisee.