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.6’dan 9’a: kataloğun en geniş sıçraması

PrestaShop mağazasını doğrudan 1.6’dan 9’a taşımak, resmi araçla mümkün değildir: bu, üründeki en geniş fark olup artık tamamen Symfony tabanlı bir yönetim paneli, en az PHP 8.1 ve neredeyse tamamen yeniden inşa edilmesi gereken bir tema ve eklentiler gerektirir. Bu kadar geniş bir farkta, çoğu zaman saf bir geçiş yerine yenileme öneririm.

Sorunumu anlatayım Mesaj gönderin

Bu geçişin neden en ağır olduğu

PrestaShop 9.0, yönetim panelini Symfony 4.4’ten Symfony 6.4 LTS’ye taşır; artık tamamen Symfony denetleyicileri ve Twig üzerine kuruludur: son “legacy” denetleyiciler ortadan kalkar. Ayrıca API Platform üzerine kurulu, OAuth’lu yeni bir yönetim API’si sunar. En az PHP sürümü 8.1’e yükselir; 8.2, 8.3 ve 8.4 desteklenir.

Buna karşılık PrestaShop 1.6, özel bir legacy framework üzerinde çalışır, yalnızca Smarty kullanır ve en fazla PHP 7.1’e kadar çalışır: üç mimari nesli (1.7, 8, 9), iki tema değişikliği ve PHP 7.1’den 8.1’e bir sıçrama aşmak gerekir. Hummingbird 9.0’da ortaya çıkar, ancak Classic varsayılan tema olmaya devam eder: zorunlu bir seçim değildir.

Her PrestaShop geçişinde olduğu gibi, autoupgrade ile doğrudan atlama yoktur: 9’a ulaşmadan önce 1.7, pratikte 8 üzerinden de geçmek gerekir.

1.6’dan 9’a geniş bir farkta tipik olarak neler bozulur

  • displayPayment (1.6) için yazılmış bir ödeme eklentisi, bu hook 1.7’den beri paymentOptions ile değiştirildiği için ödeme adımında artık hiç görünmez.
  • Süslü parantezli eski dizi erişim söz dizimini kullanan neredeyse tüm 1.6 eklentileri (örneğin $array{0}), PHP 8’de kaldırıldığı için PHP 8.1 altında ölümcül hatalar verir.
  • Yalnızca Smarty üzerine kurulu ve Bootstrap 3 tabanlı 1.6 teması, 1.7’de gelen ve 9’da hâlâ geçerli olan tema mimarisinde bir karşılığa sahip değildir: ön yüz uyarlanmaz, yeniden inşa edilir.
  • Önceki yönetim API’sine dayanan entegrasyonların, 9’da tanıtılan yeni Yönetim API’si (API Platform, OAuth) karşısında kontrol edilmesi gerekir.

Bu kadar geniş bir sürüm farkına nasıl yaklaşıyorum

  1. Eksiksiz denetim ve geçiş mi yenileme mi kararı

    Eklentiler, tema, özel geliştirmeler, tahmini iş yükü: bu kadar geniş bir farkta yenileme, adım adım geçişten daha az maliyetli olabilir.

  2. Geçiş araçlarının dışında saklanan tam yedekleme

    Dosyalar, veritabanı dökümü, sürümleriyle eklenti listesi ve ödeme/taşıyıcı yapılandırması, dokunmadan önce.

  3. Geçiş seçilirse ara adımlardan (1.7, ardından 8) geçmek

    Her adım, mağazanın bir kopyası üzerinde, asla üretimde değil, kendi onayıyla ayrı test edilir.

  4. Temanın ve özel yönetim panelinin yeniden inşası

    Tema Classic üzerine yeniden inşa edilir (veya Hummingbird için uyarlanır), yönetim geliştirmeleri 9’un yönetimi için yeniden yazılır.

  5. Uyumsuz eklentilerin değiştirilmesi

    Geçiş yapamayan eklentiler için çalışan karşılıklar arıyorum ya da yeniden yazıyorum.

  6. Kontrol, ardından üretime geçiş

    Test sürümü onaylandıktan sonra, geçişi düşük trafikli bir zaman dilimine planlıyorum.

Geçiş mi, yenileme mi: nasıl karar veriyorum

Adım adım bir geçiş, temayı muhtemelen birden fazla kez yeniden inşa etmek ve her adımda her eklentiyi kontrol etmek veya yeniden yazmak anlamına gelir. Bir yenileme, sıfır bir 9 kurulumundan başlar ve yalnızca verileri taşır. Tema zaten eskiyse, özel eklenti sayısı fazlaysa veya site uzun süredir görsel olarak değişmemişse yenilemeyi öneririm.

Her iki durumda da, başlamadan önce dosya ağacını, veritabanı dökümünü, eklenti listesini ve ödeme/taşıyıcı yapılandırmasını yedekliyorum. Son geçişten sonra, sipariş, müşteri ve katalog ürünü sayısının öncekiyle eşleştiğini, URL’lerin doğru durum koduyla yanıt verdiğini, yönlendirmelerin çalıştığını kontrol ediyor ve paymentOptions ile eksiksiz bir test siparişi veriyorum.

config.xml
<compatibility>
  <min>1.7</min>
  <max>9.99.99</max>
</compatibility>

Bu geçişi hazırlamak veya tamamlamak için

  • PHP 5.2 – 7.1 PrestaShop 1.6
  • En az PHP 8.1, 8.4’e kadar PrestaShop 9

devdocs.prestashop-project.org

İ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

PrestaShop 1.6’dan doğrudan 9’a geçebilir miyim?
Tek bir çalıştırmayla değil. autoupgrade basamakları sırayla geçer ve hiçbirini atlamaz; 1.6’yı işleyebilen eklenti sürümü de 1.7’de durur: önce 1.7’ye ulaşmak, sonra oradan 8’e ve 9’a devam etmek gerekir.
Bu kadar geniş bir farkta neden bazen geçiş yerine yenileme öneriyorsunuz?
Tema birden fazla kez yeniden inşa edilmeli ve neredeyse tüm 1.6 eklentileri PHP 8.1 ve 9’un Symfony yönetimiyle uyumsuz: bir kez yeniden inşa etmek genellikle adım adım geçişten daha az maliyetlidir.
PrestaShop 9 için hangi PHP sürümü gerekir?
En az 8.1; PHP 8.2, 8.3 ve 8.4 desteklenir.
Yeni Hummingbird teması PrestaShop 9’da zorunlu mu?
Hayır. Hummingbird 9.0 ile tanıtılır, ancak bu sürümün çıkışında Classic varsayılan tema olmaya devam eder.
Mevcut API’yi kullanan entegrasyonlarım geçişten sonra çalışmaya devam eder mi?
PrestaShop 9, API Platform üzerine kurulu, OAuth kimlik doğrulamalı yeni bir yönetim API’si sunar. Mevcut her entegrasyonun geçişten önce bu yeni API karşısında kontrol edilmesi gerekir.

İlgili sayfalar