Laragon terminalinde php -v 8.4 görünce console da düzeldi. IDE’nin kendi terminaline aynı PATH’i vermek ayrı iş.DocumentRoot public/ olduktan sonra “uygulama bulunamadı” kayboldu; kalanlar asset 404’tü, o da importmap.
Bende eksik olan ext-intl idi; ekleyince migration geçti. Composer için COMPOSER_MEMORY_LIMIT=-1 yeterli oldu.Windows’ta openssl ve fileinfo da kapalıysa medya yükleme ilk günden kırılır. Laragon PHP eklenti listesini bir kez tarayın.
Locale’ler çekirdekte composite unique ile durur: aynı slug iki dilde yaşayabilir. Forum bölümleri de locale taşır; menü öğelerini /tr ve /en için ayrı tutun.Yeni çeviri anahtarı messages+intl-icu YAML’ine eklenince cache:clear gerekir. homepage....
Resource’u Node ile karıştırmamak işi netleştirdi. İçerik Studio’da, iş kaydı kendi masasında.slaweally: Node = içerik, Resource = iş kaydı.Typo3 analogu yeni katkıcıya anlatırken işe yarıyor. Teşekkürler.
Audit log Resource’ta daha kritik; Node zaten revision’a aday. Çok kiracılı SQL filter attribute görürse tenant_id enjekte eder.Demo’da tenant kapalı olsa bile attribute’u baştan koyun; sonra şema kırılır.
Studio içerik listesine Resource karıştırmayın. Editör “taslak araç” diye aramasın. Ayrı masa, ayrı yetenek.Whitepaper bölüm 5 tam bu ayrımı anlatıyor; onboarding’e linkleyelim.
PowerShell’de & ile tam yol: & 'C:\laragon\bin\php\php-8.4\php.exe' cp-core/bin/console.ExecutionPolicy script’i değil php.exe’yi keser; “uygulama bulunamadı” yine PATH’tir.
Windows’ta php’nin PATH’te olmaması CPalius hatası değil, kabuk hatası. Laragon PHP 8.4 klasörünü kullanıcı PATH’ine ekleyin.Aynı sorun mysql ve composer’da da çıkar. IDE terminali Laragon terminalinden farklı PATH taşıyabilir.
Settings tarafındaki batch load kalıbını blog listesine de taşıdık. N+1 Guard dev’de limiti aşınca exception atıyor; canlıya öyle çıkılmıyor.Sayım sorgusunu liste DQL’inden ayırmak paginator cartesian’ını kesti.
RMVP Redis test butonu bağlantı hatasını net gösteriyor. Yanlış DSN’i .env’de bırakıp “önbellek yok” diye tema suçlamayın.Memcached ve Redis aynı anda gerekmez. Bir backend seçin, origin HTML’i onunla hizalayın.
Cron log’u AACP’de görünüyor; PublishScheduledPostsTask’ın last run’ı boşsa crontab suskundur.Dinamik görev ile çekirdek görevi karıştırmayın. Çekirdek olanı silmek sonraki cache:clear’da geri gelir.
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 y...
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.
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.
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.
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çek...
Typo3 Page/Record ayrımına yakın: Page ≈ Node, Record ≈ Resource. Ortak payda yetenekler, Twig bileşenleri ve config sync.Studio içerik listeler; iş kayıtları kendi masasında durmalı. Karışınca editör yetkisi muhasebe kaydına sızar.