WP-Cron kiváltása valódi szerveroldali cronnal WordPressben

Scheo · 2026-09-13 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Mi a WP-Cron, és miben különbözik a valódi crontól?

A WP-Cron a WordPress beépített ütemezője, és nem az órát figyeli, hanem a látogatásokat: amikor valaki megnyit egy oldalt, a WordPress megnézi, van-e esedékes feladat, és ha van, elindítja. A valódi, rendszerszintű cron ezzel szemben pontosan az óra szerint fut, attól függetlenül, hogy jár-e valaki az oldalon.

Hivatalosan igazolt: a WordPress fejlesztői dokumentációja (Plugin Handbook, Cron fejezet) leírja, hogy a WP-Cron minden oldalbetöltéskor átnézi az ütemezett feladatok listáját, és lefuttatja azokat, amelyeknek már eljött az ideje. A dokumentáció azt is kimondja, hogy egy 14:00-ra ütemezett feladat addig nem fut le, amíg 14:00 után nem jön egy oldalletöltés. A WP-Cron tehát nem ígér pontos időzítést, csak annyit, hogy a feladat valamikor az esedékesség után sorra kerül.

Ezen a mechanizmuson múlik egy csomó dolog, amire a legtöbb oldaltulajdonos nem is gondol: az időzített bejegyzések megjelenése, a frissítések keresése, a bővítményes biztonsági mentések, a WooCommerce háttérfolyamatai (Action Scheduler), a hírlevél-sorok feldolgozása, a lejárt tranziensek takarítása és a lomtár ürítése.

Hogyan lassítja a WP-Cron a látogatókat?

A látogató oldalkérése indítja el a háttérfeladatokat, amelyek ugyanazon a szerveren, ugyanazokból a PHP-folyamatokból és adatbázis-kapcsolatokból dolgoznak, amelyek a látogatókat is kiszolgálják. Forgalmas időszakban ez közvetlenül rontja a válaszidőt.

A valóság árnyaltabb annál, ahogy sokszor leírják. Hivatalosan igazolt: a WordPress alapból egy nem blokkoló, úgynevezett loopback HTTP-kérést küld a saját wp-cron.php fájljának, nagyon rövid időkorláttal, vagyis a kérést elindító látogatónak elvileg nem kell kivárnia, amíg a feladatok lefutnak. Ettől függetlenül:

• minden oldalletöltéskor lefut az esedékesség ellenőrzése, ami az ütemezési lista beolvasásával jár;
• a loopback kérés lefoglal egy újabb PHP-folyamatot, amely a feladatok ideje alatt nem szolgál ki látogatót;
• egy nehéz feladat (mentés tömörítése, képoptimalizálás, termékimport, hírlevél-köteg) CPU-t, memóriát és adatbázis-zárolásokat vesz el a közben érkező vásárlóktól;
• ha a szerveren nem működik a loopback, és be van kapcsolva az ALTERNATE_WP_CRON mód, a látogató egy átirányításon keresztül jut el az oldalra, és ezt a késést már közvetlenül érzi.

Saját tapasztalat: a „néha beszakad az admin, időnként 4-5 másodpercig tölt a kosár” típusú panaszok mögött gyakran nem egyetlen lassú lekérdezés áll. Ilyenkor az a gond, hogy csúcsidőben egyszerre több cron-feladat indul el, és elfogy a megosztott tárhely kevés PHP-munkafolyamata. Az ilyen lassulás szabálytalan, ezért nehéz tetten érni.

Mikor marad ki egy ütemezett bejegyzés vagy biztonsági mentés?

Akkor, amikor semmilyen PHP-futás nem indítja el a WP-Cront, vagy amikor a feladat félúton megszakad. A kisforgalmú és az erősen gyorsítótárazott oldalakon ez rendszeresen előfordul.

• Kevés látogató: az éjjel 2-re ütemezett mentés csak reggel 8-kor fut le, amikor megjön az első látogató.
• Teljes oldalas gyorsítótár: ha a szerveroldali cache vagy a CDN a WordPress betöltése nélkül adja ki az oldalt, akkor nem fut PHP, így a cron sem ellenőriz semmit.
• Időzített bejegyzés: „Missed schedule” (elmaradt időzítés) állapotba kerül, mert a megjelenés idején senki nem indított cron-futást, vagy a tárhely tűzfala blokkolta a loopback kérést.
• Megszakadó mentés: a loopback kérésben futó PHP beleütközik a webszerver időkorlátjába, és a nagyobb mentés félkészen marad.
• Blokkolt loopback: egy biztonsági bővítmény, a HTTP-hitelesítés vagy egy hibás SSL-tanúsítvány miatt a szerver nem éri el önmagát.

Hivatalosan igazolt: a WordPress Webhely állapota (Site Health) eszköze külön vizsgálja, hogy az ütemezett események időben lefutnak-e, és jelez, ha valamelyik késik vagy nem sikerült. Ha itt visszatérő figyelmeztetést látsz, az erős érv a kiváltás mellett.

Miért küldhet ki kétszer egy hírlevelet a WP-Cron?

Azért, mert a WP-Cron zárolása nem atomi. Egy átmeneti értékkel jelzi, hogy éppen fut, így ha egy feladat tovább tart a zárolási időnél, vagy két kérés szinte egyszerre érkezik, ugyanaz a köteg kétszer is elindulhat.

Hivatalosan igazolt (a WordPress forráskódja alapján): a futást egy doing_cron tranziens jelzi, és a zárolás alapértelmezett időkorlátja (WP_CRON_LOCK_TIMEOUT) 60 másodperc.

Szakmai feltételezés: a megkettőzött kiküldés jellemzően három helyzetben fordul elő: ha egy hírlevél-köteg feldolgozása tovább tart 60 másodpercnél, ha forgalmi csúcsban több párhuzamos kérés indítja a cront, vagy ha a szerveroldali cron mellett bekapcsolva maradt a WP-Cron is. A komolyabb hírlevél- és mentőbővítmények saját zárolást is használnak, ezért ez nem minden oldalon jön elő. Ha viszont egy vásárló kétszer kapja meg ugyanazt a levelet, a cron-beállításokat érdemes elsőként átnézni.

Hogyan kapcsold ki a WP-Cront a wp-config.php-ban?

A wp-config.php fájlba, a „That's all, stop editing!” megjegyzés fölé írd be ezt a sort: define( 'DISABLE_WP_CRON', true );. Ettől a WordPress nem indít cron-futást oldalbetöltéskor, a wp-cron.php közvetlen hívásra viszont továbbra is lefut.

1. Ments le egy példányt a wp-config.php fájlról FTP-n vagy a tárhely fájlkezelőjével.
2. Nézd meg, nincs-e már benne DISABLE_WP_CRON vagy ALTERNATE_WP_CRON sor, mert egyes tárhelyek és bővítmények előre beírják.
3. A konstanst a „stop editing” megjegyzés fölé tedd, vagyis a wp-settings.php betöltése elé. Ha később kerül be, nem érvényesül.
4. Mentés után rögtön állítsd be a szerveroldali cront, mert nélküle egyáltalán nem futnak az ütemezett feladatok.

Hivatalosan igazolt: a Plugin Handbook „Hooking WP-Cron Into the System Task Scheduler” szakasza pontosan ezt a sorrendet írja le: előbb a konstans, aztán a rendszer ütemezőjének bejegyzése.

Hogyan állítsd be a szerveroldali cront cPanelben és Pleskben?

Két bevált út van: a wp-cron.php meghívása HTTP-n keresztül (wget vagy curl), vagy az esedékes feladatok futtatása parancssorból, WP-CLI-vel. Ha a tárhelyed engedi, válaszd a WP-CLI-t, mert nem megy át a webszerveren, így nem ütközik HTTP-hitelesítésbe, gyorsítótárba vagy webes időkorlátba.

cPanel: wget vagy curl hívás

A cPanel Cron Jobs menüjében vegyél fel egy új bejegyzést, és a parancs mezőbe ezt írd, a saját domainedre cserélve:

wget -q -O - 'https://example.hu/wp-cron.php?doing_wp_cron' >/dev/null 2>&1

Ha nincs wget, curl-lel is megy: curl -s 'https://example.hu/wp-cron.php?doing_wp_cron' >/dev/null 2>&1. A sor végi átirányítás azért kell, hogy a cPanel ne küldjön e-mailt minden futás után.

cPanel: WP-CLI vagy közvetlen PHP-futtatás

Ha a tárhelyen elérhető a WP-CLI (ezt a szolgáltató dokumentációjában ellenőrizd), ez a parancs csak az esedékes eseményeket futtatja:

cd /home/felhasznalo/public_html && wp cron event run --due-now --quiet

Ha a cron környezetében nem található a wp parancs, add meg a teljes útvonalát, például /usr/local/bin/wp. Egyszerű, nem multisite telepítésnél WP-CLI nélkül is működik a közvetlen PHP-futtatás: /usr/local/bin/php /home/felhasznalo/public_html/wp-cron.php >/dev/null 2>&1. A PHP útvonala tárhelyenként más.

WooCommerce-nél hasznos tudni, hogy az Action Scheduler sorát WP-CLI-vel külön is lehet futtatni (wp action-scheduler run). Ez sok rendelésnél jól jöhet, a részleteket a WooCommerce fejlesztői dokumentációja írja le.

Plesk: Ütemezett feladatok

Pleskben a domain Scheduled Tasks (Ütemezett feladatok) menüjében háromféle feladatot hozhatsz létre: URL lekérése, PHP-szkript futtatása vagy parancs futtatása. URL-lekéréshez a https://example.hu/wp-cron.php?doing_wp_cron címet add meg. PHP-szkripthez a httpdocs/wp-cron.php útvonalat és a domainhez tartozó PHP-verziót válaszd. Parancshoz a fenti WP-CLI sort használd, a httpdocs könyvtárra igazítva. Az értesítést állítsd csak hibára, különben minden futás után kapsz egy levelet.

Többhelyes (multisite) telepítés

A wp cron event run --due-now alapból csak a fő webhelyen futtat. Multisite esetén minden alwebhelyre külön meg kell hívni, például így: wp site list --field=url | xargs -I % wp cron event run --due-now --url=%.

Milyen gyakran fusson a szerveroldali cron?

A legtöbb oldalon az 5 percenkénti futás (*/5 * * * *) jó kiindulópont. Forgalmas WooCommerce-boltnál 1-2 perc, egyszerű bemutatkozó oldalnál 10-15 perc is elég lehet. A gyakoriságot az dönti el, milyen gyorsan kell reagálnia a legérzékenyebb feladatodnak.

Hivatalosan igazolt: a WordPress legrövidebb beépített ütemezési intervalluma az óránkénti, de a bővítmények rövidebbet is regisztrálhatnak. A WooCommerce Action Scheduler például percenként próbálja feldolgozni a sorát.

Saját tapasztalat:

• Forgalmas WooCommerce, előfizetések, készletszinkron: 1-2 perc, hogy ne torlódjanak a rendelés utáni levelek és webhookok.
• Átlagos cégoldal időzített blogbejegyzésekkel: 5 perc, így a bejegyzés legfeljebb néhány percet késik.
• Ritkán változó bemutatkozó oldal napi mentéssel: 10-15 perc.

Ha néhány feladat sokáig fut, akadályozd meg, hogy a futások egymásra csússzanak. Ha a tárhelyeden elérhető a flock parancs, erre ez a legegyszerűbb: flock -n /tmp/wpcron-example.lock wp cron event run --due-now --path=/home/felhasznalo/public_html --quiet. Ha az előző futás még tart, az új egyszerűen kimarad. Egyes megosztott tárhelyek nem engednek percenkénti cront, ilyenkor a legkisebb megengedett értéket válaszd.

Hogyan ellenőrizd WP Crontrol bővítménnyel, hogy működik?

A WP Crontrol bővítmény listázza az összes ütemezett eseményt a következő futás idejével. Ha a kiváltás után egyik esedékes esemény sem ragad tartósan a múltban, a szerveroldali cron rendben dolgozik.

1. Telepítsd a WP Crontrolt, és nyisd meg az Eszközök menüben a cron események listáját.
2. Nézd meg, jelzi-e a bővítmény, hogy a DISABLE_WP_CRON be van kapcsolva. Ebből tudod, hogy a konstans tényleg érvényesül.
3. Ütemezz egy piszkozatot 10-15 perccel későbbre, és addig ne nyisd meg az oldalt. Ha a cron-intervallum letelte után megjelent, a rendszer működik.
4. Figyeld a lista tetejét: ha ott percekkel vagy órákkal korábbi esemény ragad, a szerveroldali cron nem fut, vagy hibára fut.
5. Nézd meg a Webhely állapota oldalt is, hogy nem jelez-e késő ütemezett eseményt.
6. Ha van WP-CLI, parancssorból is ellenőrizheted: wp cron event list --fields=hook,next_run_relative,recurrence.

Saját tapasztalat: a piszkozatos teszt mondja a legtöbbet, mert pontosan azt a folyamatot használja, amelyik élesben el szokott csúszni. Hibakereséskor a cron kimenetét a /dev/null helyett ideiglenesen irányítsd egy naplófájlba, mert különben a hibaüzenetek nyom nélkül eltűnnek.

Melyek a tipikus hibák a WP-Cron kiváltásakor?

A négy leggyakoribb: a kettős futás, a staging oldal kifelé dolgozó cronja, a HTTP-hitelesítésbe ütköző wget-hívás és a nyilvánosan hívható wp-cron.php. Mindegyik megelőzhető egy-két beállítással.

Kettős futás

Legtöbbször úgy jön létre, hogy a szerveroldali cron bekerül, a DISABLE_WP_CRON viszont kimarad, vagy rossz wp-config.php-ba kerül (például almappás telepítésnél). Gyakori az is, hogy a tárhely saját WordPress-kezelője már futtat cront, és mellé kerül egy második bejegyzés, vagy egyszerre van beállítva egy wget-es és egy WP-CLI-s sor. Több webszerveres, terheléselosztott környezetben a cron csak egyetlen gépen fusson. Mielőtt új bejegyzést veszel fel, nézd át a panel cron-listáját és a tárhely WordPress-eszközeit.

Jelszóval védett staging

A klónozott tesztoldal örökli az éles oldal összes ütemezett eseményét: hírlevél-sorokat, előfizetés-megújításokat, rendelési leveleket, külső szinkronokat. Saját tapasztalat: a megkettőzött kiküldések egy része valójában nem az éles oldalról, hanem egy elfelejtett stagingről megy ki. Stagingen ezért jellemzően az a jobb megoldás, ha a DISABLE_WP_CRON be van kapcsolva, és nincs mellette szerveroldali cron, vagy ha a levélküldés kifejezetten le van tiltva. Ha a stagingen mégis kell cron, a WP-CLI-s futtatás a jó út, mert azt a webes jelszóvédelem nem érinti.

HTTP-hitelesítés

Ha a könyvtárat .htaccess alapú (Basic Auth) jelszó védi, a wget 401-es választ kap, a cron pedig csendben nem csinál semmit, mert a kimenetet elnyeli a /dev/null. Ugyanez az oka annak, hogy a jelszóval védett oldalakon a beépített WP-Cron loopback kérése is gyakran elbukik. A megoldások ebben a sorrendben érdemesek: WP-CLI vagy közvetlen PHP-futtatás; ha csak URL-hívás lehetséges, a wp-cron.php kivétele a hitelesítés alól kizárólag a szerver saját IP-címére; végső esetben a wget --user=... --password=... kapcsolók. Ez utóbbinál a jelszó olvasható marad a cron-bejegyzésben, ezt mérlegeld.

A cron URL nyilvános elérhetősége

Hivatalosan igazolt (a WordPress forráskódja alapján): a DISABLE_WP_CRON csak az oldalbetöltéskori indítást kapcsolja ki, a wp-cron.php kívülről továbbra is meghívható.

Szakmai feltételezés: egy tetszőleges gyakorisággal hívható nyilvános végponttal bárki terhelheti a szervert. A zárolás miatt ez többnyire nem indít párhuzamos feladatokat, a PHP-folyamatokat viszont így is leköti. Ha WP-CLI-vel vagy közvetlen PHP-val futtatod a cront, a wp-cron.php webes elérését nyugodtan letilthatod a webszerver szintjén. Ha URL-hívást használsz, csak a saját szerver IP-címéről engedd. Arra is figyelj, hogy egyes biztonsági bővítmények és tárhelyek eleve blokkolják ezt a fájlt, és ilyenkor a wget-es megoldás hibaüzenet nélkül nem fog működni.

Kinek éri meg jobban: a forgalmas WooCommerce-boltnak vagy a kisforgalmú oldalnak?

Mindkettőnek, csak más okból: a forgalmas boltnál a válaszidőn, a kisforgalmú oldalnál a megbízhatóságon nyersz.

Saját tapasztalat: forgalmasabb WooCommerce-oldalakon a WP-Cron kiváltása az egyik legolcsóbb válaszidő-javítás. Nem kell hozzá új tárhely, kódátírás vagy bővítménycsere, csak egy konstans és egy cron-sor, és jó eséllyel kisimítja a csúcsidős, szabálytalan lassulásokat. Csodát azért ne várj tőle: ha a lassúságot lassú adatbázis-lekérdezések vagy túlterhelt admin-ajax hívások okozzák, azokon ez nem segít.

Szakmai feltételezés: kisforgalmú oldalon a WP-Cron alig lassít, viszont itt a legnagyobb a kimaradás esélye. Egy gyorsítótárazott, ritkán látogatott oldalon, ahol az admin felületet sem nyitja meg senki, napokig alig futhat cron. Ott tehát nem a sebesség, hanem az időben elkészülő mentés és a pontosan megjelenő bejegyzés miatt kell a valódi cron.

Mit ellenőrizz a kiváltás után?

Az alábbi lista végigviszi azokat a pontokat, amelyeken a beállítás a leggyakrabban elcsúszik.

• A DISABLE_WP_CRON a megfelelő wp-config.php-ban, a „stop editing” megjegyzés fölött van.
• Oldalanként pontosan egy cron-bejegyzés fut (a panelt és a tárhely WordPress-eszközeit is átnézted).
• A gyakoriság illik a legérzékenyebb feladathoz.
• A hosszú feladatoknál van átfedés elleni védelem.
• Az időzített tesztbejegyzés időben megjelent, a WP Crontrolban nincs beragadt, lejárt esemény.
• A Webhely állapota nem jelez késő ütemezett eseményt.
• A staging nem küld levelet, és nem futtat éles szinkront.
• A wp-cron.php webes elérése korlátozva van, ha nem URL-hívással futtatod.
• Egy hét múlva átnézed a mentések és a hírlevél-kiküldések naplóját.

Források és további olvasnivalók

• WordPress Developer Resources: Plugin Handbook, Cron fejezet (Hooking WP-Cron Into the System Task Scheduler)
• WordPress Advanced Administration Handbook: wp-config.php szerkesztése
• WP-CLI Commands dokumentáció: wp cron
• WooCommerce Developer Documentation: Action Scheduler
• WP Crontrol bővítmény leírása, WordPress.org bővítménytár
• cPanel dokumentáció: Cron Jobs
• Plesk dokumentáció: Scheduled Tasks