WP-Cron'u Kapatıp System Cron Kullanma

wp-cron nedir ve system cron neden onun yerini alır

WP-Cron, WordPress'e yerleşik görev zamanlayıcıdır ve yalnızca biri bir sayfa isteğinde bulunduğunda çalışır. WordPress içinde hiçbir işlem kendiliğinden uyanmaz. Önbellekten sunulmayan her istekte WordPress, zamanlanmış işlerin listesini okur. Süresi gelen bir iş varsa, işi gerçekleştirmek için /wp-cron.php adresine kendisine ikinci bir HTTP isteği gönderir. Bu işi system cron'a taşımak, sitenin o dakika bin ziyaretçisi de olsa hiç ziyaretçisi olmasa da sabit bir zamanlamayla öngörülebilir tek bir çalıştırma sağlar.

Asıl işi iki satır yapar: wp-config.php içindeki bir sabit ve bir crontab girdisi. Bu kılavuzdaki diğer tüm bölümler, bu iki satırın açıklamadığı konuları ele alır. İşin hangi kullanıcıyla çalıştırılması gerektiği, zamanlanmış olayların gerçekten tetiklendiğinin nasıl doğrulanacağı ve kurulumun site üzerinde hiçbir çıktı üretmeden başarısız olabileceği üç durum açıklanır.

Örneklerde WordPress dizini olarak /srv/www/example.com, web sunucusu kullanıcısı olarak www-data kullanılmıştır. Her yerde kendi yollarınızı ve kullanıcı adınızı kullanın.

Yoğun trafikli bir sitede cron maliyetini hangi ziyaretçi tetikledi?

Önbelleğe alınmamış her istek bu kontrolün maliyetini taşır. WordPress, cron seçeneğini yükler ve zaman damgalarını karşılaştırır. Çalıştırılması gereken bir işlem varsa spawn_cron() çağrılır. Bu işlev, /wp-cron.php adresine bloklamayan bir loopback isteği gönderir. Ziyaretçi sonucu beklemez. Ancak bir PHP worker'ı bekler. pm.max_children = 5 ile PHP-FPM çalıştıran küçük bir VPS üzerinde yavaş bir zamanlanmış iş, tamamlanması ne kadar sürerse sürsün PHP kapasitesinin beşte birini kullanır. Bu işin yoğunluğun en yüksek olduğu dakikada tetiklenme olasılığı daha yüksektir. Çünkü sayfa yüklemeleri en çok o sırada gerçekleşir.

WordPress yinelenen çalıştırmaları sınırlar. Ömrü WP_CRON_LOCK_TIMEOUT olan bir kilit alır. Varsayılan değer 60 saniyedir. Böylece eşzamanlı ziyaretçiler ayrı ayrı bir çalıştırma başlatmaz. Kilit, yinelenen çalıştırmaları sınırlar. Ancak işi istek yolundan çıkarmaz.

Bunun önemli olup olmadığına karar vermeden önce kendi sunucunuzda ne sıklıkta tetiklendiğini ölçün. Her loopback isteği web sunucusunun access log'unda görünür:

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

Apache bunun yerine /var/log/apache2/access.log dosyasına yazar. Günde binlerle ifade edilen bir sayı gerçek bir maliyettir. Bu sayıyı bir makalede okumak yerine kendi sunucunuzda ölçmeniz gerekir. Bu yaklaşım, başka bir değişiklikten önce ve sonra bir VPS üzerinde benchmark yapmak ile aynıdır.

Önbellekleme durumu değiştirir. Sayfa önbelleği isteklerin çoğunu statik HTML olarak sunuyorsa bu istekler için PHP hiç çalışmaz. Bu nedenle cron kontrolü de gerçekleşmez. Yoğun trafiğe sahip ve büyük ölçüde önbelleğe alınan bir site, aşağıdaki düşük trafikli siteye benzemeye başlar.

Sessiz bir sitede cron işlemlerini hangi ziyaretçi tetikledi

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

Belirtiler genellikle aynıdır. 09:00 için zamanlanan bir yazı, biri bir sayfa yükleyene kadar yazı listesinde Missed schedule durumunda kalır. Yedekleme eklentileri gece çalışmaz. Güncelleme denetimleri gecikir. Bu nedenle güvenlik güncellemesi yayımlanmış olsa bile yönetim panelinde güncellenecek bir şey görünmez. Sipariş e-postaları, yenileme bildirimleri ve süre sonu uyarıları geç gönderilir.

Bunların hiçbiri hata kaydına yazılmaz. WordPress açısından görev gecikmiş değildir. Çünkü görev hiç başlatılmamıştır.

Adım 1: wp-config.php içindeki ziyaretçi tetikleyicisini devre dışı bırakma

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

define( 'DISABLE_WP_CRON', true );

Bu satırı /* That's all, stop editing! Happy publishing. */ satırının üzerine ekleyin. Çünkü bu yorumun hemen altındaki satır wp-settings.php gerektirir ve WordPress cron kontrolünü init üzerine wp-settings.php ile bağlar. require ifadesinden sonra tanımlanan bir sabit, davranışı değiştirmek için çok geç tanımlanmış olur. Dosya doğru görünür, ancak tetikleyici çalışmaya devam eder.

Satırın beklediğiniz yerde olduğunu doğrulayın:

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

Bu sabit, olayların zamanlanmasını durdurmaz. Eklentiler, önceki gibi kuyruğa iş eklemeye devam eder. Yalnızca sayfa yüklemelerinin bu kuyruğu çalıştırmasını engeller. Bu nedenle 3. adımı tamamlayana kadar kuyruk hiç çalışmaz.

Bu sabit, /wp-cron.php adresine yapılan doğrudan istekleri de engellemez. Herkes bu URL'yi istemeye devam edebilir. Bu genellikle zararsızdır, çünkü dosya yalnızca zamanı gelen işleri çalıştırır. Bu adresi web sunucusu yapılandırmasında engellemek isteğe bağlıdır. Engellerseniz bu kılavuzun sonlarına doğru açıklanan curl geri dönüş mekanizması da çalışmaz.

Adım 2: WP-CLI kurulumu

WP-CLI, WordPress için resmi komut satırı aracıdır. Web sunucusunun PHP modülünden ayrı bir paket olan PHP command line binary bileşenine ihtiyaç duyar.

php -v
sudo apt install -y php-cli

WP-CLI'yi resmi kurulum kılavuzunun önerdiği yöntem olan phar build ü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 PHP binary yolunu, PHP sürümünü ve WP-CLI sürümünü yazdırır. Üçünün de çıktıda yer alması phar dosyasının çalıştığını gösterir. Ağustos 2026 itibarıyla kurulum kılavuzu minimum PHP sürümü olarak PHP 7.2.24'ü belirtir ve Ubuntu 24.04, PHP 8.3 ile birlikte gelir. Bu nedenle güncel bir sunucu bu gereksinimi rahatça karşılar. Daha sonra sudo wp cli update ile güncelleyin.

WP-CLI'yi sitenin kullanıcısı olarak çalıştırın; root olarak çalıştırmayın:

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

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

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

--allow-root kullanılmasını önerir. Burada bunu kullanmayın. Bunun nedeni aşağıdaki ilk hata senaryosunda açıklanmaktadır.

Ayrıca sudo -u www-data -i komutunun çalışmadığına dikkat edin. Bunun nedeni, bu hesabın login shell değerinin /usr/sbin/nologin olması ve This account is currently not available. almanızdır. Komutun doğrudan sudo -u öğesine geçirilmesi login shell'i atlar ve komutun sorunsuz çalışmasını sağlar.

Şimdi WordPress'in 1. adımda tanımlanan sabiti gerçekten gördüğünü 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 sabitle ilgili fatal error, define() satırına ulaşılmadığı anlamına gelir. Bunun yaygın nedeni, satırın require ifadesinin altına eklenmiş olmasıdır.

Adım 3: cron girdisini doğru kullanıcı olarak ekleme

Doğru kullanıcı, PHP'nin dosya 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 komut da www-data sonucunu verir. Siteye kendi kullanıcısına sahip bir PHP-FPM pool tanımlandıysa, Ubuntu 24.04 üzerinde LAMP stack kurulumu için siteye özel yapılandırmada genellikle bu kullanıcı kullanılır. Aşağıdaki işlemlerin tamamında bu kullanıcıyı kullanın.

Bu kullanıcının yazabileceği bir log dizini oluşturun:

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

Bu kullanıcının crontab dosyasını düzenleyin:

sudo crontab -u www-data -e

Bir 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 açıklayalım. */5 komutu beş dakikada bir çalıştırır. flock -n bir lock dosyası alır ve önceki çalıştırma hâlâ bu dosyayı tutuyorsa hemen sonlanır. /usr/local/bin/wp cron'un ihtiyaç duyduğu mutlak yoldur. --path komutun herhangi bir çalışma dizininden çalıştırılmasını sağlar. --due-now kuyruktaki tüm event'ler yerine yalnızca zamanı gelen event'leri çalıştırır. Yönlendirme, normal çıktıyı ve hataları okuyabileceğiniz tek bir dosyaya gönderir.

Bu yönlendirme pratikte isteğe bağlı değildir. Cron, bir job'ın çıktısını ilgili kullanıcıya e-posta ile gönderir. Çoğu VPS image'ında mail transfer agent kurulu değildir. Bu durumda cron (CRON) info (No MTA installed, discarding output) kaydını yazar ve çıktıyı atar. Bir dosya, gerekli kanıtı korur.

Dosyanın kaydedildiğini kontrol edin:

sudo crontab -u www-data -l

Birden fazla site için her siteye bir satır ekleyin. Dakikaları farklı belirleyin; böylece tüm job'lar aynı anda başlamaz:

*/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

Log dosyası rotate edilmezse sürekli büyür. /etc/logrotate.d/wp-cron dosyasını yazın:

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

Herhangi bir işlem yapmadan dosyanın ayrıştırılabildiğini kontrol edin: sudo logrotate --debug /etc/logrotate.d/wp-cron.

Adım 4: zamanlanmış olayların gerçekten çalıştığını doğrulama

Başarıyla kaydedilen bir crontab satırı tek başına bir şey kanıtlamaz. En düşük maliyetli kontrolden kesin sonuç veren kontrole doğru ilerlenmelidir.

İlk olarak cron komutu başlattı mı? Cron, kendi unit'i altında journal'a kayıt yazar:

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

Sağlıklı bir kayıt, başındaki zaman damgası ve host adı çıkarıldığında aşağıdaki gibi 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 başarıyla çalışıp çalışmadığı hakkında bilgi vermez.

İkinci olarak WordPress herhangi bir işlem yürüttü mü? Log dosyası okunmalıdır:

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

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

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

Hatalar aynı dosyaya yazılır. 2>&1 kullanımının amacı budur. Çoğu çalıştırmada yürütülecek olay bulunmaz ve dosyaya çok az çıktı yazılır. Bu nedenle dosya, çalışması gerektiğini bildiğiniz bir işlemden sonra okunmalıdır.

Üçüncü olarak uçtan uca doğrulama yapılmalıdır. Bir marker olayı zamanlayın ve listeden kaldırılmasını 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 ve ardından listeleme komutunu tekrar çalıştırın. Hook listeden kaldırılmıştır. Çünkü tek seferlik olay, çalıştırıldığında kuyruktan silinir. Hiçbir plugin bu hook adına callback kaydetmediği için çalıştırılması site üzerinde başka bir işlem yapmaz. Hook iki aralık sonrasında hâlâ listeleniyorsa kuyruk çalıştırılmıyordur. İlk iki kontrol, sorunun cron'dan mı yoksa WP-CLI'dan mı kaynaklandığını gösterir.

Bu işlem için wp cron test kullanılmamalıdır. Bu komut, ziyaretçi tarafından tetiklenen işlem başlatmanın çalışıp çalışmadığını denetler ve DISABLE_WP_CRON doğru olduğunda hata verir. Doğru yapılandırılmış bir sunucuda hata beklenen çıktıdır; arıza değildir.

systemd timer alternatifi

Sunucudaki zamanlanmış işlerin geri kalanı zaten systemd servisleri ve timer'ları olarak çalışıyorsa WordPress'i de aynı yapıya ekleyin. Böylece her çalıştırma systemctl list-timers içinde görünür ve çıktı, döndürmeniz gereken bir dosya yerine 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ırmaz. Bu nedenle bu sürümde flock gerekmez. Persistent=true, makine kapalıyken kaçırılan bir çalıştırmanın telafi edilmesini sağlar. crontab girdisi bunu yapamaz.

crontab veya timer seçeneklerinden birini kullanın. Aynı site için ikisini birden çalıştırmak kuyruğun iki kez işlenmesine neden olur. E-posta veya sipariş işlerinin yinelenen çalıştırmaları müşterileriniz tarafından fark edilir.

Cron işinin root olarak çalışmaması gerekir

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

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

Kuyruk hiç çalışmaz. Çıktıyı başka bir yere yönlendirmediyseniz bu mesajı göremezsiniz. Tehlikeli çözüm, --allow-root eklemektir. Bu durumda eklentinin ilgili çalıştırma sırasında oluşturduğu her dosyanın sahibi root olur. Sonraki web isteği www-data olarak çalışır, bu dizinlere yazamaz ve site aşağıdakilere benzer mesajlar göstermeye başlar:

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

Sahipliği düzeltin, 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ı farklıdır. Bu nedenle birindeki satırın silinmesi diğerini etkilemez. Her ikisini de kontrol edin:

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

Cron neden wp: not found bildiriyor

Bu, ikinci arızadır. Cron, kullanıcı işlerine çok kısa bir PATH verir: /usr/bin:/bin. WP-CLI, bu listede bulunmayan /usr/local/bin konumuna kurulur. İş başlar, saniyenin çok küçük bir bölümünde başarısız olur ve günlükte tek bir satır kalır:

/bin/sh: 1: wp: not found

Tahmin etmek yerine cron ortamını kendiniz kontrol edin. Geçici olarak şu 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 satırı silin. Bu dosyadaki PATH= değeri, işinizin gerçekten aldığı değerdir.

İki çözüm vardır. 3. adımda olduğu gibi /usr/local/bin/wp mutlak yolunu kullanın. Alternatif olarak PATH değerini crontab'ın en üstünde, tüm iş satırlarının üzerine bir kez tanımlayın:

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

Aynı sorun bir alt katmanda da görülür. wp phar dosyası #!/usr/bin/env php ile başlar. Bu nedenle shell'in php dosyasını da bulabilmesi gerekir. PHP, özel derlemelerde ve control panel derlemelerinde görülebileceği gibi /usr/bin dışında bulunuyorsa şu hata alınır:

/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.

Bir dakikalık aralık ilk sorunu neden yeniden oluşturur

Bu üçüncü hatadır. * * * * * değeri beş dakikadan daha güvenli görünür, ancak yoğun bir sitede başlangıçtaki duruma geri dönülmesine neden olur. Bir çalıştırma aralıktan daha uzun sürerse sonraki çalıştırma ilki hâlâ devam ederken başlar. On dakika sonra her biri kendi belleğini ve veritabanı bağlantısını kullanan on PHP süreci bulunur.

Yığılmayı doğrudan kontrol etmek için:

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

etimes süreç yaşını saniye cinsinden gösterir. Tek satır normaldir. Aralığınızın çok üzerinde yaş değerlerine sahip birden fazla satır, çalıştırmaların üst üste bindiğini gösterir. Küçük bir VPS üzerinde bu durum MySQL Too many connections hatasıyla veya kernel'ın belleği geri kazanmak için PHP'yi sonlandırmasıyla sonuçlanabilir. Bu durum sudo dmesg -T | grep -i 'killed process' ile doğrulanabilir.

WP-CLI, wp-cron.php isteği göndermek yerine etkinlik callback'lerini doğrudan çalıştırır. Bu nedenle WordPress'in yinelenen süreç başlatmayı önlemek için kullandığı 60 saniyelik kilit burada geçerli değildir. Adım 3 girdisindeki flock -n artık çakışmayı önler. Atlanan çalıştırma tasarım gereği hemen ve sessizce sonlanır.

Aralığı, gerçekten bağlı olduğunuz en kısa zamanlamayı temel alarak belirleyin 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ılandır: 09:00 için zamanlanmış bir gönderi en geç 09:05'te yayımlanır. Zaman açısından kritik bir iş bulunmayan siteler için on beş dakika uygundur. Bir dakika, yalnızca gerçekten ihtiyaç duyan mağazalar ve kuyruk tabanlı eklentiler için kullanılmalıdır. Ayrıca önce bir çalıştırmanın birkaç saniye içinde tamamlandığından emin olunmalıdır.

WP-CLI yüklenemiyorsa

Bazı hostlar shell araçlarını engeller. wp-cron.php adresine gönderilen basit bir HTTP isteği, yalnızca tüm web stack üzerinden ilerleyerek aynı kuyruğu çalıştırır:

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

Açıkça belirtmek gerekirse, şu kısıtlar geçerlidir:

• Çalışma, web sunucusu ve PHP-FPM istek zaman aşımlarıyla sınırlıdır. Bu nedenle uzun bir iş tamamlanmadan kesilebilir.
• Sertifika geçerli olmalıdır. Aksi halde curl işlemi SSL certificate problem ile durdurur. Yenileme işlemlerinin çalıştığından emin olmak için nginx üzerinde Certbot kullanılmalıdır.
• Sayfa önbelleği wp-cron.php değerini önbelleğe almamalıdır. Aksi halde cron istekleri önbelleğe alınmış bir yanıt alır ve hiçbir işlem çalışmaz.
• Etkinlik başına çıktı alınamaz. Bu nedenle bir işin çalıştığına ilişkin tek kanıt, oluşturduğu etkidir.

-sS başarılı çalıştırmalarda curl çıktısını bastırırken hataları yazdırmaya devam eder. Bu davranış cron işi için gereklidir.

Sunucunun zamanlanmış görevlerinde başka neler yer almalı?

WordPress kuyruğunu system cron yönetmeye başladıktan sonra sunucunun diğer rutin işlerini de görebileceğiniz aynı yerde tutun. İşletim sistemi güvenlik yamaları, elle yönettiğiniz bir cron satırı yerine otomatik güncellemelere bırakılmalıdır. WordPress eklenti ve tema güncellemeleri farklı bir karardır: Bir crontab içindeki wp plugin update --all canlı bir siteyi gece 3'te, kimse izlemiyorken kolayca kullanılmaz hale getirebilir. Bu nedenle güncellemeleri bilinçli olarak çalıştırın veya bir staging adımının ve yedeğin arkasına alın.

FAQ

Zamanlanmış yazıların yayımlanması için WP-Cron'u devre dışı bırakmak yeterli midir?

Hayır. Kuyruğu başka bir işlem çalıştırdığı sürece zamanlanmış yazılar yayımlanmaya devam eder. DISABLE_WP_CRON yalnızca sayfa yüklemelerinin kuyruğu tetiklemesini engeller. Olaylar önceki gibi zamanlanır. 09:00 için ayarlanan bir yazı, 09:00 sonrasındaki ilk cron çalışmasında yayımlanır. Bu nedenle beş dakikalık aralık, yazıyı en geç 09:05'te yayımlar. Sabiti ayarlayıp cron girdisini eklemezseniz yazı, bir işlem kuyruğu çalıştırana kadar Missed schedule olarak işaretlenmiş listede kalır.

WordPress cron job hangi kullanıcıyla çalıştırılmalıdır?

PHP'nin yazdığı dosyaların sahibi olan kullanıcıyla çalıştırılmalıdır. Varsayılan Ubuntu kurulumunda bu kullanıcı www-data olur. stat -c '%U %G' /srv/www/example.com/wp-content/uploads komutuyla kontrol edin ve sonucu PHP-FPM pool yapılandırmasındaki user = satırıyla karşılaştırın. Job'u root olarak çalıştırmak WP-CLI'nin YIKES hatasıyla durmasına neden olur. --allow-root ile zorla çalıştırılması ise wp-content içinde web sunucusunun sonradan yazamayacağı root sahipli dosyalar oluşturur.

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

Çoğu site için beş dakikada bir çalıştırmak uygundur. Aralığı, gerçekten kullandığınız en kısa zamanlamaya göre belirleyin. Ayrıca bu aralık, tek bir çalışmanın süresinden rahatça uzun olmalıdır. Çalışma süresi, WP-CLI komutunun başına time eklenerek ölçülebilir. Yoğun bir sitede, flock çalışmaları korumadığı sürece bir dakikalık aralıklar işlemlerin üst üste binmesine neden olur.

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

Çünkü bu komut, ziyaretçi tarafından tetiklenen çalıştırmayı test eder. DISABLE_WP_CRON true olarak ayarlandığında hata bildirir. Bu yapılandırmayla çalışan bir sunucuda alınması gereken sonuç budur. Bunun yerine system cron yolunu kontrol edin. /var/log/wp-cron/example.log dosyasını okuyun veya wp cron event schedule ile bir işaretleyici olayı zamanlayın. Sonraki çalışmadan sonra bu olayın wp cron event list içinden kaldırıldığını doğrulayın.

WP-CLI gerekli midir, yoksa wp-cron.php için curl kullanmak yeterli midir?

curl çalışır ve WP-CLI kuramadığınız durumlarda doğru seçenektir. WordPress'i web sunucusu üzerinden yüklediği için daha yavaştır. Ayrıca istek zaman aşımıyla sınırlıdır. WP-CLI olayları web zaman aşımı olmadan komut satırındaki bir PHP sürecinde çalıştırır. Her olay için süresiyle birlikte bir satır yazdırır. Böylece günlük kaydı hangi olayın çalıştığını ve ne kadar sürdüğünü açıkça gösterir.