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

Geçiş sonrası uyumsuz PrestaShop eklentileri

Yıllarca sorunsuz çalışan bir eklenti, bir PrestaShop geçişinden sonra sessizce kaybolabilir veya tamamen çökebilir. Bu neredeyse hiçbir zaman rastlantı değildir: arkasında her zaman belirli bir teknik mekanizma vardır ve geçişten önce kontrol edilebilir.

Sorunumu anlatayım Mesaj gönderin

Bir eklenti uyumluluğunu nasıl bildirir

Her PrestaShop eklentisi, hangi sürüm aralığıyla çalıştığını config.xml dosyasında, <compatibility><min> ve <max> etiketleriyle bildirir. Aynı bilgi, eklentinin ana PHP sınıfında $ps_versions_compliancy özelliği olarak da bulunur. Resmi Addons pazaryeri, bir eklentinin belirli bir sürümle uyumlu olarak sunulup sunulmadığını göstermek için bu bildirime dayanır: bir eklenti hedef sürümü kapsayacak şekilde hiç güncellenmemişse, o sürüm için basitçe artık mevcut olarak görünmez.

Bu bildirim tek başına eklentinin gerçekten çalışacağını garanti etmez: yayıncının niyetini gösterir, kapsamlı bir testin sonucunu değil. Ama bunun eksikliği güvenilir bir sinyaldir: uyumluluk aralığı hedef sürümden önce biten bir eklentinin zaten doğru çalışma şansı yoktur.

Bir eklentiyi uyumsuz kılan dört mekanizma

  • Ödeme hook’u PrestaShop 1.6 ile 1.7 arasında ad değiştirdi: displayPayment (1.6) yerini paymentOptions’a (1.7, 8 ve 9) bıraktı. 1.6 için yazılmış ve hiç güncellenmemiş bir ödeme eklentisi, ödeme anında hiçbir hata mesajı vermeden basitçe görünmez olur: bu, 'eklenti kayboldu' şikayetinin sık görülen ve sinsi bir nedenidir.
  • Birçok eski eklenti, dizilere veya karakter dizilerine süslü parantezlerle erişim söz dizimini kullanır, örneğin $array[0] yerine $array{0}. Bu söz dizimi PHP 8'de kaldırıldı ve kurulu PrestaShop sürümünden bağımsız olarak, eklenti PHP 8'e geçmiş bir sunucuda çalışır çalışmaz ölümcül bir hataya yol açar.
  • Çekirdek bir sınıfı veya denetleyiciyi değiştirmek için override/ klasöründeki dosyaları değiştiren override sistemi, orijinal sınıf iki sürüm arasında imza veya yapı değiştirdiyse her büyük geçişte bozulur: override o zaman ya artık hiç çağrılmaz ya da çalışma zamanında bir PHP hatasına yol açar.
  • Kağıt üzerinde uyumlu olarak bildirilen bir eklenti, özellikle az bakım gören veya terk edilmiş eklentilerde, yayıncısı tarafından hedef sürümde gerçekten hiç test edilmemiş olabilir: config.xml’deki uyumluluk bildirimi bir niyeti yansıtır, kapsamlı bir testi değil.

Geçişten önce uyumluluğu nasıl kontrol ediyorum

  1. Kurulu her eklentinin config.xml’ini okumak

    İkincil görünenler de dahil, mağazada gerçekten kurulu olan her eklentide bildirilen uyumluluk aralığını kontrol ediyorum.

  2. Eklentinin Addons sayfasını kontrol etmek

    Yayıncının hangi sürümleri uyumlu olarak duyurduğunu ve güncel bir sürümün var olup olmadığını görmek için eklentinin resmi pazaryerindeki sayfasına bakıyorum.

  3. Mağazanın bir kopyası üzerinde test etmek

    Uyumluluk bildirimi hiçbir zaman gerçek bir testin yerini tutmaz. Önce bir kopya üzerinde geçiş yapıyorum ve geçişi onaylamadan önce her eklentinin temel işlevlerini deniyorum.

  4. Override’ları ve kişiselleştirmeleri elle yeniden gözden geçirmek

    Çok sayıda override üzerine kurulu bir eklenti veya kişiselleştirme, sadece otomatik bir test değil, sistematik bir elle inceleme gerektirir; çünkü bir override hatası, belirli bir eylem onu tetikleyene kadar sessiz kalabilir.

Hedef sürümde resmi bir karşılığı olmayan bir eklenti için ne yapmalı

Bir eklenti hedef sürüm için basitçe mevcut değilse, önce başka bir yayıncıda eşdeğer bir eklenti arıyorum: belirli eklenti artık olmasa bile, işlevin kendisi nadiren benzersizdir. Piyasada uygun bir çözüm yoksa, orijinal eklentinin iş mantığını koruyup artık güncelliğini yitirmiş kodunu miras almadan, yeni mimariye uygun özel bir eklenti geliştiriyorum.

İ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

Ödeme eklentim geçişten sonra hiçbir hata vermeden neden ödeme sayfasından kayboldu?
Bu büyük olasılıkla 1.6 ile 1.7 arasındaki hook değişikliğiyle ilgilidir: displayPayment yerini paymentOptions’a bırakır. Hiç güncellenmemiş bir ödeme eklentisi artık yeni hook’a bağlanmaz ve hata mesajı vermeden kaybolur.
Addons’ta uyumlu olarak işaretlenmiş bir eklenti yine de çökebilir mi?
Evet, config.xml’deki uyumluluk bildirimi yayıncının niyetini yansıtır, benim tam kurulumumda yapılmış kapsamlı bir testi değil. Bu yüzden mağazanın bir kopyası üzerinde gerçek bir test yapmak vazgeçilmezdir.
Kusursuz çalışan bir eklenti PHP 8'e geçildiğinde neden birden çöküyor?
Genellikle $array{0} gibi süslü parantezli dizi erişim söz diziminden dolayı; bu söz dizimini PHP 8 kaldırdı. Bu ölümcül hatanın PrestaShop sürümüyle ilgisi yoktur, tamamen PHP sürüm değişikliğinden kaynaklanır.
1.6'da çalışan bir override, kodu değiştirilmeden gerçekten bozulabilir mi?
Evet, üzerine yazdığı sınıf yeni sürümde imza veya yapı değiştirdiyse. Override o zaman ya artık çağrılmaz ya da çalışma zamanında bir PHP hatasına neden olur.
Hedef sürümüm için eşdeğer bir eklenti yoksa ne yaparsınız?
Önce başka bir yayıncıda bir alternatif arıyorum. Hiçbiri uygun değilse, orijinal eklentinin iş mantığını koruyan, yeni sürümün mimarisine uyarlanmış özel bir eklenti geliştiriyorum.

İlgili sayfalar