Modüller ve eklentiler: satın almak, geliştirtmek, onarmak

Bu bölüm kimin için

Buraya çok farklı iki ruh haliyle gelinir. Ya bir işlev eksiktir: ürün yapılandırıcısı, taksitli ödeme, ekip için bir takip ekranı, standartta bulunmayan bir bildirim. Ya da kurulu bir modül sorun çıkarmaktadır: güncellemeden sonra görünmez olmuştur, başka bir modülle çakışmaktadır, her sayfayı yavaşlatmaktadır ya da geliştiricisi artık yanıt vermemektedir.

Her iki durumda da asıl soru aynıdır: mevcut olana ne kadar yaslanmalı ve hangi noktadan sonra kontrol edilebilen bir kod yazmak daha iyidir. Bu sayfalar tek bir tavsiye yerine ölçütleri verir — doğru karar sipariş hacmine, mağazanın öngörülen ömrüne ve sonrasında onu kimin bakımını üstleneceğine bağlıdır.

Bölüm nasıl düzenlendi

Yirmi dört sayfa bir modülün yaşam döngüsünü izler. Önce karar sayfaları: satın almak mı geliştirtmek mi, resmî, üçüncü taraf ya da özel, fiyatı gerçekte ne belirler, teklif istemeden önce ihtiyaç nasıl çerçevelenir. Ardından en sık görülen işlevsel ihtiyaçlar: abonelik ve üyelik alanı, kapora ve taksitli ödeme, yapılandırıcı, PDF belgeler, bildirimler, ürüne veya siparişe ek alan, yönetim panelinde iş ekranı, satış sonrası, arka planda çalışan işlemler.

Sonra arızalar gelir: güncellemeden sonra bozulan modül, iki modül arasındaki çakışma, etkin olduğu hâlde hiçbir şey göstermeyen modül, üzerine yazılan değişiklikler, mağazayı yavaşlatan modül, ortadan kaybolan geliştirici. Ve son olarak yaşam döngüsü: modül envanterini denetlemek, üretime almadan önce test etmek, düzgün kaldırmak, zaman içinde sürdürmek, yarım kalmış bir geliştirmeyi devralmak.

Bir modül mağazanıza gerçekte ne yapar

Modül, sitenin yanına konan bir tuğla değildir: içine yerleşir. PrestaShop'ta hook'lara bağlanır, kendi tablolarını ekler ve çekirdek bir sınıfın davranışını değiştirmek için override/ dizinine bir dosya bırakabilir. Çakışmaların çoğu buradan doğar: aynı metodu geçersiz kılmak isteyen iki modül bir arada bulunamaz ve ikincisi kendi override dosyasını yerleştiremez, üstelik çoğu zaman satıcıya görünen bir mesaj olmadan.

WooCommerce'te eşdeğer mekanizma eylemler ve filtreler üzerinden, bir de alt temanın woocommerce/ dizinine kopyalanan şablonlar üzerinden işler. Bu kopyalar eklentinin güncellemelerini izlemez: WooCommerce bir şablonu değiştirdiğinde kopya olduğu gibi kullanılmaya devam eder ve sayfa eski bir sürümden üretilir. Sürüm yükseltmesinden sonra sipariş akışının bir yasal ibareyi ya da bir alanı yitirmesinin en sıradan nedeni budur.

Bu iki mekanizmayı akılda tutmak, bir modül envanterinin zamanla neden bozulduğunu ve satın almadan önce sorulacak sorunun yalnızca istediğinizi yapıp yapmadığı değil, neye dokunduğu olduğunu görmeye yeter.