CPalius CMF 2.0.1

Yayın: 2026-09-16 · Kanal: kararlı · Kritik: evet

2.0.0, kendisine güncellenirken siteyi düşürebiliyordu. Bu sürüm sebebi düzeltiyor ve halihazırda takılmış siteler için bir kurtarma betiği getiriyor.

Siteniz şu anda Table 'cp_users' doesn't exist gösteriyorsa, aşağıdaki "Takılmış siteyi kurtarma" bölümüne geçin — bu sürümü panelden kuramazsınız, çünkü bozuk olan şey panelin kendisi.

Ne oldu#

AACPUpdateController::upgrade() yeni dosyaları diske yazıyor, sonra güncelleme ekranını render ediyordu. Migration'lar bilerek "bir sonraki istekteki uygula adımına" bırakılmıştı.

O ekran, tam da az önce inen kodla, henüz taşınmamış veritabanına karşı çalışıyor. Bundan önceki her sürüm bunu atlatabildi, çünkü bundan önceki hiçbir sürüm tablo adı değiştirmemişti. 2.0.0 hepsini değiştirdi, dolayısıyla render Table 'cp_users' doesn't exist ile öldü — ve ölen şey panelin kendisi olduğu için operatör, migration'ı çalıştıracak butona bir daha hiç ulaşamadı. Site çıkışsız kaldı.

Düzeltme#

Migration'lar artık dosyaları yazan istekte, hiçbir şey render edilmeden çalışıyor. O pencerede güvenle koşabilen tek adım onlar: DBAL bağlantısı ve diskteki migration sınıfları yeterli, ikisi de atılmak üzere olan derlenmiş konteynere bağlı değil. Güncelleme kancaları, modül yükseltmeleri ve önbellek yeniden kurulumu bir sonraki isteğe kalıyor, çünkü onlar proje servislerini eski konteynerden geçiriyor.

Güncelleme rotası artık render etmiyor, yönlendiriyor — patch rotasının 1.1.3'ten beri aynı sebeple yaptığı şey. Yönlendirme yalnızca router istiyor; güncelleme ekranını render etmek servis grafiğinin yarısını artık koda uymayan bir konteynerden geçiriyor.

Takılmış siteyi kurtarma#

2.0.0 sitenizi zaten bozduysa uygulama kendini onaramaz — panel erişilemez durumda. public/cp-2.0.0-recover.php bunu dışarıdan, doğrudan PDO ile yapıyor: Symfony yok, konteyner yok, Doctrine yok.

1. cp-2.0.0-recover.php dosyasını bizden isteyin. Bilerek depoda değil: kendi erişim denetimi olmayan tek kullanımlık bir dosya ve işi biter bitmez silinmek üzere.
2. FTP ile sitenizin public/ klasörüne yükleyin.
3. Şunu açın: https://siteniz/cp-2.0.0-recover.php?dry=1 — planı yazdırır ve hiçbir şeye dokunmaz.
4. Plan doğruysa aynı adresi ?dry=1 olmadan açın.
5. cp-core/var/cache/prod/ içini boşaltın, klasör kalsın.
6. Siteniz Redis kullanıyorsa Doctrine önbellek havuzlarını temizleyin.
7. Betiği silin.

Betik, 2.0.0 migration'ının yaptığı işi aynı sırada ve aynı korumalarla yapıyor, sonunda migration'ı çalışmış olarak kaydediyor; böylece normal çalıştırıcı tekrarlamıyor. Her adım korumalı, yani iki kez çalıştırmak zararsız. Yayından önce gerçek bir 1.x veritabanına karşı doğrulandı.

Normal yükseltme#

Hâlâ 1.x'te olan bir site 2.0.1'i doğrudan AACP → Güncellemeler üzerinden alabilir ve 2.0.0'daki sorunla karşılaşmaz: şema, dosyalarla aynı istekte taşınıyor.

Önce veritabanı yedeği alın. 2.0.0 şema migration'ı geri alınabilir değil, bu değişmedi.

Bilinen kısıtlar#

Kurtarma betiği DATABASE_URL değerini Symfony'yi başlatmak yerine küçük bir ayrıştırıcıyla .env'den okuyor — çünkü takılmış bir sitede başlatılamayan şey tam olarak Symfony. .env dosyanız bu değeri düz bir ANAHTAR=değer satırı dışında bir yolla veriyorsa betik onu bulamaz. Betiğin kendi erişim denetimi yok; işi biter bitmez silin.