Cron Kurulumu Derinlemesine

Zamanlanmış Görevler motoru anlatıyor. Bu sayfa işin eli kirlenen yarısı: her barındırma panelinde girilecek komut, her panelin kurduğu tuzak ve "herhâlde çalışıyordur" demek yerine çalıştığını kanıtlama yolu.

Bir şey kurmadan önce bunu okuyun

Zamanlanmış yayın hiç cron kurmadan da çalışıyor. jekcms önbellek klasöründe bir "sıradaki işin zamanı" damgası tutar ve motoru, sayfa yanıtı ziyaretçiye teslim edildikten hemen sonra koşturur. 14:37'ye kurulmuş bir yazı, 14:37 ya da sonrasındaki ilk ziyarette yayına girer ve o ziyaretçi hiçbir şey beklemez. Normal bir istekte mekanizmanın tüm maliyeti bir iki küçük dosya okumasıdır; veritabanına hiç gidilmez.

Yani soru "cron'suz çalışır mı" değil, "bana hangi hassasiyet lazım". Gerçek cron üç şey kazandırır. Trafiği az bir sitede dakikası dakikasına zamanlama. Kimse siteyi gezmezken de dönen arka plan işleri: bülten grupları, haftalık Search Console çekimi, zamanlanmış yedekler. Bir de müşteri "yayın ziyaretçiye mi bağlı" diye sorduğunda verecek net bir cevap.

Seçim hakkınızın olmadığı tek durum, kendi panel oturumlarınız dahil hiç trafiği olmayan bir sitedir. Siteyi kimse çağırmıyorsa hiçbir şey ateşlenemez.

Gerçek cron kurduğunuzda jekcms bunu fark eder: komut satırı turu bir tazelik bayrağı bırakır ve ziyaretçi tetikli zamanlayıcı kendini sonraki yirmi dakika boyunca tamamen kapatır - her turda yenilenir. Yapılandırmanızda JEK_DISABLE_PSEUDO_CRON sabitini true tanımlayarak kalıcı olarak da kapatabilirsiniz.

Ne zamanlanacak

Tek komut, dakikada bir, kurulum kökündeki cron.php'yi hedefleyerek:

* * * * * /usr/bin/php /home/KULLANICINIZ/public_html/cron.php >/dev/null 2>&1

Trafiği düşük bir sitede beş dakika kabul edilebilir; bedeli zamanlanmış yayında görünür kaymadır - 10:00'a kurulmuş bir yazı 10:04'te çıkabilir. Daha uzun aralıklarda, sağlayıcı hız sınırlarının altında kalmak için bilerek tur başına tek öğe işleyen AI toplu analiz işçisi kullanılamayacak kadar yavaşlar.

PHP'nin yolu sunucudan sunucuya değişir. Kabuk erişiminiz varsa which php deneyin; yoksa /usr/local/bin/php ve /opt/cpanel/ea-php82/root/usr/bin/php paylaşımlı sunucuların çoğunu kapsar. Yanlış ikiliyi kullanmak, bir cron görevinin "koşup" hiçbir şey yapmamasının bir numaralı sebebidir.

cPanel

Advanced → Cron Jobs → Add New Cron Job. Hazır ayarlardan Once per minute seçin ve yukarıdaki komutu kendi yollarınızla yapıştırın.

>/dev/null 2>&1 burada önemlidir: onsuz cPanel çıktıyı her dakika size e-postalar.

Hostinger hPanel

Advanced → Cron Jobs. Komut aynı, ama Ağustos 2026'da Hostinger üzerinde ölçülmüş bir uyarıyla: hPanel komutu her zaman bir kabuk üzerinden çalıştırmaz, dolayısıyla >/dev/null 2>&1 her zaman yönlendirme olarak yorumlanmaz. Böyle olduğunda o parçalar programa sıradan argüman olarak geçer. PHP onları yok sayar ve cron.php doğru çalışmaya devam eder, ama çıktı susturulmaz ve bildirim adresi dolar.

Kurulumdan sonra dakika başı posta yağmuru görüyorsanız, komuttan yönlendirmeyi çıkarın ve bunun yerine panelde cron görevinin bildirim adresini boş bırakın. jekcms'in kendi dağıtım betikleri de bu yüzden panelin yönlendirmesine güvenmez, log'unu kendisi dosyaya yazar.

Plesk

Tools & Settings → Scheduled Tasks → Add Task, görev türü Run a command:

php /var/www/vhosts/alanadiniz.com/httpdocs/cron.php

Run değerini her dakika, Send notifications değerini "Only on errors" yapın; yoksa Plesk size aralıksız posta atar. Kaydettikten sonra bir kez Run Now'a basın - komutun çalıştığını, bir dakika bekleyip öğrenmeden önce doğrular.

DirectAdmin

Advanced Features → Cron Jobs, cPanel ile aynı crontab söz dizimi:

* * * * * /usr/bin/php /home/KULLANICI/domains/alanadiniz.com/public_html/cron.php >/dev/null 2>&1

Linux sunucu (crontab)

VPS'te dosyaların sahibi olan kullanıcının crontab'ını düzenleyin - root'unkini değil; yoksa yazdığı önbellek ve log dosyalarını web sunucusu sonradan okuyamaz:

sudo -u www-data crontab -e

Önce dizin değiştiren ve okuyabileceğiniz bir log tutan bir satır ekleyin:

* * * * * cd /var/www/jekcms && /usr/bin/php cron.php >> logs/cron.log 2>&1

cd önemlidir çünkü bazı include'lar çalışma dizinine göre çözülür; log yönlendirmesi ise "cron bozuk galiba" durumunu beş saniyelik bir teşhise çevirir.

Linux + systemd zamanlayıcı

Kullanıcı başına crontab yerine journal kayıtları ve yeniden başlatmaya dayanıklı durum istiyorsanız /etc/systemd/system/jekcms-cron.service dosyasını oluşturun:

[Unit]
Description=jekcms cron tick

[Service]
Type=oneshot
User=www-data
WorkingDirectory=/var/www/jekcms
ExecStart=/usr/bin/php cron.php

ve /etc/systemd/system/jekcms-cron.timer:

[Unit]
Description=Run jekcms cron every minute

[Timer]
OnCalendar=*:0/1
Persistent=true

[Install]
WantedBy=timers.target

Ardından etkinleştirin ve zamanlamanın oturduğunu doğrulayın:

sudo systemctl daemon-reload
sudo systemctl enable --now jekcms-cron.timer
systemctl list-timers | grep jekcms
journalctl -u jekcms-cron -n 20

Kabuğu ve cron paneli olmayan sunucular

cron.php bir HTTP tetiği de kabul eder. Sır adres satırında değil başlıkta taşınır: adres satırındaki her şey erişim kayıtlarına, tarayıcı geçmişine ve Referer başlığına düşer. Bir zamanlayıcı kimliğinin yeri orası değil.

Yapılandırmanızda CRON_TOKEN tanımlayın, sonra bir dış cron servisini özel başlıkla sitenize yöneltin:

curl -s -H "X-Cron-Secret: CRON_TOKEN_DEGERINIZ" https://siteniz.com/cron.php

Eşleşen jetonu taşımayan her istek 403 forbidden alır. Dış cron servislerinin çoğu (cron-job.org, EasyCron ve benzerleri) ücretsiz katmanda özel başlığı destekler.

Windows Görev Zamanlayıcı

XAMPP, WAMP ya da IIS kurulumlarında Create Basic Task değil Create Task kullanın - dakika düzeyinde tekrarı yalnız tam iletişim kutusu sunar.

General sekmesinde göreve ad verin ve Run whether user is logged on or not seçeneğini işaretleyin. Triggers altında bugünden başlayan günlük bir tetik ekleyin; 1 gün boyunca her 1 dakikada bir tekrarlasın. Actions altında programı C:\xampp\php\php.exe, argümanı C:\xampp\htdocs\jekcms\cron.php ve Start in alanını C:\xampp\htdocs\jekcms yapın - en çok unutulan alan sonuncusudur, o olmadan göreli include'lar patlar. Conditions altında Start only if the computer is on AC power kutusunun işaretini kaldırın, yoksa görev dizüstünde durur. Settings altında Run task as soon as possible after a scheduled start is missed kutusunu işaretleyin.

Kaydedin, sonra göreve sağ tıklayıp Run deyin: zamanlamaya güvenmeden önce ateşlendiğini görün.

Gerçekten çalıştığını kanıtlamak

Önce komutu elle koşturun. Komut satırı turu bir zaman damgası, iş yapan her adım için bir satır ve done basar:

php /kurulum/yolu/cron.php

Bu çalışıyor ama zamanlanmış görev çalışmıyorsa sorun jekcms'te değil panel kaydındadır. Tazelik bayrağı tartışmayı bitirir; dosyaya her gerçek turda dokunulur:

ls -l cache/.cron-real.flag

Değişiklik zamanı son bir iki dakika içindeyse cron cron.php'yi çağırıyordur. Saatler öncesiyse ya da dosya hiç yoksa, panel ne derse desin çağırmıyordur.

Çıktıyı bir log dosyasına yönlendirdiyseniz onu izleyin:

tail -f logs/cron.log

Sırada gerçekten ne beklediğini görmek isterseniz:

SELECT type, status, scheduled_at, attempts, error_message
FROM scheduled_tasks
WHERE status IN ('pending', 'processing')
ORDER BY scheduled_at;

Yarım saatten uzun süre processing durumunda kalan satırlar, kuyruk bir sonraki yoklamada pending durumuna otomatik geri alınır; yani çöken bir iş akışı tabloyu kalıcı olarak tıkamaz.

Cron kurmamaya karar verirseniz

Zamanlanmış yayın, içerik kuyruğu ve tek seferlik görev kuyruğu elinizde kalır; çünkü ziyaretçi tetikli zamanlayıcı "sıradaki iş" damgasını tam olarak bu üçünden hesaplar. Onları dakikası dakikasına değil, ilk ziyaret hassasiyetiyle korursunuz.

Kaybettiğiniz şey, sırtına bineceği ziyaretçisi olmayan her iştir. Gece sessizleşen bir sitede 02:00'de kuyruğa giren bülten grubu sabahki ilk okuru bekler. Gecelik yedek penceresi tamamen kaçabilir. Insights raporunu besleyen haftalık Search Console geçmiş çekimi, ilerlemek için penceresi içinde bir tura ihtiyaç duyar.

Zamanlayıcıyla karıştırılmaması gereken ikinci ve ilgisiz bir yedek daha var: ön yüz isteklerinin kabaca ellide biri AI toplu analiz işçisini de bir adım ileri iter. O gerçekten olasılıklıdır, yalnız o işçiye dokunur ve cron'suz bir sitede toplu SEO analizinin hiç değil de eninde sonunda bitmesi için vardır.

Dürüst özet: hobi bloguna cron gerekmez. Bülteni, yedek politikası ya da birinin güvendiği bir yayın takvimi olan her sitede gerçek bir cron görevi olmalı.