WordPress’te wp-cron.php Yerine Gerçek Cron Kullanmak

WordPress’te wp-cron Neden Sorun Olabiliyor?

WordPress varsayılan olarak klasik Linux zamanlayıcısı cron yerine, kendi içinde çalışan bir taklit mekanizma kullanır: wp-cron.php. Bu dosya, sitenize her istek geldiğinde tetiklenir ve zamanlanmış işleri (zamanlanmış yazılar, e-posta gönderimleri, WooCommerce sipariş işlemleri, stok güncellemeleri vb.) çalıştırmaya çalışır. Küçük ve az trafikli sitelerde bu yaklaşım “idare eder”; ancak trafik büyüdükçe, WooCommerce gibi yoğun arka plan işlerine sahip e-ticaret sitelerinde hem performans hem de tutarlılık tarafında ciddi problemler ortaya çıkmaya başlar.

DCHost tarafında çok sayıda WordPress ve WooCommerce sitesini incelerken, özellikle şu iki uç senaryoda wp-cron kaynaklı sorunları hep gördük:

• Çok az trafik: Cron tetiklenmediği için WooCommerce kuyruk işleri çalışmıyor, kargolama entegrasyonları gecikiyor, abonelik yenilemeleri aksıyor.
• Çok fazla trafik: Her istekte wp-cron denemesi sunucuyu yoruyor, PHP süreçleri artıyor, TTFB yükseliyor ve kampanya dönemlerinde site gözle görülür şekilde yavaşlıyor.

Bu yazıda, wp-cron.php yerine gerçek cron kullanarak hem trafiği hem de sunucu kaynaklarını nasıl rahatlatabileceğinizi; WooCommerce siparişlerinin, zamanlanmış görevlerin ve bakım işlerinin nasıl daha güvenilir ve öngörülebilir hale getirileceğini adım adım ele alacağız. Temel düzeyde bir kurulum anlatımına zaten WordPress’te wp-cron devre dışı bırakma ve gerçek cron job kurulum rehberimizde değinmiştik; burada daha derine inip, trafik, performans ve WooCommerce özelinde doğru stratejiyi konuşacağız.

wp-cron Nasıl Çalışır ve Neden Yetersiz Kalır?

Önce problemi netleştirelim. WordPress’te zamanlanmış görevler wp_cron() fonksiyonu üzerinden yönetilir ve bu fonksiyon da wp-cron.php dosyası tarafından tetiklenir. Varsayılan davranış şöyledir:

• Bir ziyaretçi siteye geldiğinde WordPress, en son wp-cron çalıştırma zamanına bakar.
• Gerekliyse, arka planda wp-cron.php dosyasına HTTP isteği gönderir (loopback request).
• Bu istek, veritabanındaki zamanlanmış olayları kontrol eder ve zamanı gelenleri çalıştırır.

Bu mimarinin başlıca sorunları:

• Yük altında gereksiz PHP süreçleri: Her istek, wp-cron’u tetiklemeye çalışarak fazladan bir PHP süreci ve veritabanı sorgusu üretebilir.
• Düşük trafikte çalışmayan cron: Sitenize kimse girmiyorsa wp-cron da tetiklenmez; zamanlanmış görevler saatlerce, hatta günlerce gecikebilir.
• Cache ve CDN ile çakışmalar: Bazı durumlarda reverse proxy, WAF veya güvenlik eklentileri wp-cron.php isteklerini engelleyebilir; cron fiilen çalışmaz.
• WooCommerce kuyrukları: WooCommerce, Action Scheduler üzerinden pek çok arka plan işini wp-cron’a bağlar. Cron güvenilir değilse, sipariş sonrası e-posta, fatura, stok, entegrasyon çağrıları gecikir.

Sonuç: Trafik arttıkça performans kaybı; trafik azaldıkça işlerin hiç çalışmaması gibi iki uç sorunla karşılaşırsınız. Çözüm, buradaki mantığı tersine çevirmek: trafiğe göre tetiklenen cron yerine, işletim sistemi seviyesinde çalışan gerçek cron kullanmak.

Gerçek Cron Kullanmanın Sağladığı Avantajlar

Linux veya BSD tabanlı sistemlerde cron, crond servisi tarafından yönetilir ve belirli zaman aralıklarında komutları çalıştırır. Biz WordPress özelinde, bu mekanizmayı wp-cron.php veya wp-cli üzerinden WordPress cron olaylarını tetiklemek için kullanacağız.

Gerçek cron’a geçtiğinizde elde edeceğiniz başlıca kazançlar:

• Öngörülebilirlik: “Saat başı yedek al”, “her dakika WooCommerce kuyruklarını kontrol et” gibi net kurallarınız olur. Trafik gelse de gelmese de işler çalışır.
• Performans: Her HTTP isteğinde cron denemesi yapmak zorunda kalmazsınız; cron ayrı bir süreç olarak, planlı şekilde çalışır. Özellikle yoğun WooCommerce sitelerinde CPU ve I/O yükü anlamlı ölçüde düşer.
• Daha az hata ve zaman aşımı: Cron’u PHP CLI üzerinden tetiklerseniz, web sunucusunun timeout ve limitlerinden bağımsız çalıştırabilirsiniz.
• İzlenebilirlik: Çıktıları log’lara yönlendirerek cron’un gerçekten çalışıp çalışmadığını, sürelerini ve potansiyel hataları takip edebilirsiniz.

Genel cron kullanımına dair daha ileri seviye ipuçları için, sunucu tarafında zamanlanmış görevleri tasarlarken faydalı olacak Linux crontab en iyi uygulamalar rehberimize de göz atabilirsiniz.

Hangi Siteler Mutlaka Gerçek Cron’a Geçmeli?

Her WordPress sitesinin gerçek cron’a geçmesi uzun vadede mantıklı; fakat bazı tip sitelerde bu geçiş kritik seviyede önemli:

1. WooCommerce ve diğer e-ticaret siteleri

WooCommerce, zamanlanmış görevler konusunda heavily cron’a yaslanır:

• Sipariş sonrası e-posta ve SMS bildirimleri
• Stok azaltma, stok kritik eşik uyarıları
• Abonelik yenilemeleri ve periyodik ödemeler
• Üçüncü parti entegrasyon (ERP, kargo, muhasebe vb.) kuyrukları

Bu yüzden ciddi trafik alan veya iş kritik sipariş akışına sahip WooCommerce mağazalarında wp-cron’un aksaması, doğrudan gelir kaybına ve operasyonel kaosa yol açabiliyor. WooCommerce ile yoğun çalışan siteler için hazırladığımız WooCommerce kapasite planlama rehberi ile birlikte, bu yazıda anlattığımız cron optimizasyonlarını birlikte düşünmeniz çok daha sağlıklı bir mimari sağlar.

2. Yoğun trafikli blog, haber ve içerik siteleri

Binlerce, on binlerce günlük oturumu olan sitelerde her istekte wp-cron kontrolü yapmak:

• Gereksiz ekstra PHP süreçleri
• Yüksek TTFB
• Cache hit oranlarında düşüş

gibi sorunlara yol açar. Özellikle kampanya ve trend dönemlerinde ani trafik patlamaları bekliyorsanız, bu tür sitelerde de vakit kaybetmeden gerçek cron’a geçmenizi öneririz.

3. Üyelik (membership), LMS ve abonelik tabanlı siteler

Üyelik bitişleri, periyodik faturalar, kurs erişim süreleri, otomatik hatırlatma e-postaları gibi işlerin tümü cron ile takip edilir. Özellikle LMS türü projelerde (örneğin Moodle, LearnPress vb.) cron güvenilir değilse, öğrencilerin erişimi doğru zamanda açılıp kapanmayabilir. Bu tip projeler için altyapı planlarken, LMS performans rehberimizde paylaştığımız ölçeklendirme önerilerini gerçek cron ile birleştirmek uzun vadede sizi kurtarır.

Adım 1: wp-cron’u Güvenli Şekilde Devre Dışı Bırakmak

Gerçek cron’a geçerken yapılacak ilk iş, WordPress’in kendi kendini tetikleme alışkanlığını bırakmasını sağlamak. Bunun için wp-config.php dosyanıza aşağıdaki sabiti eklemeniz yeterli:

define( 'DISABLE_WP_CRON', true );

Dikkat etmeniz gereken noktalar:

• Bu satırı, mümkünse /* That's all, stop editing! Happy publishing. */ satırının hemen üstüne ekleyin.
• Yazımı birebir doğru olmalı; fazladan boşluk veya yanlış tırnak kullanmayın.
• Bu satırı eklediğiniz andan itibaren, gerçek cron kurulu değilse zamanlanmış işleriniz tamamen durur. O yüzden bu değişikliği, gerçek cron job’unu tanımlamaya çok yakın bir anda yapın.

Bu adımın temel mantığını ve olası hata senaryolarını daha detaylı görmek isterseniz, aşama aşama ekran görüntüleriyle ilerlediğimiz wp-cron devre dışı bırakma rehberimizi inceleyebilirsiniz.

Adım 2: Gerçek Cron ile wp-cron.php’yi Tetiklemek

Şimdi sıra, işletim sistemi seviyesinde çalışan gerçek cron ile WordPress cron olaylarını tetiklemeye geldi. Burada iki ana yaklaşım var:

• HTTP üzerinden tetikleme: curl veya wget ile wp-cron.php’ye istek atmak
• PHP CLI üzerinden tetikleme: PHP yorumlayıcısını doğrudan komut satırından çalıştırmak veya wp-cli kullanmak

Paylaşımlı hosting (cPanel / DirectAdmin) üzerinde cron kurulumu

DCHost paylaşımlı hosting veya reseller paketlerinde, kontrol panelinizde bulunan “Cron Jobs” ya da “Zamanlanmış Görevler” menüsünden gerçek cron job’lar tanımlayabilirsiniz. Yaygın senaryo için örnek bir cron kaydı:

*/5 * * * * /usr/bin/php -q /home/KULLANICI_ADI/public_html/wp-cron.php > /dev/null 2>&1

Burada:

• */5 * * * * → Cron’un her 5 dakikada bir çalışacağını gösterir.
• /usr/bin/php → Sunucudaki PHP CLI yolu (DCHost ortamlarında yol değişiklik gösterebilir, panelde belirtilen yolu kullanın).
• /home/KULLANICI_ADI/public_html/wp-cron.php → Sitenizin ana dizinindeki wp-cron.php dosyasının yolu.
• > /dev/null 2>&1 → Çıktıyı çöpe yönlendirerek gereksiz e-posta veya log birikimini engeller.

Alternatif olarak HTTP üzerinden tetiklemek isterseniz:

*/5 * * * * curl -s https://alanadiniz.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Ancak mümkünse PHP CLI yolunu tercih etmenizi öneririz; böylece:

• Web sunucusunun timeout ve limitlerinden bağımsız çalışırsınız.
• WAF, rate limit, CDN gibi katmanlar cron isteğine karışmaz.
• Gerektiğinde farklı PHP sürümü kullandırmak daha esnek olur.

VPS veya dedicated sunucuda cron kurulumu (SSH ile)

VPS veya fiziksel sunucu kullanan projelerde (örneğin DCHost VPS/dedicated platformları) SSH üzerinden doğrudan kendi crontab’inizi düzenleyebilirsiniz:

crontab -e

Ardından örnek bir satır ekleyin:

* * * * * /usr/bin/php -d max_execution_time=300 /var/www/alanadiniz.com/public/wp-cron.php > /var/log/wp-cron.log 2>&1

Burada ayrıca -d max_execution_time=300 ile PHP CLI için özel bir maksimum çalışma süresi atayıp, çıktıları da /var/log/wp-cron.log dosyasına yazarak hataları izleyebilirsiniz.

Eğer sitenizde WP-CLI kuruluysa, cron olaylarını sadece zamanı gelmiş işler için tetiklemek adına şu yaklaşımı da kullanabilirsiniz:

* * * * * cd /var/www/alanadiniz.com/public && /usr/bin/wp cron event run --due-now --path=/var/www/alanadiniz.com/public > /dev/null 2>&1

Büyük WooCommerce sitelerinde WP-CLI ile olay bazlı tetikleme hem daha kontrollü, hem de daha performanslı bir çözüm olur.

WooCommerce İçin Doğru Cron Sıklığı Nasıl Seçilir?

En çok gelen sorulardan biri şu: “Cron’u kaç dakikada bir çalıştırmalıyım?” Cevap, sitenizin tipi ve arka planda çalışan işlerin hacmine göre değişiyor.

Düşük trafikli küçük mağazalar

• Günlük sipariş: 0–20 arası
• Ağır entegrasyon yok, temel e-posta ve stok işlemleri

Genellikle 5 dakikada bir cron çalıştırmak yeterli olur:

*/5 * * * * /usr/bin/php /.../wp-cron.php > /dev/null 2>&1

Orta ölçekli mağazalar

• Günlük sipariş: 20–300 arası
• E-posta otomasyonları, kargo/muhasebe entegrasyonları, kuyruk işleri mevcut

Burada 1–2 dakikada bir cron çalıştırmak, kuyrukların birikmesini önler:

*/2 * * * * /usr/bin/php /.../wp-cron.php > /dev/null 2>&1

Yüksek hacimli WooCommerce siteleri

• Günlük sipariş: 300+ (kampanya dönemlerinde çok daha fazla)
• Çoklu entegrasyonlar, segmentli e-posta, yoğun Action Scheduler kuyrukları

Bu tip yapılarda genellikle iki katmanlı bir yaklaşım öneriyoruz:

1. Her dakika temel cron tetikleme:
   * * * * * /usr/bin/php /.../wp-cron.php > /dev/null 2>&1
2. Yoğun ve uzun süren işleri, WooCommerce Action Scheduler veya ayrı bir queue işçisi ile ayırmak. Bu tür arka plan işçilerini VPS üzerinde arka plan işleri ve kuyruk yönetimi rehberimizde anlattığımız yaklaşıma benzer şekilde, ayrı PHP-FPM havuzları veya CLI süreçleri ile yönetmek mümkündür.

Burada amaç; ödeme sonrasında müşterinin beklemesini gerektirmeyen işlemleri (muhasebe entegrasyonu, raporlama vb.) cron/queue tarafına kaydırıp, ödeme adımını olabildiğince hızlı tutmaktır.

systemd Timers mı, Klasik Cron mu?

Modern Linux dağıtımlarında (özellikle VPS ve dedicated sunucularda) klasik cron yerine systemd timer kullanmak da güçlü bir seçenek. systemd timer’lar şunları sağlar:

• Daha esnek zamanlama (boot’tan 5 dakika sonra gibi)
• Yerleşik loglama ve yeniden başlatma politikaları
• Servis bağımlılıklarını daha iyi yönetme

Örneğin bir WordPress site için /etc/systemd/system/wp-cron.service ve /etc/systemd/system/wp-cron.timer tanımlayıp, wp-cron’u klasik cron’dan tamamen bağımsız yönetebilirsiniz. Bu konuyu derinlemesine ele aldığımız “cron mu systemd timer mı?” rehberimiz, hangi senaryoda hangisini kullanmanız gerektiğini karar vermenize yardımcı olacaktır.

Performans ve Güvenilirlik İçin İleri Seviye İpuçları

1. Cron çıktısını log’layın ve düzenli kontrol edin

Özellikle WooCommerce sitelerinde cron, siparişlerin arka plan hayat damarlarından biridir. Aşağıdaki gibi bir yapı:

* * * * * /usr/bin/php /.../wp-cron.php >> /var/log/wp-cron.log 2>&1

Size şu avantajları sağlar:

• Cron’un gerçekten çalışıp çalışmadığını görebilirsiniz.
• Hangi cron çalışmasının ne kadar sürdüğünü kolayca analiz edebilirsiniz.
• “Allowed memory size exhausted” veya veritabanı hatalarını erken yakalarsınız.

2. Zamanlanmış olayları periyodik olarak temizleyin

Yıllarca çalışan sitelerde wp_options, wp_actionscheduler_actions gibi tablolar kolayca şişebilir. Bu da her cron çağrısında gereksiz yük oluşturur. Bu konuyu detaylı incelediğimiz WordPress veritabanı optimizasyon rehberimiz, uzun süredir çalışan WooCommerce siteleri için özellikle faydalıdır.

3. Cron’u kilitleyin (locking) ve çakışmaları engelleyin

Yoğun sitelerde, bazen önceki cron çalışması bitmeden bir sonraki tetiklenebilir. Bu durum:

• Aynı görevin birden fazla kez çalışmasına
• Veritabanında kilitlenmelere ve deadlock’lara

neden olabilir. Linux tarafında flock kullanarak bunu önleyebilirsiniz:

* * * * * flock -n /tmp/wp-cron.lock /usr/bin/php /.../wp-cron.php > /dev/null 2>&1

Bu komut, /tmp/wp-cron.lock kilidi alınamıyorsa (yani önceki cron hâlâ çalışıyorsa) yeni bir cron çalıştırmaz.

4. Çok siteli (multisite) yapılarda ayrı cron stratejisi

WordPress Multisite kullanımında tek bir codebase olsa da, her site için ayrı cron olayları olabilir. Genel yaklaşım:

• Küçük ağlarda tek bir wp-cron tetiklemesi genellikle yeterlidir.
• Çok büyük ağlarda (örneğin 100+ site) kritik siteler için ayrı cron tanımlamayı düşünebilirsiniz.

Multisite mimarilerinde cron tasarımını, WordPress Multisite mi ayrı kurulumlar mı? yazımızda anlattığımız mimari kararlarla birlikte ele almak en sağlıklısıdır.

DCHost Altyapısında Cron ve WordPress İçin Önerilen Yol Haritası

DCHost olarak WordPress, WooCommerce ve özel PHP uygulamaları barındıran müşterilerimiz için pratik bir yol haritası öneriyoruz:

1. Küçük projeler ve başlangıç aşaması
   Paylaşımlı hosting kullanıyorsanız, kontrol panelinizdeki Cron Jobs menüsünden 5 dakikada bir çalışacak bir PHP CLI tabanlı cron tanımlayın. DISABLE_WP_CRON ekleyip wp-cron’u devre dışı bırakın.
2. Büyüyen WooCommerce mağazaları
   Trafiğiniz ve sipariş hacminiz arttıkça, DCHost üzerinde VPS veya daha güçlü dedicated sunucuya geçip, wp-cron’u her dakika tetikleyin. Ağır işleri mümkün olduğunca kuyruk/arka plan süreçlerine taşıyın.
3. Kritik SLA’li projeler
   PCI DSS, yüksek erişilebilirlik veya ciddi SLA beklentisi olan projelerde, systemd timer tabanlı cron, merkezi loglama ve gerektiğinde ayrılmış arka plan işçileri ile daha da güçlü bir mimari tasarlayın.

Bu yol haritasını uygularken; CPU, RAM ve disk IOPS ihtiyacınızı netleştirmek için yeni web sitesi için CPU, RAM ve trafik hesaplama rehberimizden de faydalanmanız karar vermeyi kolaylaştıracaktır.

Özet: wp-cron’dan Gerçek Cron’a Geçmek Neden Kritik?

WordPress’in kendi cron sistemi, özellikle küçük ve hobi projeleri için hızlı bir başlangıç sağlar; fakat işin içine ciddi trafik, WooCommerce siparişleri, entegrasyonlar ve SLA beklentileri girdiğinde bu yaklaşım yeterli olmuyor. wp-cron, trafiğe bağımlı çalıştığı için az trafikte gecikmelere, çok trafikte ise gereksiz yük ve yavaşlamaya neden oluyor.

Gerçek cron’a geçtiğinizde:

• Zamanlanmış görevleriniz trafiğe bağlı olmadan, dakikası dakikasına çalışır.
• WooCommerce sipariş akışınız, stok güncellemeleriniz ve entegrasyonlarınız çok daha öngörülebilir hale gelir.
• Sunucu kaynaklarınızı daha verimli kullanır, TTFB ve genel yanıt sürelerinde gözle görülür iyileşme sağlarsınız.
• İş yükünü gerektiğinde ayrı kuyruk işçilerine ve PHP-FPM havuzlarına dağıtarak mimarinizi büyütmek çok daha kolaylaşır.

Eğer şu an sitenizde zamanlanmış görevler gecikiyorsa, WooCommerce sipariş e-postaları düzensiz geliyorsa, kampanyalarda site belirli saatlerde yavaşlıyorsa; ilk bakmanız gereken yerlerden biri mutlaka cron mimariniz olmalı. DCHost altyapısında barınan projeleriniz için panel tarafında cron tanımlamadan, VPS/dedicated sunucularda systemd timer’lara kadar bu sürecin her adımında size teknik olarak eşlik edebiliriz.

Kendi sitenizde hangi cron stratejisinin daha doğru olacağı konusunda emin değilseniz, mevcut trafiğinizi, sipariş hacminizi ve büyüme planınızı birlikte değerlendirip; hosting paketinden cron yapılandırmasına kadar net ve uygulanabilir bir plan çıkarabiliriz.