CPalius CMF 2.2.16
Yayın: 2026-09-25 · Kanal: kararlı · Kritik: evet
2.2.15, migrasyonlar ile bir spesifik cache temizliği arasındaki sırayı düzeltti. Yeterli değildi, çünkü aynı sınıf sorunun ikinci bir kapısı vardı: Symfony kendi framework-seviyesi olaylarını — kernel.response, kernel.terminate — bir controller yanıt döndürdükten sonra, uygulama kodu isteyip istemediğine bakmaksızın, her istekte otomatik olarak gönderir. O olaylara bağlı, istekte henüz kullanılmamış herhangi bir modül-sahipli dinleyici, aynı isteğin biraz önce sildiği bir container dosyasına hâlâ uzanabiliyordu. Bu sürüm kapıyı daha dikkatli kilitlemek yerine tamamen kaldırıyor.
Bu sefer gerçekten doğru şekilde: asıl sorun neydi
Bu kod tabanının derlenmiş container'ı temizleyen her parçası, gerçek silme işlemini her zaman kernel.terminate'e ertelemişti — yanıt tamamen gönderildikten sonra çalışması gereken, kayıtlı bir PHP kapanış fonksiyonu. Bu doğru tasarımdı. Hata, aynı silme işlemini yine de anında, isteğin ortasında, zorla tetikleyebilen ikinci, ayrı bir kod yoluydu — özellikle yeni oluşturulan bir alt sürecin (ön yüz varlıklarını derleyen) bayat değil taze dosyalar görmesi için.
Erken zorlamak o tek alt sürecin sorununu çözdü ve daha büyük bir sorun yarattı: onu zorlayan isteğin önünde hâlâ kendi kalan işi vardı — bir yönlendirme, bir render, ve her zaman, koşulsuz olarak, Symfony'nin kendi kernel.terminate olay gönderimi — hepsi artık container'ın dosyaları gitmiş hâldeyken çalışıyordu. 2.2.11'den 2.2.15'e kadar her biri, bir temizlikten SONRA olanları daha hızlı ve daha güvenli hale getirdi. Hiçbiri, etrafındaki her şey ne kadar dikkatli sıralanırsa sıralansın, bir temizliğin bu ikinci yol üzerinden isteğin ortasında hâlâ olabileceği gerçeğini ele almadı.
Ne düzeldi
Zorlanmış, istek-ortası temizleme yolu tamamen kaldırıldı. Derlenmiş container'ın her temizlenmesi — tam bir güncelleme, bir yama, AACP'nin cache-yeniden-derleme ekranı, bir tema aktivasyonu, her ne olursa olsun — artık tam olarak tek bir şekilde çalışıyor: zamanlanmış, ertelenmiş, ve sadece o istek için kernel.terminate tamamen çalıştıktan SONRA, tam olarak başlangıçta amaçlandığı gibi yürütülüyor. Daha önce erken zorlanmış temizliğin sebebi olan ön yüz varlık derlemesi, artık buna ihtiyaç duymak yerine aynı ertelenmiş, arka plan dizisinin bir parçası olarak gerçekleşiyor.
Pratik etki: cache'i temizleyen istek, ondan sonra ne çalışırsa çalışsın — bu kod tabanının araya girme veya etrafında yeniden sıralama şansı olmayan framework içi mekanizmalar dahil — her zaman normal şekilde, zaten sahip olduğu container ile bitiyor. Bir cache temizliğinden sonra hiçbir şey, hâlâ temizlenme sürecinde olan bir container'a takılamaz.
Yükseltme
Şema değişikliği yok. Elle bir işlem gerekmiyor. Bir temizlikten sonra yeniden derleme artık tetikleyen isteğin yanıtı dönmeden önce değil, arka planda oluyor — bir cache-yeniden-derleme eylemi (elle veya otomatik) yeniden derlemenin kendisini beklemek yerine hemen "zamanlandı" diye rapor veriyor; container ve varlıklar bir sonraki istek geldiğinde hazır oluyor.