CPalius CMF 2.0.0

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

Veritabanındaki her tablo yeniden adlandırıldı, taşıdığı üç collation teke indi, ve her biri iki kez yazılmış dört forum tablosu ikiye düştü. Bunun major sürüm olmasının sebebi tablo adlarının değişmesi ve sınıfların kaldırılması: ikisinden birine bağlanan üçüncü parti bir modül, güncellenene kadar çalışmaz.

Yükseltmeden önce okuyun#

Önce veritabanı yedeği alın. Şema migration'ı geri alınabilir değil. 31 tabloyu yeniden adlandırıyor, dördünü ikiye katlıyor ve her tablonun collation'ını çeviriyor; birleşmeleri geri almak, kimsenin vermediği oyları uydurmak demek olurdu. Geri dönüş yolu down migration değil, yedekten geri yükleme.

Migration'ı güncelleme sizin için çalıştırıyor. 2.100 satırlık bir veritabanında yaklaşık 1,5 saniye sürdü ve collation dönüşümü dışında tablo yeniden yazımı yapmıyor — yani pencere kısa, ama bir pencere var, ve büyük bir foruma sahip sitede collation adımının orantılı olarak uzamasını bekleyin.

Her yerde tek önek#

Dokuz çekirdek tablo cp_ geleneği oluşmadan önce yazılmış ve hiç almamıştı: users, nodes, assets, menus, menu_items, node_field_index, url_aliases, node_category ve node_tag. Modüller de yazarının seçtiği öneki kullanıyordu — forum_, blog_, ya da hiçbiri. Bir tablonun adı, sahibini söylemiyordu.

Bu sürümden itibaren kural tek cümle:

• Çekirdek tabloları cp_<isim>
• Modül tabloları cp_<modul>_<isim>

Yani users artık cp_users, forum_posts artık cp_forum_posts, ve yazacağınız modül tablolarını cp_<modulunuz>_ altına koyar. doctrine_migration_versions ve messenger_messages adlarını koruyor: onlar Doctrine ve Symfony Messenger'a ait ve bu adları koda gömüyorlar.

Tek collation#

Veritabanı üç tane taşıyordu: en eski dokuz tabloda utf8mb4_0900_ai_ci, diğer 56'sında utf8mb4_unicode_ci, Doctrine'ın migration tablosunda utf8mb4_general_ci. Bu sınırın iki yanındaki bir varchar'ı joinlemek Illegal mix of collations hatası verir — geliştirmede çalışıp üretimde patlayan, ya da tam tersi, hangi tablolara dokunduğuna bağlı bir sorgu.

Artık hepsi utf8mb4_unicode_ci; 66 tablonun 56'sının zaten kullandığı ve hem MySQL 8'in hem MariaDB 11'in kabul ettiği collation bu.

Beğeni ve beğenmeme artık tek tablo#

forum_post_likes ve forum_post_dislikes aynı dört sütunu tutuyordu ve repository sınıfları, entity adı dışında satır satır aynıydı. Artık cp_forum_post_votes, ve karar +1 veya -1 olarak saklanıyor.

Bu gerçek bir açığı kapatıyor. Bir üyenin aynı mesaja hem beğeni hem beğenmeme tutup tutamayacağına ForumTopicService karar veriyordu: kendi satırını eklemeden önce karşı satırı siliyordu. Veritabanında bunu zorlayan hiçbir şey yoktu, yani aynı anda gelen iki istek ikisini de bırakabilirdi. UNIQUE(post_id, user_id) artık bu durumu temsil edilemez kılıyor.

Mevcut oylar taşınıyor. Bir şekilde ikisini birden tutan üye, en son verdiğini korur.

Konu okuma durumu ve izleme tek satır#

forum_topic_views ve forum_topic_watches ikisi de şu üye, şu konu, şu zaman idi ve ikisi de aynı çift üzerinde anahtarlıydı. Artık cp_forum_topic_user_state, ve last_seen_at ile watching_since tek satırın iki boş geçilebilir sütunu. Bir konuyu izlemeyi bırakmak artık satırı silmek yerine bir sütunu temizliyor, yani nereye kadar okuduğunuzu çöpe atmıyor.

Kaldırılan sınıflar#

Bunlardan birine bağlanan modülün güncellenmesi gerekir:

• Modules\Forum\Entity\ForumPostLike ve ForumPostDislike — yerine ForumPostVote, ForumPostVote::LIKE / ::DISLIKE ile
• Modules\Forum\Entity\ForumTopicView ve ForumTopicWatch — yerine ForumTopicUserState
• ForumPostLikeRepository, ForumPostDislikeRepository, ForumTopicViewRepository, ForumTopicWatchRepository — yerine ForumPostVoteRepository ve ForumTopicUserStateRepository

Domain olayları değişmedi: ForumPostLikedEvent ve ForumPostDislikedEvent aynı veriyle tetiklenmeye devam ediyor.

Beraberinde gelen düzeltmeler#

Güncellemeden sonra Doctrine'ın sorgu önbelleği de temizleniyor. O önbellek DQL'i değil, DQL için ürettiği SQL'i saklıyor ve üretimde Redis'te duruyor — yani var/cache'in silinmesi oraya hiç ulaşmıyordu. Bu sürümden önce, tablo adı değiştiren bir güncelleme Redis'i artık var olmayan tablolardan seçen ifadeler dağıtır halde bırakırdı. Bu durumda hiçbir şey yayınlanmadı; bu sürüm hazırlanırken bulundu.

Modül şema dosyaları yeniden depoda. .gitignore'daki *.sql kuralı veritabanı dökümlerini dışarıda tutmak için yazılmıştı ve cp-content/modules/*/Resources/migrations/ altındaki şema dosyalarını da dışlıyordu. Dörtten üçü hiç commit edilmemişti. En ağırı Whitepaper'ınki: cp_whitepaper_documents ve cp_whitepaper_sections tablolarını başka hiçbir şey oluşturmuyor, yani temiz bir klondan kurulan site o modülü hiç çalıştıramıyordu.

Forum presence tablosu artık temiz kurulumu bozmuyor. Onu iki yer oluşturuyor — bir çekirdek migration ve modülün kendi SQL'i — ve modülün kopyasında IF NOT EXISTS yoktu, yani çekirdek migration'ların önce koştuğu yeni bir sitede Forum modülü kurulumu zaten var olan bir tabloda patlıyordu.

Performans probe'undaki kimlik sonrası SSRF kapatıldı. Varnish/PageSpeed kontrol adresi operatörden geliyor ve şeması hiç denetlenmiyordu, yani gopher:// bir başlık probe'unu iç ağda erişilebilir herhangi bir porta ham bayt gönder haline getiriyordu. Şema artık iki ayrı yerde HTTP ve HTTPS'e sabitli. Loopback'i yoklamak çalışmaya devam ediyor — kontrolün amacı zaten o.

Kaldırdığı traversal'ı kendisi üreten bir sanitizer. Sayfa önbelleği str_replace(['..', "\0"], '', $path) çalıştırıyordu; bu iki geçişi sırayla yapar, yani .\0./.\0. birinci geçişten sağ çıkıp ikincisinde ../.. oluyordu. Symfony yolu hiç URL-decode etmediği için HTTP üzerinden erişilebilir değildi — yine de kapatıldı.

Yükseltme notları#

1. Veritabanı yedeği alın. Bu sürümde tercihe bağlı değil.
2. Güncellemeyi her zamanki gibi AACP → Güncellemeler üzerinden uygulayın. Önce migration'lar, sonra güncelleme kancaları, en son önbellek yeniden kurulumu çalışır.
3. Paylaşımlı hostingde FTP ile uyguluyorsanız sonrasında cp-core/var/cache/prod/ içini boşaltmayı ve Doctrine önbellek havuzlarını temizlemeyi unutmayın — bu sürüm güncelleyicinin bunu kendi yapmasını sağlıyor, ama ancak bu sürümü indiren güncellemeden sonrası için.
4. Bizden almadığınız modülleri yukarıdaki kaldırılan sınıflar için kontrol edin.

Bilinen kısıtlar#

doctrine:schema:validate yükseltilmiş bir veritabanında hâlâ uyumsuzluk raporluyor: 81 satır, hiçbiri bu sürümde eklenmedi. Bunlar MariaDB'nin JSON sütunlarını json_valid kontrollü longtext olarak göstermesi (MySQL yerel JSON tipi kullanıyor), migration'ların elle adlandırdığı ama Doctrine'ın kendi adını üreteceği indeksler, ve Doctrine'ın karşılaştıracağı bir entity'si olmayan, ham SQL ile sürülen üç tablo. Bunları düzeltmek ayrı bir iş.