AACP Cron, job tanımlarını cp_cron_jobs üzerinden yönetir. PublishScheduledPostsTask blog zamanlaması için buna bağlı. Sunucu “status” sayfası ayrı bir ürün değil; AACP Araçlar menüsü ve telemetri bu işi görür.
Prod’da APP_ENV=prod iken cron’un gerçekten crontab’tan çağrıldığını doğrulayın. Paneldeki “son koşu” boşsa görev hiç tetiklenmiyordur.
cp_cron_jobs satırı doğruysa AACP log’u yeterli oluyor. Blog scheduled → published geçişini önce staging’de bir yazıyla denedik, sonra canlı crontab’a aldık.
Dinamik job silmek migration ile gelmiş görevi silmez; çekirdek görevler kodda kayıtlı kalır.
Crontab’a php cp-core/bin/console cp:cron:run benzeri görevi ekleyince AACP last-run doldu. Panelden “çalıştır” ile prod’u kandırmayın.
Zamanlanmış yazı 09:00’da yayınlandı; origin cache’i o job’un sonunda düşürmek iyi oldu.
Prod crontab ile staging aynı job listesini taşıyor. Fark yalnızca DATABASE_URL ve APP_SECRET. Cron’u sadece AACP’den “çalıştır” ile canlı tutmayın.
PublishScheduledPostsTask log’u AACP’de; yazı Studio’da. İki paneli karıştırmayın.
slaweally: AACP Cron’da dinamik job nasıl çalışıyor?
Çekirdek görevler kodda kayıtlı, ek görevler cp_cron_jobs satırı. Server status ayrı SaaS değil; telemetri ve RMVP AACP Araçlar’da.
Prod’da aynı tanımı kullanıyoruz; tek fark crontab kullanıcısının yazma izni var/log üzerinde.
