WordPress WP-Cron devre dışı bırakma ve sistem cron ayarı

wp-cron nedir ve sistem cron'u neden onun yerini alır

WP-Cron, WordPress içinde yerleşik olarak bulunan bir görev zamanlayıcıdır ve yalnızca bir kullanıcı bir sayfa talep ettiğinde çalışır. WordPress içinde hiçbir şey kendi kendine tetiklenmez. Önbellekten sunulmayan her istekte WordPress, zamanlanmış görevlerin listesini okur ve eğer zamanı gelen bir görev varsa, işi yapması için /wp-cron.php adresine kendisine yönelik ikinci bir HTTP isteği gönderir. Bu görevi sistem cron'una taşımak, o dakika içinde siteye bin ziyaretçi gelse de hiç gelmese de sabit bir zamanlamada öngörülebilir bir çalışma sağlar.

İşi fiilen yapan iki satır vardır: wp-config.php içinde bir sabit değer ve bir crontab girdisi. Bu kılavuzdaki diğer her şey, bu iki satırın belirtmediği kısımlardır. Görevin hangi kullanıcı yetkisiyle çalışması gerektiği, zamanlanmış etkinliklerin gerçekten tetiklendiğinin nasıl doğrulanacağı ve kurulumun sitede hiçbir hata mesajı vermeden başarısız olabileceği üç durum bu kapsamdadır.

Örneklerde WordPress dizini olarak /srv/www/example.com, web sunucusu kullanıcısı olarak ise www-data kullanılmıştır. Kendi yollarınızı ve kullanıcı adınızı her yerde buna göre değiştirin.

Yoğun bir sitede cron maliyetini hangi ziyaretçi tetikler

Önbelleğe alınmayan her istek, kontrol maliyetini beraberinde getirir. WordPress, cron seçeneğini yükler, zaman damgalarını karşılaştırır ve bir işlem zamanı geldiğinde spawn_cron() fonksiyonunu çağırır. Bu fonksiyon, /wp-cron.php adresine engellemeyen (non-blocking) bir loopback isteği gönderir. Ziyaretçi sonucun dönmesini beklemez ancak bir PHP worker süreci bekler. pm.max_children = 5 ile çalışan küçük bir VPS üzerinde, yavaş bir zamanlanmış görev, PHP kapasitenizin beşte birini işlem süresi boyunca meşgul eder. Bu durumun en yoğun dakikanızda gerçekleşme olasılığı yüksektir; çünkü sayfa yüklemelerinin en fazla olduğu an o andır.

WordPress, mükerrer işlemleri sınırlandırır. Varsayılan olarak WP_CRON_LOCK_TIMEOUT, yani 60 saniyelik bir ömre sahip kilit mekanizması kullanır; böylece eş zamanlı ziyaretçilerin her biri ayrı bir işlem başlatmaz. Kilit, mükerrerliği sınırlar ancak iş yükünü istek yolundan kaldırmaz.

Bunun bir sorun olup olmadığına karar vermeden önce kendi sunucunuzda ne sıklıkla tetiklendiğini sayın. Her loopback, web sunucusu erişim günlüğünde (access log) şu şekilde görünür:

sudo grep -c 'wp-cron.php' /var/log/nginx/access.log

Apache ise bunun yerine /var/log/apache2/access.log dosyasına yazar. Günde binlerce kez gerçekleşen bir işlem gerçek bir maliyettir. Bu, bir makalede okumak yerine kendi sunucunuzda ölçmeniz gereken bir değerdir; tıpkı başka herhangi bir değişiklikten önce ve sonra bir VPS'i kıyaslamanız (benchmark) gerektiği gibi.

Önbellekleme durumu değiştirir. Eğer bir sayfa önbelleği, isteklerin çoğunu statik HTML olarak sunuyorsa, bu istekler için PHP çalışmaz ve dolayısıyla cron kontrolü gerçekleşmez. Yoğun önbelleğe sahip bir site, aşağıda belirtilen düşük trafikli site gibi davranmaya başlar.

Ziyaretçi tetiklemeli cron, düşük trafikli sitelerde neden aksar

Ziyaretçi yoksa cron da çalışmaz. Günde sadece birkaç ziyaret alan bir site, zamanlanmış görevlerini sadece bu ziyaretlerin gerçekleştiği rastgele anlarda, günde birkaç kez çalıştırır.

Belirtilerin hepsi aynı yapıdadır. 09:00 için zamanlanan bir gönderi, birisi sayfayı yükleyene kadar gönderi listesinde Missed schedule olarak işaretli kalır. Yedekleme eklentileri gece işlemlerini atlar. Güncelleme denetimleri gecikir; bu nedenle bir güvenlik sürümü yayınlanmış olsa bile kontrol paneli güncellenecek bir şey olmadığını gösterir. Sipariş e-postaları, yenileme bildirimleri ve süre sonu uyarıları geç gönderilir.

Bunların hiçbiri bir hata kaydı oluşturmaz. WordPress açısından görev hiçbir zaman gecikmemiştir, çünkü görev hiçbir zaman başlatılmamıştır.

Adım 1: wp-config.php dosyasında ziyaretçi tetikleyicisini kapatın

/srv/www/example.com/wp-config.php dosyasını açın ve şu sabiti ekleyin:

define( 'DISABLE_WP_CRON', true );

Bu satırı, /* That's all, stop editing! Happy publishing. */ yazan satırın üzerine yerleştirin. Çünkü bu yorum satırının hemen altındaki satır wp-settings.php gerektirir ve wp-settings.php, WordPress'in cron denetimini init üzerine bağladığı yerdir. Bu require ifadesinden sonra tanımlanan bir sabit, herhangi bir şeyi değiştirmek için çok geç kalmış olur; dosya doğru görünse de tetikleyici çalışmaya devam eder.

Satırın düşündüğünüz yerde olduğunu doğrulayın:

grep -n "DISABLE_WP_CRON\|stop editing" /srv/www/example.com/wp-config.php

Bu sabit, etkinliklerin zamanlanmasını durdurmaz. Eklentiler, daha önce olduğu gibi kuyruğa iş eklemeye devam eder. Yalnızca sayfa yüklemelerinin bu kuyruğu çalıştırmasını engeller; bu da 3. adımı tamamlayana kadar kuyruğun hiçbir zaman çalışmayacağı anlamına gelir.

Ayrıca /wp-cron.php adresine yapılan doğrudan istekleri de engellemez. Herkes bu URL'yi talep edebilir ve dosya yalnızca zamanı gelen işleri çalıştırdığı için bu genellikle zararsızdır. Web sunucusu yapılandırmanızda bunu engellemek isteğe bağlıdır. Eğer engellerseniz, bu kılavuzun sonuna doğru yer alan curl yedekleme mekanizması da çalışmayı durdurur.

Adım 2: WP-CLI kurulumu

WP-CLI, WordPress için resmi komut satırı aracıdır. Bu araç, web sunucusunun PHP modülünden ayrı bir paket olan PHP komut satırı ikili dosyasına ihtiyaç duyar.

php -v
sudo apt install -y php-cli

WP-CLI'ı, resmi kurulum kılavuzunun önerdiği yöntem olan phar derlemesi üzerinden kurun:

cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

php wp-cli.phar --info komutu PHP ikili dosya yolunu, PHP sürümünü ve WP-CLI sürümünü yazdırır. Eğer bu üçü de görüntüleniyorsa phar düzgün çalışıyor demektir. Ağustos 2026 itibarıyla kurulum kılavuzu minimum PHP 7.2.24 sürümünü şart koşmaktadır; Ubuntu 24.04 ise PHP 8.3 ile geldiğinden, güncel bir sunucu bu gereksinimi fazlasıyla karşılar. Daha sonra sudo wp cli update ile güncelleyin.

WP-CLI'ı hiçbir zaman root olarak değil, sitenin kullanıcı hesabı ile çalıştırın:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com core version

WP-CLI, root olarak çalıştırıldığında başlamayı reddeder:

Error: YIKES! It looks like you're running this as root.

Bu durum --allow-root kullanımını önerir. Burada bunu kullanmayın. Nedeni aşağıdaki ilk hata modunda açıklanmıştır.

Ayrıca sudo -u www-data -i komutunun çalışmadığına dikkat edin; çünkü bu hesabın giriş kabuğu /usr/sbin/nologin olarak ayarlanmıştır ve This account is currently not available. çıktısını alırsınız. Komutu doğrudan sudo -u üzerinden iletmek giriş kabuğunu atlar, bu sayede komut sorunsuz çalışır.

Şimdi WordPress'in 1. adımdaki sabiti görüp görmediğini doğrulayın:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com eval 'var_dump( DISABLE_WP_CRON );'

Bu komut bool(true) çıktısını verir. Tanımlanmamış bir sabit ile ilgili ölümcül bir hata (fatal error), define() satırına ulaşılamadığı anlamına gelir; bu da genellikle ilgili satırın require ifadesinin altına yerleştirildiğini gösterir.

Adım 3: cron girdisini doğru kullanıcı ile ekleyin

Doğru kullanıcı, PHP'nin yazdığı dosyaların sahibi olan kullanıcıdır. Her iki tarafı da kontrol edin:

stat -c '%U %G' /srv/www/example.com/wp-content/uploads
grep -E '^(user|group) = ' /etc/php/8.3/fpm/pool.d/www.conf

Varsayılan bir Ubuntu kurulumunda her iki yanıt da www-data değerini döndürür. Eğer siteye, Ubuntu 24.04 üzerinde bir LAMP yığını kurulumunda genellikle sonuçlanan, kendi kullanıcısına sahip özel bir PHP-FPM havuzu atadıysanız, aşağıdakilerin tamamında bu kullanıcıyı kullanın.

Söz konusu kullanıcının yazabileceği bir günlük dizini oluşturun:

sudo install -d -o www-data -g www-data -m 750 /var/log/wp-cron

İlgili kullanıcının crontab dosyasını düzenleyin:

sudo crontab -u www-data -e

Şu satırı ekleyin:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1

Parça parça inceleyelim. */5 komutu her beş dakikada bir çalıştırır. flock -n bir kilit dosyası kullanır ve önceki bir çalıştırma hala devam ediyorsa işlemi hemen sonlandırır. /usr/local/bin/wp, cron'un ihtiyaç duyduğu mutlak dosya yoludur. --path, komutun herhangi bir çalışma dizininden çalıştırılmasını sağlar. --due-now, kuyruktaki her olayı değil, yalnızca zamanı gelmiş olayları çalıştırır. Yönlendirme işlemi, normal çıktıları ve hataları okuyabileceğiniz tek bir dosyaya gönderir.

Bu yönlendirme pratikte isteğe bağlı değildir. Cron, bir işin çıktısını kullanıcısına e-posta ile gönderir; çoğu VPS imajında bir posta aktarım aracısı (MTA) yüklü değildir ve cron bu durumda (CRON) info (No MTA installed, discarding output) hatasını günlüğe kaydederek çıktıyı siler. Bir dosya, kanıtları saklamanızı sağlar.

Kaydedilen dosyayı kontrol edin:

sudo crontab -u www-data -l

Birden fazla site için, hepsinin aynı anda başlamaması adına dakikaları kademeli olarak ayarlanmış şekilde her biri için bir satır kullanın:

*/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-one.lock /usr/local/bin/wp --path=/srv/www/one.example.com cron event run --due-now >> /var/log/wp-cron/one.log 2>&1
2-59/5 * * * * /usr/bin/flock -n /run/lock/wp-cron-two.lock /usr/local/bin/wp --path=/srv/www/two.example.com cron event run --due-now >> /var/log/wp-cron/two.log 2>&1

Günlük dosyası, döndürme (rotate) işlemi yapmadığınız sürece sürekli büyür. /etc/logrotate.d/wp-cron dosyasını oluşturun:

/var/log/wp-cron/*.log {
    weekly
    rotate 4
    missingok
    notifempty
    compress
    create 640 www-data www-data
}

Dosyanın herhangi bir değişiklik yapmadan ayrıştırılıp ayrıştırılamadığını kontrol edin: sudo logrotate --debug /etc/logrotate.d/wp-cron.

Adım 4: zamanlanmış olayların gerçekten tetiklendiğini doğrulama

Başarıyla kaydedilen bir crontab satırı hiçbir şeyi kanıtlamaz. En basit kontrolden başlayarak sorunu kesin olarak çözen yönteme doğru ilerleyin.

İlk olarak, cron komutu başlattı mı? Cron, günlük kayıtlarını kendi birimi altında journal'a yazar:

journalctl -u cron.service --since "15 min ago" | grep wp

Sağlıklı bir girdi, zaman damgası ve ana bilgisayar adı baştan kırpılmış şekilde şu şekilde görünür:

CRON[24913]: (www-data) CMD (/usr/bin/flock -n /run/lock/wp-cron-example.lock /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now >> /var/log/wp-cron/example.log 2>&1)

Bu satır, cron'un komutunuzu www-data olarak başlattığı anlamına gelir. Komutun çalışıp çalışmadığı hakkında hiçbir bilgi vermez.

İkinci olarak, WordPress herhangi bir şey yürüttü mü? Günlük dosyasını okuyun:

sudo tail -n 20 /var/log/wp-cron/example.log

WP-CLI her olay için bir satır ve ardından bir toplam yazdırır:

Executed the cron event 'wp_version_check' in 0.418s.
Success: Executed a total of 2 cron events.

Hatalar aynı dosyaya düşer; 2>&1 kullanımının temel amacı da budur. Çoğu çalıştırmada bekleyen iş olmayacağı için çok az çıktı üretilir; bu nedenle, iş beklediğini bildiğiniz bir çalıştırmadan sonra dosyayı inceleyin.

Üçüncü olarak, uçtan uca kanıtlayın. Bir işaretleyici olay zamanlayın ve kayboluşunu izleyin:

sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event schedule wp_cli_cron_check now
sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event list --fields=hook,next_run_relative --format=csv | grep wp_cli_cron_check

Bir aralık bekleyin, ardından listeleme komutunu tekrar çalıştırın. Kanca (hook) kaybolacaktır, çünkü tek seferlik bir olay çalıştığında kuyruktan kaldırılır. Hiçbir eklenti bu kanca adında bir geri çağırma (callback) kaydetmediği için, çalıştırmak site üzerinde başka bir işlem yapmaz. Kanca iki aralık geçmesine rağmen hala listeleniyorsa, kuyruk işlenmiyor demektir; ilk iki kontrol size sorunun cron'dan mı yoksa WP-CLI'dan mı kaynaklandığını söyleyecektir.

Bunun için wp cron test kullanmayın. Bu komut, ziyaretçi tetiklemeli başlatmanın çalışıp çalışmadığını kontrol eder ve DISABLE_WP_CRON doğru (true) olduğunda hata verir. Doğru yapılandırılmış bir sunucuda bu hata beklenen çıktıdır, bir arıza değildir.

systemd timer alternatifi

Sunucudaki diğer zamanlanmış işler halihazırda systemd servisleri ve timer'ları ile çalışıyorsa, WordPress'i de buraya taşıyın. Her çalışma systemctl list-timers içerisinde görünür hale gelir ve çıktı, log rotasyonu gerektiren bir dosya yerine doğrudan journal'a yazılır.

/etc/systemd/system/wp-cron-example.service dosyasını oluşturun:

[Unit]
Description=Run due WordPress cron events for example.com

[Service]
Type=oneshot
User=www-data
Group=www-data
ExecStart=/usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

Ardından /etc/systemd/system/wp-cron-example.timer dosyasını oluşturun:

[Unit]
Description=Run WordPress cron for example.com every 5 minutes

[Timer]
OnCalendar=*:0/5
AccuracySec=30s
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now wp-cron-example.timer
systemctl list-timers wp-cron-example.timer
journalctl -u wp-cron-example.service -n 20

Systemd aynı servisin iki kopyasını aynı anda çalıştırmayacağından, bu sürüm flock kullanımına ihtiyaç duymaz. Persistent=true parametresi, makine kapalıyken kaçırılan bir çalışmanın telafi edilmesini sağlar; bu, crontab girdisi ile yapılamayan bir işlemdir.

Crontab veya timer yönteminden birini seçin. Her ikisini de aynı site üzerinde çalıştırmak, kuyruğun iki kez boşaltılmasına neden olur; bu durumda e-posta veya sipariş işlerinin mükerrer çalışması müşterileriniz tarafından fark edilebilir.

Cron işinin neden root olarak çalıştırılmaması gerektiği

Bu, kurulumun başarısız olduğu üç yoldan ilkidir. İşi root kullanıcısının crontab dosyasına eklerseniz, WP-CLI herhangi bir işlem yapmadan durur:

Error: YIKES! It looks like you're running this as root.

Kuyruk asla çalışmaz ve eğer çıktıyı yönlendirmediyseniz mesajı hiçbir zaman göremezsiniz. Tehlikeli çözüm --allow-root eklemektir, çünkü bu durumda eklentinin o çalışma sırasında oluşturduğu her dosya root kullanıcısına ait olur. Bir sonraki web isteği www-data olarak çalışır, bu dizinlere yazamaz ve site şu tür hatalar vermeye başlar:

Unable to create directory wp-content/uploads/2026/08. Is its parent directory writable by the server?

Dosya sahipliğini düzeltin ve ardından işi taşıyın:

sudo chown -R www-data:www-data /srv/www/example.com/wp-content

Root kullanıcısının crontab dosyası ile www-data kullanıcısının crontab dosyası ayrı dosyalardır; bu nedenle birinden satırı silmek diğerini etkilemez. Her ikisini de kontrol edin:

sudo crontab -u root -l
sudo crontab -u www-data -l

Cron neden wp: not found hatası veriyor

Bu ikinci başarısızlık durumudur. Cron, kullanıcı işlerine çok kısa bir PATH, yani /usr/bin:/bin sağlar. WP-CLI, bu listede yer almayan /usr/local/bin dizinine kurulur. İş başlar, saniyenin çok küçük bir diliminde başarısız olur ve günlük kaydında şu tek satır yer alır:

/bin/sh: 1: wp: not found

Tahmin yürütmek yerine cron'un ortam değişkenlerini kendiniz görün. Geçici bir satır ekleyin:

*/5 * * * * env > /tmp/cron-env.txt 2>&1

Bir aralık geçtikten sonra /tmp/cron-env.txt dosyasını okuyun ve ardından satırı silin. Bu dosyadaki PATH= değeri, işinizin tam olarak aldığı değerdir.

İki çözüm yolu mevcuttur. 3. adımda olduğu gibi /usr/local/bin/wp mutlak yolunu kullanın. Veya PATH değişkenini crontab dosyasının en üstünde, tüm iş satırlarının üzerinde bir kez tanımlayın:

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Aynı tuzak bir alt seviyede daha bulunur. wp phar dosyası #!/usr/bin/env php ile başlar, bu nedenle kabuğun php dosyasını da bulabilmesi gerekir. Eğer PHP, /usr/bin dışında bir yerde bulunuyorsa (özel derlemelerde ve kontrol paneli kurulumlarında bu durum yaşanır), şu hatayı alırsınız:

/usr/bin/env: 'php': No such file or directory

Bu durumda yorumlayıcıyı açıkça çağırın, örneğin /usr/local/bin/php /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now şeklinde kullanın.

Bir dakikalık aralığın orijinal sorunu neden yeniden oluşturduğu

Bu üçüncü başarısızlıktır. * * * * * beş dakikadan daha güvenli hissettirir ancak yoğun bir sitede sizi başladığınız noktaya geri döndürür. Eğer bir çalıştırma, aralık süresinden daha uzun sürerse, ilki hala devam ederken bir sonraki başlar. On dakika sonra, her biri kendi belleğini ve veritabanı bağlantısını tutan on adet PHP süreci oluşur.

Doğrudan bir yığılma olup olmadığını kontrol edin:

ps -eo etimes,user,args | grep '[c]ron event run'

etimes, sürecin saniye cinsinden yaşıdır. Tek bir satır sağlıklı olduğunu gösterir. Yaşları aralığınızın çok üzerinde olan birden fazla satır, çalıştırmaların üst üste bindiği anlamına gelir; küçük bir VPS üzerinde bu durum MySQL Too many connections hatasıyla veya çekirdeğin belleği geri kazanmak için PHP'yi sonlandırmasıyla sonuçlanır ki bunu sudo dmesg -T | grep -i 'killed process' ile doğrulayabilirsiniz.

WP-CLI, wp-cron.php üzerinden istek göndermek yerine olay geri çağırmalarını doğrudan çalıştırır; bu nedenle WordPress'in yinelenen başlatmalara karşı kullandığı 60 saniyelik kilit burada geçerli değildir. 3. adımdaki girişte yer alan flock -n, çakışmayı önleyen mekanizmadır. Atlanan bir çalıştırma, tasarımı gereği sessizce ve hemen sonlanır. Çakışma, ana bilgisayar çekirdeğinin sizin yerinize çözdüğü bir sorun değil, crontab içerisinde çözmeniz gereken bir sorundur: Linux çekirdeği 7.2 ile eklenen önbellek duyarlı görev yerleşimi bile sürecin hangi çekirdeğe atanacağına karar verir, ancak kaç tane başlattığınızla ilgilenmez.

Aralığı, gerçekten bağlı olduğunuz en kısa zamanlamaya göre seçin ve önce bir çalıştırmayı ölçün:

time sudo -u www-data /usr/local/bin/wp --path=/srv/www/example.com cron event run --due-now

Beş dakika makul bir varsayılan değerdir: 09:00 için zamanlanmış bir gönderi 09:05'e kadar yayınlanır. Zaman açısından kritik hiçbir şeyin olmadığı bir site için on beş dakika uygundur. Bir dakika, yalnızca gerçekten ihtiyaç duyan mağazalar ve kuyruk tabanlı eklentiler içindir; bunu da ancak bir çalıştırmanın birkaç saniye içinde bittiğinden emin olduğunuzda kullanın.

WP-CLI kuramıyorsanız

Bazı barındırma sağlayıcıları kabuk araçlarını engeller. wp-cron.php adresine yapılacak basit bir HTTP isteği, aynı kuyruğu tüm web yığını üzerinden çalıştırır:

*/5 * * * * /usr/bin/curl -sS --max-time 120 "https://example.com/wp-cron.php?doing_wp_cron" > /dev/null

Vazgeçtikleriniz şunlardır:

• Çalıştırma süresi, web sunucusu ve PHP-FPM istek zaman aşımları ile sınırlıdır; bu nedenle uzun süren bir işlem yarıda kesilebilir.
• Sertifika geçerli olmalıdır, aksi takdirde curl işlemi SSL certificate problem hatasıyla durdurur; bu yüzden yenileme işlemlerini Nginx üzerinde Certbot ile çalışır durumda tutun.
• Sayfa önbellekleme mekanizması wp-cron.php dosyasını önbelleğe almamalıdır; aksi takdirde cron istekleri önbellekten yanıt alır ve hiçbir işlem çalışmaz.
• Olay bazlı çıktı alamazsınız; bu nedenle bir işin çalıştığına dair tek kanıt, sistem üzerindeki etkisidir.

-sS bayrağı, başarılı işlemlerde curl çıktısını gizlerken hataları yazdırmaya devam eder; cron işlerinde istenen davranış budur.

Sunucu zamanlamasında başka neler yer almalı

Sistem cron'u WordPress kuyruğunun yönetimini üstlendiğinde, sunucunun diğer rutin işlerini de aynı yerde tutarak tek bir noktadan izlenebilir hale getirin. İşletim sistemi güvenlik yamaları, elle yönetilen bir cron satırı yerine unattended upgrades aracına bırakılmalıdır. WordPress eklenti ve tema güncellemeleri ise farklı bir değerlendirme gerektirir: crontab içindeki bir wp plugin update --all komutu, gece saat 03:00'te kimse izlemiyorken canlı bir siteyi kolayca bozabilir; bu nedenle güncellemeleri kontrollü bir şekilde, bir hazırlık (staging) aşaması ve yedekleme sonrasında gerçekleştirin.

FAQ

WP-Cron devre dışı bırakıldığında zamanlanmış gönderiler yayınlanmaz mı?

Hayır, kuyruğu çalıştıran başka bir mekanizma olduğu sürece yayınlanır. DISABLE_WP_CRON yalnızca sayfa yüklemelerinin kuyruğu tetiklemesini engeller. Etkinlikler tıpkı eskisi gibi zamanlanmaya devam eder. 09:00 için ayarlanan bir gönderi, 09:00'dan sonraki ilk cron çalışmasında yayınlanır; dolayısıyla beş dakikalık bir aralıkla gönderi en geç 09:05'te yayınlanmış olur. Eğer sabiti tanımlayıp cron girdisini eklemezseniz, gönderi kuyruk çalıştırılana kadar listede Missed schedule olarak işaretli şekilde bekler.

WordPress cron işini hangi kullanıcı çalıştırmalıdır?

PHP'nin yazdığı dosyaların sahibi olan kullanıcı; bu, varsayılan bir Ubuntu kurulumunda www-data kullanıcısıdır. Bunu stat -c '%U %G' /srv/www/example.com/wp-content/uploads ile kontrol edin ve PHP-FPM havuz yapılandırmanızdaki user = satırı ile karşılaştırın. İşi root olarak çalıştırmak WP-CLI'ın bir YIKES hatası vererek durmasına neden olur; --allow-root ile zorlamak ise wp-content içerisinde web sunucusunun daha sonra yazamayacağı, root sahipliğinde dosyalar bırakır.

Sistem cron'u, WordPress cron'unu ne sıklıkla çalıştırmalıdır?

Beş dakikalık aralık çoğu site için uygundur. Aralığı, gerçekten ihtiyaç duyduğunuz en kısa zamanlamaya göre belirleyin ve WP-CLI komutunun önüne time ekleyerek ölçebileceğiniz tek bir çalıştırma süresinin üzerinde tutun. Bir dakikalık aralıklar, flock ile korunmadığı sürece yoğun sitelerde çalıştırmaların üst üste binmesine neden olur.

WP-Cron'u devre dışı bıraktıktan sonra neden wp cron test başarısız oluyor?

Çünkü bu komut ziyaretçi tarafından tetiklenen başlatma işlemini test eder ve DISABLE_WP_CRON değeri true olarak ayarlandığında hata bildirir. Bu, bu şekilde yapılandırılmış bir sunucuda beklenen doğru sonuçtur. Bunun yerine sistem cron yolunu kontrol edin: /var/log/wp-cron/example.log dosyasını okuyun veya wp cron event schedule ile bir işaretleyici etkinlik zamanlayın ve bir sonraki çalıştırmadan sonra wp cron event list içerisinden kaybolduğunu doğrulayın.

WP-CLI gerekli mi, yoksa wp-cron.php dosyasına curl atmak yeterli mi?

Curl çalışır ve WP-CLI kuramadığınız durumlarda doğru çözümdür. Ancak daha yavaştır çünkü WordPress'i web sunucusu üzerinden yükler ve istek zaman aşımı ile sınırlıdır. WP-CLI ise etkinlikleri web zaman aşımı olmayan bir komut satırı PHP sürecinde çalıştırır ve her etkinlik için süresiyle birlikte tek bir satır çıktı verir; böylece günlük kaydı size tam olarak neyin çalıştığını ve ne kadar sürdüğünü söyler.