Kayıt ol

Tovala Akıllı Fırın Deneyimi: Paket Servisten Daha İyi mi?FortiMail'de Kritik Zero-Day Açığı Aktif Saldırılarda Kullanılıyor Meadow: Sosyal Medyasız Minimalist Telefon Deneyimi California'da Gizli Kayıt Yapan Akıllı Gözlük Yasasına Veto Hello Robot Stretch 4, TechCrunch Disrupt 2026'da Canlı Tanıtılacak

JavaScript devre dışı. Daha iyi bir deneyim için, önce lütfen tarayıcınızda JavaScript'i etkinleştirin.

WP-Cron Nasıl Devre Dışı Bırakılır? Sistem Cronuna Geçiş Rehberi

Mesaj: <blockquote data-quote="Admin" data-source="post: 12846" data-attributes="member: 1"><p><h2>WP-Cron Nasıl Devre Dışı Bırakılır? Sistem Cronuna Geçiş Rehberi</h2><p>WordPress’te ileri bir tarihe zamanladığınız yazıların yayımlanması, güncelleme kontrolleri ve bazı eklentilerin arka plan işlemleri WP-Cron üzerinden yürütülür. Bu sistem, ayrıca bir zamanlayıcı kurmadan birçok işlemin otomatik yapılmasını sağlar.</p><p>Ancak varsayılan WP-Cron çalışma düzeni, siteye gelen isteklere bağlıdır. Ziyaretçi az olduğunda görevler gecikebilir; yoğun ve ağır işlemler bulunan sitelerde ise kaynak kullanımı araştırılması gereken bir konuya dönüşebilir.</p><p>Bu nedenle bazı projelerde görevleri sunucunun sistem cronuyla tetiklemek daha uygun olur. <strong>Amaç, zamanlanmış görevleri kaldırmak değil; onları ziyaretçi trafiğinden bağımsız çalıştırmaktır.</strong></p><p>Bu rehberde geçişin nasıl yapılacağını, cPanel üzerinden cron tanımlamayı ve kurulumun gerçekten çalıştığını doğrulama yöntemlerini anlatacağız.</p><h2>WP-Cron Nedir ve Nasıl Çalışır?</h2><p>WP-Cron, WordPress’in zamanlanmış işlemleri yönetmek için kullandığı mekanizmadır. Zamanlanmış yazıların yayımlanması ve güncelleme kontrolleri, çekirdekteki kullanım örnekleri arasındadır. Eklentiler de kendi görevlerini bu sisteme ekleyebilir.</p><p>Sunucunun sistem cronu belirlenen takvime göre çalışır. Varsayılan WP-Cron ise sürekli çalışan ayrı bir zamanlayıcı değildir. WordPress’e ulaşan istekler, zamanı gelmiş görevlerin kontrol edilmesine fırsat sağlar.</p><p>Örneğin bir yazıyı saat 09.00’a zamanladığınız halde o saatlerde WordPress’i çalıştıran bir istek oluşmazsa, yayımlama işlemi daha sonra tetiklenebilir. Tamamen önbellekten sunulan ziyaretler de her durumda WordPress’i çalıştırmayabilir.</p><p>Burada sık yapılan bir yorum hatası vardır: <strong>Her ziyaret, bütün cron görevlerini yeniden çalıştırmaz.</strong> WordPress zamanı gelen görevleri kontrol eder; çalışma kilidi de gereksiz eş zamanlı tetiklemeleri sınırlamaya yardımcı olur.</p><h2>Sistem Cronuna Geçmek Ne Zaman Mantıklıdır?</h2><p>Aşağıdaki durumlarda geçiş değerlendirilebilir:</p><ul> <li data-xf-list-type="ul">Zamanlanmış yazılar düzenli olarak gecikiyorsa.</li> <li data-xf-list-type="ul">Düşük trafikli bir sitede görevlerin ziyaretçiden bağımsız çalışması gerekiyorsa.</li> <li data-xf-list-type="ul">Arka plan işlemlerinin hangi aralıklarla tetiklendiğini kontrol etmek istiyorsanız.</li> <li data-xf-list-type="ul">Cron çalışmaları sırasında kaynak kullanımı yükseliyorsa.</li> <li data-xf-list-type="ul">Sunucuda bu işleri izleyebileceğiniz ve yönetebileceğiniz bir ortam varsa.</li> </ul><p>Ancak yavaş bir WordPress sitesinde WP-Cron’u hemen suçlamak doğru değildir. Uzun süren veritabanı sorguları, sorunlu bir eklenti veya ağır bir yedekleme görevi de yük oluşturabilir.</p><p>Sistem cronuna geçmek, ağır görevin yaptığı işi azaltmaz. Aynı işlem yine çalışacağı için <strong>tetikleme düzeniyle görevin maliyetini ayrı ayrı değerlendirmek gerekir.</strong></p><h2>Geçiş Öncesinde Hazırlık Yapın</h2><p>Önce mevcut çalışma düzenini inceleyin. Hosting sağlayıcınız veya yönetim aracınız, WordPress için zaten harici bir zamanlayıcı kurmuş olabilir. Böyle bir durumda ikinci bir cron işi eklemek gereksizdir.</p><p>Hazırlık sırasında şu bilgileri belirleyin:</p><ol> <li data-xf-list-type="ol">WordPress’in kurulu olduğu dizin.</li> <li data-xf-list-type="ol">Kullanılacak tetikleme yöntemi.</li> <li data-xf-list-type="ol">Hosting paketinin izin verdiği en kısa cron aralığı.</li> <li data-xf-list-type="ol">Görevlerin kabul edilebilir gecikme süresi.</li> <li data-xf-list-type="ol">Hata çıktılarının nasıl izleneceği.</li> </ol><p>Ayrıca <code class="bbCodeInline">wp-config.php</code> dosyasının bir kopyasını alın. Değişiklikten sonra sözdizimi hatası oluşursa bu kopya geri dönüşü kolaylaştırır.</p><p><strong>Önce dış tetikleyiciyi hazırlayıp test edin, ardından WordPress’in otomatik tetiklemesini kapatın.</strong> WordPress’in resmi sistem zamanlayıcısı rehberi de harici görevin kurulmasını ve sonrasında otomatik tetiklemenin devre dışı bırakılmasını anlatır.</p><h2>1. Adım: Tetikleme Yöntemini Seçin</h2><p>Üç yaygın seçenek vardır:</p><table style='width: 100%'><tr><th>Yöntem</th><th>Çalışma biçimi</th><th>Kontrol edilmesi gereken nokta</th></tr><tr><td><strong>curl</strong></td><td><code class="bbCodeInline">wp-cron.php</code> adresine HTTP isteği gönderir.</td><td>DNS, HTTPS, yönlendirme ve güvenlik kuralları</td></tr><tr><td><strong>wget</strong></td><td>Aynı adrese HTTP isteği gönderebilir.</td><td>Komutun kullanılabilirliği ve hata çıktıları</td></tr><tr><td><strong>WP-CLI</strong></td><td>WordPress görevlerini komut satırından çalıştırır.</td><td>Dosya yolu, PHP ortamı ve kullanıcı izinleri</td></tr></table><h3>WP-Cron Nasıl Devre Dışı Bırakılır? Sistem Cronuna Geçiş Rehberi</h3><p>HTTP yöntemleri, web üzerinden çalışan WordPress ortamını kullanır. WP-CLI ise web sunucusuna istek göndermeden görevleri çalıştırabilir.</p><p>Bununla birlikte WP-CLI’nin her kurulumda kesin olarak daha az bellek harcadığını veya daha hızlı olduğunu söylemek doğru değildir. Eklentilerin davranışı ve yapılan işlemler sonucu etkiler.</p><h2>2. Adım: HTTP Komutunu Hazırlayın</h2><p>curl kullanılabilen bir sunucuda şu örnek değerlendirilebilir:</p><p><code class="bbCodeInline">/usr/bin/curl --fail --silent --show-error --connect-timeout 10 --max-time 120 --output /dev/null 'https://ornek.com/wp-cron.php'</code></p><p>Komutu kullanmadan önce:</p><ul> <li data-xf-list-type="ul"><code class="bbCodeInline">ornek.com</code> yerine kendi alan adınızı yazın.</li> <li data-xf-list-type="ul">WordPress bir alt dizindeyse doğru yolu kullanın.</li> <li data-xf-list-type="ul"><code class="bbCodeInline">/usr/bin/curl</code> yolunu sunucunuzdaki gerçek komut yoluyla doğrulayın.</li> <li data-xf-list-type="ul">Adresin doğrudan doğru HTTPS adresine ulaştığından emin olun.</li> </ul><p>Örneğin WordPress <code class="bbCodeInline">/blog/</code> altında kuruluysa hedef adres şöyle olabilir:</p><p><code class="bbCodeInline">https://ornek.com/blog/wp-cron.php</code></p><p>Komuttaki <code class="bbCodeInline">--silent</code> ilerleme çıktısını kapatırken <code class="bbCodeInline">--show-error</code> hataların görünmesini sağlar. <code class="bbCodeInline">--fail</code>, HTTP hata yanıtlarında başarısızlık bildirilmesine yardımcı olur. <code class="bbCodeInline">--output /dev/null</code> ise yanıt gövdesinin kaydedilmesini engeller.</p><p>Buradaki bağlantı ve toplam istek süreleri örnektir. Kendi ortamınıza göre değerlendirin. HTTP isteğinin tamamlanması, arka plandaki bütün işlemlerin başarıyla bittiğini tek başına kanıtlamaz.</p><h2>3. Adım: cPanel’de Cron İşi Oluşturun</h2><p>cPanel’de <strong>Cron Jobs</strong> bölümünü açın. Menü görünmüyorsa sağlayıcınız bu özelliği hesabınız için kapatmış olabilir.</p><p>Beş dakikalık bir örnek için zaman alanları şöyle doldurulur:</p><table style='width: 100%'><tr><th>Alan</th><th>Değer</th></tr><tr><td>Minute</td><td><code class="bbCodeInline">*/5</code></td></tr><tr><td>Hour</td><td><code class="bbCodeInline">*</code></td></tr><tr><td>Day</td><td><code class="bbCodeInline">*</code></td></tr><tr><td>Month</td><td><code class="bbCodeInline">*</code></td></tr><tr><td>Weekday</td><td><code class="bbCodeInline">*</code></td></tr></table><p></p><p><strong>Command</strong> alanına hazırladığınız curl komutunu yazın ve görevi ekleyin. Komutlarda tam dosya yolunu kullanmak, cron ortamındaki yol farklılıklarından kaynaklanan sorunları azaltır.</p><p>Linux <code class="bbCodeInline">crontab</code> üzerinden işlem yapılıyorsa aynı örnek tek satır olarak yazılabilir:</p><p><code class="bbCodeInline">*/5 * * * * /usr/bin/curl --fail --silent --show-error --connect-timeout 10 --max-time 120 --output /dev/null 'https://ornek.com/wp-cron.php'</code></p><p><strong>cPanel’in zaman alanlarını ayrı dolduruyorsanız </strong><code class="bbCodeInline">[B]*/5 * * * *[/B]</code><strong> kısmını Command alanına tekrar eklemeyin.</strong></p><p>İlk kurulumda hata bildirimlerini takip edin. Komutu terminalde çalıştırabilmek faydalı bir kontroldür; ayrıca görevin panelden otomatik çalıştığını da doğrulamak gerekir.</p><h2>4. Adım: WordPress’in Otomatik Tetiklemesini Kapatın</h2><p>Harici görevin çalıştığını doğruladıktan sonra <code class="bbCodeInline">wp-config.php</code> dosyasını açın.</p><p>Dosyada aynı sabitin daha önce tanımlanıp tanımlanmadığını kontrol edin. Varsa ikinci bir satır eklemek yerine mevcut tanımı düzenleyin:</p><p><code class="bbCodeInline">define( 'DISABLE_WP_CRON', true );</code></p><p>Bu tanım, WordPress’in yüklenmesini başlatan <code class="bbCodeInline">wp-settings.php</code> çağrısından <strong>önce</strong> bulunmalıdır. Standart dosya düzeninde şu yorumun üstüne yerleştirilebilir:</p><p><code class="bbCodeInline">/* That's all, stop editing! Happy publishing. */</code></p><p>Yorum satırının kendisi çalışan kod değildir. Asıl önemli nokta, sabitin WordPress yüklenmeden önce tanımlanmasıdır.</p><p><code class="bbCodeInline">DISABLE_WP_CRON</code>, otomatik tetiklemeyi kapatır. Kayıtlı görevleri silmez; sistem cronunun <code class="bbCodeInline">wp-cron.php</code> üzerinden görevleri çalıştırması için kullanılabilir.</p><h2>WP-CLI ile Alternatif Kurulum</h2><p>WP-CLI bulunan bir sunucuda zamanı gelmiş görevler şu şekilde çalıştırılabilir:</p><p><code class="bbCodeInline">wp --path=/home/kullanici/public_html cron event run --due-now</code></p><p><code class="bbCodeInline">--path</code> WordPress dizinini, <code class="bbCodeInline">--due-now</code> ise zamanı gelmiş görevlerin çalıştırılacağını belirtir.</p><p>Cron tanımında <code class="bbCodeInline">wp</code> yerine sunucunuzdaki doğrulanmış tam çalıştırılabilir dosya yolunu kullanın. Komutu site dosyalarına erişebilen uygun sistem kullanıcısıyla çalıştırın.</p><p>Komut satırındaki PHP sürümü ve yapılandırması, web sitesinin kullandığı PHP ortamından farklı olabilir. Bu nedenle manuel test ve hata kayıtları önemlidir.</p><p>Görevleri çalıştırırken eklentileri atlayan seçenekleri gelişigüzel kullanmayın. İlgili görevlerin işlevleri eklentiler tarafından sağlanıyor olabilir. Ayrıca HTTP ve WP-CLI yöntemlerinden birini ana tetikleyici olarak belirleyin.</p><h2>Cron Kaç Dakikada Bir Çalıştırılmalı?</h2><p>Doğru aralık, işlerin kabul edilebilir gecikmesine ve sunucunun kapasitesine bağlıdır.</p><table style='width: 100%'><tr><th>İhtiyaç</th><th>Değerlendirilebilecek aralık</th></tr><tr><td>Dakikalık hassasiyet gereken işler</td><td>1 dakika, ortam izin veriyorsa</td></tr><tr><td>Birkaç dakikalık gecikme kabul edilen görevler</td><td>5 dakika</td></tr><tr><td>Gecikmeye daha toleranslı işlemler</td><td>10–15 dakika</td></tr></table><p></p><p>Bu tablo zorunlu bir standart değildir. Eklentinin çalışma biçimi ve hosting sınırları ayrıca incelenmelidir.</p><p>Beş dakikada bir çalışan tetikleyicide, bir görev sıradaki çalışmayı bekleyebilir. Sunucu yükü veya işlem hatası varsa gecikme daha da uzayabilir. Sistem cronu, bütün görevlerin tam saniyesinde tamamlanacağını garanti etmez.</p><p>Uzun süren işlerde sonraki çalışmanın öncekiyle çakışmasını önlemek gerekir. cPanel belgeleri de çok sık tanımlanan görevlerin üst üste binerek performansı olumsuz etkileyebileceğini belirtir.</p><h2>WooCommerce Kullanıyorsanız Kuyrukları da İnceleyin</h2><p>WooCommerce ortamında yalnızca standart WP-Cron listesini kontrol etmek yeterli olmayabilir. Bazı arka plan işlemleri <strong>Action Scheduler</strong> üzerinden yönetilir.</p><p>Action Scheduler, WP-Cron ile bağlantılı çalışırken yönetim paneli isteklerinden başlatılan asenkron işlemler gibi başka tetikleme yollarına da sahiptir. Bu nedenle otomatik WP-Cron tetiklemesi kapatıldığında bütün mağaza işlemlerinin aynı şekilde duracağını varsaymayın.</p><p>Bekleyen ve başarısız görevleri inceleyin. Özellikle abonelik, webhook veya e-posta işlemlerinde görevin hata kaydı önemlidir.</p><p>Büyük kuyruklar için Action Scheduler’ın ayrı WP-CLI komutları bulunur. Standart WordPress cron görevlerini çalıştırmakla bu kuyruğu doğrudan yönetmek aynı işlem değildir.</p><h2>Kurulumun Çalıştığı Nasıl Doğrulanır?</h2><p>Özel bir test yazısını birkaç dakika sonrasına zamanlayın. Otomatik tetikleme kapalıyken, sistem cronunun çalışmasını bekleyerek yazının yayımlanıp yayımlanmadığını kontrol edin.</p><p>WP-CLI erişiminiz varsa görev listesini görüntüleyebilirsiniz:</p><p><code class="bbCodeInline">wp --path=/home/kullanici/public_html cron event list</code></p><p>Bu komut zamanlanmış görevlerin listesini verir. Listedeki bir görevin bulunması, son çalışmasının başarılı olduğunu tek başına göstermez.</p><p>Panelden incelemek için WP Crontrol kullanılabilir. Eklenti görevleri görüntüleme, düzenleme ve elle çalıştırma gibi işlevler sunar. Ancak görevi elle çalıştırmak, sunucudaki zamanlayıcının doğru kurulduğunu kanıtlamaz.</p><h2>Sık Karşılaşılan Sorunlar</h2> <table style='width: 100%'><tr><th>Belirti</th><th>Kontrol edilecek nokta</th></tr><tr><td>HTTP isteği 403 dönüyor</td><td>WAF, erişim kuralı veya IP kısıtlaması</td></tr><tr><td>Komut bulunamıyor</td><td>Çalıştırılabilir dosyanın tam yolu</td></tr><tr><td>WP-CLI WordPress’i bulamıyor</td><td><code class="bbCodeInline">--path</code> ve dosya izinleri</td></tr><tr><td>Görevler gecikiyor</td><td>Cron aralığı, kuyruk ve sunucu yükü</td></tr><tr><td>Yalnızca bir görev başarısız</td><td>İlgili eklentinin hata kaydı</td></tr><tr><td>Görevler üst üste biniyor</td><td>Çalışma süresi ve eş zamanlılık kontrolü</td></tr></table><p></p><p>Güvenlik kuralı sorunu varsa bütün korumayı kapatmak yerine ilgili isteğin neden engellendiğini araştırın.</p><p>İlk kurulumda <code class="bbCodeInline">>/dev/null 2>&1</code> kullanmak hata mesajlarını da gizler. Sessiz çalışma tercih edilecekse hataları ayrıca izleyebileceğiniz bir kayıt düzeni oluşturun.</p><h2>WordPress 6.9’daki Değişiklik Ne Sağladı?</h2><p>WordPress 6.9’da normal cron tetiklemesi <code class="bbCodeInline">init</code> yerine <code class="bbCodeInline">shutdown</code> aşamasına taşındı. Resmi performans notları, bu değişikliğin cron başlatılırken oluşabilen TTFB gecikmesini azaltmayı hedeflediğini açıklar.</p><p>Bu iyileştirme, WP-Cron’u sürekli çalışan bir sistem zamanlayıcısına dönüştürmez. Trafikten bağımsız tetikleme ihtiyacı bulunan sitelerde harici zamanlayıcı yine değerlendirilebilir.</p><p></p><h2>Sıkça Sorulan Sorular</h2><h3>WP-Cron’u kapatmak siteyi kesin hızlandırır mı?</h3><p>Hayır. Sonuç, cronun mevcut yüküne ve görevlerin maliyetine bağlıdır. Öncesi ve sonrası ölçüm yapılmalıdır.</p><h3>Yalnızca <code class="bbCodeInline">DISABLE_WP_CRON</code> eklemek yeterli mi?</h3><p>Görevlerin çalışmaya devam etmesi için doğrulanmış bir dış tetikleyici gerekir. Harici zamanlayıcı olmadan otomatik tetiklemeyi kapatmayın.</p><h3><code class="bbCodeInline">wp-cron.php</code> dosyasını silebilir miyim?</h3><p>Sistem cronuna geçiş için dosyayı silmeniz gerekmez. HTTP yöntemi bu dosyayı kullanır.</p><h3>Kurulumdan sonra boş sayfa görmek normal mi?</h3><p><code class="bbCodeInline">wp-cron.php</code> görünür bir içerik üretmeyebilir. Boş yanıt, görevlerin başarılı çalıştığını tek başına göstermez.</p><h3>Sorun çıkarsa nasıl geri dönerim?</h3><p>Eklediğiniz <code class="bbCodeInline">DISABLE_WP_CRON</code> tanımını kaldırın veya mevcut değerini <code class="bbCodeInline">false</code> yapın. Harici cron işini de durdurup görevlerin çalışma durumunu yeniden kontrol edin.</p><h3>Cron aralığını kısaltmak bütün gecikmeleri çözer mi?</h3><p>Hayır. Hatalı veya ağır bir görev daha sık tetiklendiğinde yük artabilir. Önce gecikmenin kaynağını bulun.</p></blockquote><p></p>