Zamanlama kontrolü, her genel sayfa isteğinde yüklenen includes/bootstrap.php içinde çalışıyor. options tablosundaki last_schedule_check anahtarı son kontrolün Unix zaman damgasını saklıyor. 60 saniyeden az süre geçtiyse kontrol hiçbir jekcms.alfadizayn.com/tr/blog/jekcms-veritabani-semasi-tasarim-kararlari-ve-odunler" class="auto-link" target="_blank" rel="noopener">veritabanı sorgusu olmadan tamamen atlanıyor. Daha fazla süre geçtiyse JekCMS, posts tablosunu scheduled durumlu ve scheduled_at <= NOW() koşulunu karşılayan satırlar için sorguluyor, durumlarını published olarak güncelliyor ve zaman damgasını yeniliyor.

Ödün: Trafik Bağımlı Doğruluk

Ana dezavantaj öngörülebilir nitelikte: iki saat boyunca hiçbir ziyaretçi gelmezse, bu aralıkta zamanlanmış gönderiler bir sonraki isteğe kadar yayınlanmıyor. Tutarlı trafiği olan siteler için — dakikada en az bir ziyaret — bu pratikte fark edilmiyor. Düşük trafikli sitelerde gece yarısı zamanlanmış gönderiler için saatler süren gecikmeler mümkün. Bu belgelenmiş bir ödün, hata değil.

cron_publish.php: Güvenilir Alternatif

v1.4.0, tools/cron_publish.php'de bağımsız bir yayın betiği sunuyor. Sunucunuzun crontab'ına ekleyin: */5 * * * * php /path/to/jekcms/tools/cron_publish.php. Betik kontrol aralığı içinde çalıştığında, ziyaretçi tetiklemeli kontrol işlevsiz kalıyor — son zaman damgasını tespit ediyor ve atlıyor. İki mekanizma çakışma olmadan bir arada var oluyor; cron betiği çalışırken ziyaretçi tetiklemeli sistem her ikisinin de birbirini engellememesi için akıllıca koordine ediliyor.

Gecikme Pencerenizi Ölçmek

Gerçek gecikme riskinizi sunucu erişim loglarından tahmin edebilirsiniz. Son 30 gün boyunca saat başına benzersiz istek sayısını hesaplayın. Her saat en az bir istek gösteriyorsa maksimum zamanlama gecikmeniz 60 saniyedir.

En sessiz saatleriniz — genellikle yerel saat 02:00 ile 06:00 arası — sıfır istek gösteriyorsa, bu saatler risk pencerenizi temsil eder. Günlük 500 ziyaret ortalaması olan bir site genellikle gece boyunca 15 ile 40 dakikalık boşluklar yaşar. Günlük 2.000+ ziyareti olan siteler neredeyse hiç 5 dakikadan uzun boşluk yaşamaz.

Kontrol Mekanizması Dahili Olarak Nasıl Çalışır

Dahili akış, veritabanı yükünü en aza indirmek için tasarlanmış hassas bir sıra izler:

// includes/bootstrap.php (basitleştirilmiş)
$lastCheck = (int) get_option('last_schedule_check');
$now = time();

if ($now - $lastCheck < 60) {
 return; // Atla - çok yakın zamanda kontrol edildi
}

// Atomik zaman damgası güncellemesi
update_option('last_schedule_check', $now);

// Bekleyen tüm gönderileri tek sorguda yayınla
$db->execute(
 "UPDATE posts SET status = 'published',
 published_at = NOW()
 WHERE status = 'scheduled'
 AND scheduled_at <= NOW()"
);

// Yeni içerik için sayfa önbelleğini temizle
Cache::flush('page');

Zaman damgası güncellemesi, yayın sorgusundan önce gerçekleşir. Bu, iki eşzamanlı ziyaretçinin 60 saniyelik kontrolü geçip yayın sorgusunu iki kez çalıştırmasını önler. İkinci istek sıfır satır güncelleyecektir ancak koruma bu gereksiz sorguyu tamamen önler.

Yayın Sonrası Önbellek Temizleme

Zamanlanmış gönderiler yayınlandığında sayfa önbelleği temizlenir, böylece ziyaretçiler yeni içeriği hemen görür. Bu adım olmadan önbelleğe alınmış bir ana sayfa 300 saniyeye kadar (varsayılan sayfa önbelleği TTL) eski içeriği gösterebilir. Temizleme yalnızca sayfa düzeyindeki önbellekleri hedefler.

Cron Görevini Yapılandırma

Kurulum barındırma ortamına göre değişir. SSH erişimi olan standart bir Linux sunucuda:

# Crontab düzenleyiciyi aç
crontab -e

# Bu satırı ekle (her 5 dakikada)
*/5 * * * * php /var/www/html/jekcms/tools/cron_publish.php

# Girişi doğrula
crontab -l

5 dakikalık aralık pratik bir varsayılandır. Gerçek zamanlıya yakın yayına ihtiyaç duyan haber siteleri için her dakikaya düşürün (* * * * *). Haftalık yayın takvimi olan bloglar için 15 dakika yeterlidir. Kısa aralıkların performans maliyeti yoktur — bekleyen gönderi olmadığında betik 10 milisaniyenin altında tamamlanır.

Cron Yürütmesini İzleme

Cron betiği her çalışmayı logs/cron_publish.log dosyasına zaman damgası ve yayınlanan gönderi sayısıyla kaydeder. Sağlıklı bir log şöyle görünür:

[2025-12-01 14:05:01] Kontrol tamamlandi. 0 gonderi yayinlandi.
[2025-12-01 14:15:01] Kontrol tamamlandi. 2 gonderi yayinlandi.

Log 15 dakikadan fazla giriş göstermiyorsa cron görevi durmuş demektir. Log dosyasının son değişiklik zamanını kontrol eden günlük bir izleme betiği kurun.

Cron Erişimi Olmayan Paylaşımlı Hosting

Özel cron görevlerini kısıtlayan paylaşımlı hosting ortamları, HTTP tabanlı harici bir cron servisi kullanarak /tools/cron_publish.php'i HTTP üzerinden çağırabilir (cron-job.org ücretsiz katman sunuyor). Betik bir token kontrolü içeriyor: ortam dosyanızda CRON_SECRET'ı ayarlayın; betik eşleşen X-Cron-Secret başlığını içermeyen istekleri reddediyor.

Harici Cron Servisi Seçenekleri

  • cron-job.org — Ücretsiz katman, özel HTTP başlıklarıyla 60 saniyeye kadar aralıkları destekler. Cron URL'nizi X-Cron-Secret başlığıyla hedefleyen bir görev ekleyin.
  • UptimeRobot — Öncelikle izleme servisi, ancak HTTP kontrolü cron uç noktasını yan etki olarak tetikler. Aralığı 5 dakika olarak ayarlayın.
  • n8n veya Zapier — Zaten bir otomasyon platformu kullanıyorsanız, altyapınızı merkezileştirmek için zamanlanmış bir HTTP istek düğümü ekleyin.

Güvenilir Zamanlama İçin Pratik İpuçları

  • Önbellek gecikmeleri ve kontrol aralıklarını hesaba katmak için gönderileri en az 10 dakika ileriye zamanlayın
  • Birden fazla gönderiyi aynı dakikaya zamanlamak yerine 5 dakika arayla planlayın
  • Yaklaşan yayınları bir bakışta doğrulamak için yönetim panelindeki "Zamanlanmış Gönderiler" widget'ını kullanın
  • Zamana duyarlı içerik için güvenmeden önce kurulumunuzu özel bir gönderiyle test edin
  • Aynı sunucudaki her JekCMS sitesinin kendi cron girişine ihtiyacı var — zamanlama mekanizmasını paylaşmazlar
  • Sistem, config/config.php dosyasındaki TIMEZONE sabitiyle yapılandırılan saat dilimlerini kullanır