Projeler ve ajans desteği için müsait · Hızlı yanıt, işi yapan kişiden

Mesaj gönderin contact@allaux.fr
FR EN TR
allaux.
Acil durum Projemi konuşalım

PrestaShop 1.7’den 9’a: Symfony 6.4 ve yeniden yazılacak geçersiz kılmalar

PrestaShop’ta 1.7’den doğrudan 9’a geçmek; Symfony 6.4’e, en az PHP 8.1’e ve tamamen Twig tabanlı bir yönetim paneline tek seferde geçmek demektir: göründüğünden daha ağır bir sıçrama.

Sorunumu anlatayım Mesaj gönderin

1.7 ile 9 arasında ne değişiyor

PrestaShop 1.7 ile 9 arasındaki fark artık yalnızca bir sürüm numarası meselesi değil, bir nesil değişikliğidir. PrestaShop 1.7 karma bir mimariye dayanır: yönetim panelinin bir kısmı ve bazı ön yüz denetleyicileri Symfony üzerinde, geri kalanı hâlâ saf Smarty ve legacy yönetim denetleyicileriyle çalışır. PrestaShop 9 bu son legacy denetleyicileri kaldırır: yönetim paneli artık tamamen Symfony denetleyicileri ve Twig şablonlama üzerine kuruludur; Symfony’nin kendisi de 6.4 LTS’e atlar, 1.7/8 tarafındaki çok daha eski sürüme karşı. PHP tarafında, 1.7 en son alt sürümünde 7.4’te tavan yaparken, 9 en az PHP 8.1 ister ve 8.2, 8.3, 8.4’ü destekler: iki uyumluluk aralığı arasında doğrudan örtüşme yoktur.

PrestaShop 9 ayrıca API Platform üzerine kurulu, OAuth kimlik doğrulamalı yeni bir yönetim API’si (Admin API) ekler. Tema tarafında, 9 Hummingbird temasını tanıtır, ama varsayılan tema çıkışta Classic kalır: 1.6’dan 1.7’ye geçişin aksine, zorunlu bir tema yeniden inşası söz konusu değildir.

Veritabanı yapısı geçilen her ana sürümde değişir; burada, tek işlemde veya iki aşamada yapılsın, autoupgrade’in güncelleme betiklerinin kapsaması gereken iki ana aşama vardır (1.7’den 8’e, ardından 8’den 9’a).

Bu büyüklükte bir sürüm farkında neler bozulur

  • Legacy bir Smarty yönetim denetleyicisine dayanan bir eklenti, 9’da o denetleyicinin artık olmadığını fark eder: çökmez, sadece kaybolur.
  • 1.7 için yazılmış bir çekirdek metot override’ı, PHP 8.1’den beri gerekli dönüş tiplerini yok sayar: bir uyarı değil, ölümcül bir hata tetikler.
  • Bir dizi veya karakter dizisine erişmek için süslü parantez söz dizimini ($array{0}) kullanan bir eklenti, PHP 8.1 veya üzerinde çalışmayı durdurur.
  • Eski web servis API’sine göre geliştirilmiş bir entegrasyon, Admin API’nin OAuth kimlik doğrulaması için tasarlanmamıştır, gözden geçirilmesi gerekir.
  • config.xml dosyasında yalnızca 8. sürüme kadar uyumluluk bildiren bir eklenti, 9 üzerinde kurulum sırasında reddedilir.

Bu sıçramaya nasıl yaklaşıyorum

  1. Denetim ve yol kararı

    Eklentileri, denetleyici ve şablon override’larını ve mevcut web servis API’sini kullanan entegrasyonları listeliyorum, ardından işi nasıl böleceğime karar veriyorum. autoupgrade basamakları sırayla geçer, hiçbirini atlamaz: ara sürümlerin güncelleme betikleri her hâlükârda çalışır, tek soru bunların tek seferde mi akacağı yoksa özellikle legacy eklenti veya override varsa mağazayı kontrol etmek için 8’de durup durmayacağımdır.

  2. Bağımsız tam yedekleme

    Herhangi bir işlemden önce, autoupgrade’in iç yedeğine ek olarak tam bir SQL dökümü ve dosyaların tam kopyasını alıyorum; bunlar değiştirilecek sunucunun dışında saklanır.

  3. Mağazanın bir kopyası üzerinde geçiş

    Tüm prosedür, hedef PHP sürümü zaten devrede olan bir test ortamında tekrarlanır; böylece dönüş tipi hataları ve eksik denetleyiciler gerçek siteye dokunmadan önce ortaya çıkar.

  4. Geri dönüşü olmayan nokta: veritabanı betiklerinin çalıştırılması

    Şema güncelleme betikleri çalışmaya başladığında, temiz bir geri dönüş yalnızca dökümün geri yüklenmesiyle mümkündür. Bu adım yalnızca eklentiler ve override’lar test ortamında doğrulandıktan sonra başlatılır.

  5. Legacy denetleyicilerin ve eklentilerin yeniden yazılması

    Hâlâ Smarty üzerinde çalışan yönetim denetleyicileri ve bunlara bağımlı eklentiler, 9’un Symfony/Twig mimarisi için yeniden yazılır, sadece güncellenmez.

  6. Üretime geçiş

    Test sürümü onaylandıktan ve hedef PHP doğrulandıktan sonra, geçişi düşük trafikli bir zamana planlıyorum.

Sonradan nasıl doğruluyorum

Her aşamadan sonra eski ve yeni veritabanı arasında sipariş, müşteri ve ürün hacimlerini karşılaştırıyorum. Sipariş sürecini her ödeme yönteminde, yeniden yazılan denetleyicilerin her kullanıcı profili için doğru çalıştığını test ediyorum ve hiçbir API entegrasyonunun eski kimlik doğrulamasında takılı kalmadığından emin oluyorum. İlk günler PHP hata günlüğünü de izliyorum, özellikle nadiren kullanılan bir özellik devreye girdiğinde ortaya çıkan dönüş tipi hataları için.

İlgili sayfalar

İhtiyacınızı bir dakikada anlatın

Size bir anket daha değil, doğrudan bir tahmin sunabilmem için birkaç hedefli soru.

version-depart
version-arrivee
catalogue
modules-tiers (facultatif)
conserver (facultatif)
Size dönebilmem için en az bir e-posta veya telefon numarası belirtin.

Size dönebilmem için en az bir e-posta veya telefon numarası belirtin.

Sıkça sorulan sorular

9’dan önce mutlaka 8. sürümden geçmem gerekir mi?
Zorunlu bir durak değil, hayır: autoupgrade basamakları sırayla geçer ve hiçbirini atlamaz, doğrudan 9’u hedefleseniz bile 8’in betikleri çalışır. Ancak fark büyüdükçe tek seferde çalıştırılan güncelleme betiği sayısı artar ve risk penceresi uzar. Mevcut eklenti ve override’ların durumuna göre 8’de durmanın riski azaltıp azaltmadığına karar veriyorum.
Özel Smarty yönetim denetleyicilerim 9’da çalışmaya devam eder mi?
Hayır, oldukları gibi değil. PrestaShop 9, son legacy yönetim denetleyicilerini kaldırır: hâlâ Smarty üzerinde olan her yönetim paneli denetleyicisi, 9’un Symfony/Twig mimarisi için yeniden yazılmalıdır; kendiliğinden güncellenmez.
Böyle bir sıçrama ne kadar sürer?
Basit bir 1.7’den 8’e güncellemeden daha uzun: denetim, legacy denetleyici yeniden yazımları ve kopya üzerinde testler, yönetim paneli kişiselleştirmesi olduğunda günler değil haftalar tutar.
SEO’m etkilenir mi?
URL’ler ve sayfa yapısı korunursa, sürüm değişikliğinin kendisinden etkilenmez. İşlem boyunca, özellikle iki aşamada yürütülüyorsa, yönlendirmelere yakından dikkat ediyorum.

İlgili sayfalar