3. parti eklentileri nasıl değerlendirilir?

Magento 'kutunun dışında' çok şey yaparken, üçüncü taraf genişletme gerektiren müşteri mağazaları için kaçınılmaz özelliklerin ve olanakların olduğunu gördük.

Bununla birlikte, ortamın niteliği göz önüne alındığında, ticari işlemlerle ilgili böyle karmaşık bir sisteme 'yabancı' kod getirilmesi riskli bir teklif olabilir.

Magento uzantılarını değerlendirirken nelere dikkat ediyorsunuz? Karşılaştığınız 'kırmızı bayraklar' neler (performans domuzları, güvenlik riskleri, mimari kötü uygulamalar)?

İşte 3. Parti Modüllerini değerlendirmekle ilgili bazı düşünceler:

Temelleri:

• Mevcut Magento Versiyonu Desteği - Magento'nun en yeni versiyonunu destekliyor mu?

  Bir modül Magento'nun en son sürümünü desteklemiyorsa, üzerinde değerli geliştirme zamanı harcamadan çalışmasını sağlamak zor olacaktır.

• Destek - Modülü oluşturan geliştiriciler ürünü destekliyor mu?

  Sağlıklı bir modülün işaretlerinden biri, geliştiricilerin aktif olarak desteklemesidir. Desteklemiyorlarsa kırmızı bayraktır, neden iyi olursa ürünü desteklemiyorlar?

  Ek olarak, bir modül desteklendiğinde, geliştiricilerden basit bir e-posta ile genellikle önemli bilgiler alabiliriz (örneğin, bu modül jQuery veya Prototip kullanıyor mu).

• Yorumlar - Diğer kullanıcılar ne diyor? Deneyimleri nasıldı?

  Değerlendirmeleri okuyarak büyük resmin daha iyi anlaşılmasını sağlayabiliriz, bir kurulum sorunu var mı? Geliştiriciler zamanında ve yardımcı bir şekilde mi tepki veriyor? Reklamı yapıldığı gibi çalışıyor mu?

• İade - İstenildiği gibi çalışmazsa paranızı geri verecekler mi?

  Çoğu zaman modülü denemek istiyoruz, böylece çalışır ve teknik özelliklerimizi karşılarsa test edebiliriz! Ancak bu gerçekleşmezse, iade etme ve para iadesi alma seçeneğini istiyoruz.

Orta düzey:

• Sınıf Geçersiz Kılmaları - Modül herhangi bir çekirdek sınıfı geçersiz kılıyor mu?

  Genel olarak, iyi bir modülün konuşulması herhangi bir temel sınıfı geçersiz kılmamalı, bunun yerine Gözlemcileri kullanmalıdır.

  Bunun bir nedeni, Magento'yu yükseltmeyi zorlaştırmasıdır. Ek olarak, diğer modüller verilen bir fonksiyondan bir çıkışa bağlı olabilir ve bu modül farklı bir tane sağlıyor.

  Bazen bu mümkün değildir, eğer öyleyse, çekirdek bir sınıfı geçersiz kılmasının çok iyi bir nedeni olmalı.

• Düzen güncellemeleri - Modül düzen ayarlarımın bir kısmını değiştirir mi?

  Bazı modüller, yerleşim ayarlarını sitenize göre değiştirir (örneğin: ürün sayfası), geçerli düzeninizi bozmadığından emin olun ve gerekli olanı yaparsa (okuyun: düzeltmek için ne kadar zaman alacaktır) .

• Şablon değişiklikleri - Modül, geçerli tasarımımı değiştiren şablonlar içeriyor mu?

  Bu modül yeni şablonlar sunacak mı? Evet ise, tasarımımı bozacaklar mı? Tasarımın istediğimiz şekilde olması ne kadar zaman alır?

• Bağımlılıklar - Modül başka bir modüle bağlı mı?

  Modül diğerlerine bağlıysa, orada olduklarından ve yüklendiklerinden emin olmamız gerekir. Ek olarak, kendimize sormamız gerekiyor, gelecekte bağlı olduğu modülü kapatmak isteyecek miyiz?

İleri:

• SQL Yükseltme komut dosyaları - Modül DB'yi bir şekilde günceller mi?

  Bir modül veritabanını güncellediğinde, birkaç şeyden emin olmamız gerekir.

  Çekirdek bir tabloyu günceller mi? Evetse, bu iyi değil, veritabanlarımızı temiz ve güncellemeye hazırız.

  Bilgileri mantıklı bir şekilde saklıyor mu? Verileri veritabanından kendimizden elde etmek istiyorsak, bunu anlayabilir miyiz?

• Olaylar - Modül herhangi bir olayı gözlemler veya gönderir mi?

  Bir modül olayları gönderir veya gözlemlerse şunu bilmek isteriz:

  Hangi olayları gözlemliyor / gönderiyor? Bu sistemde çalışan başka bir modülü etkileyecek mi. Örneğin, modüllerimizden biri yüklenen ürünlerimizin adını büyük harfe dönüştürürse ve bu modül yüklenen ürünün adına 'free' kelimesini eklerse, nasıl çalışır? 'Ücretsiz' kelimesi aynı zamanda üst kısımdan mı gelecek?

• Kod İnceleme - Modül kabul edilebilir kodlama tekniklerini kullanıyor mu?

  Bunun Magento'dan daha çok PHP kodlama teknikleri ile ilgisi var.

  Kod Try / Catch bloklarını kullanıyor mu?

  Kod kullanıcı girişinden kaçıyor mu?

  Bunun özellikleri bizim yetenek seviyemize / gereksinimlerimize bağlıdır.

• Potansiyel sorunlar - Bu modülü kurmanın bir sonucu olarak hangi potansiyel sorunlar ortaya çıkabilir?

  Bu modülü kurarsak ortaya çıkacak en büyük beş problemi hayal etmeye çalışın, olabileceği kadar şaşırtıcı, gerçekten bir bütün olarak projeye içgörü kazandırıyor.

Alt çizgi:

Bütün bunlar ideal bir dünyada olmak güzel, gerçek dünya senaryolarında 'uzlaşma' denilen şeyi yapmamız gerekiyor :)

Ek olarak, bu kurallar bize sadece bir modül kuruyorsak, sosyal paylaşım modülü diyelim, basit bir site kurulumuna ihtiyaç duyan bir müşterimiz için diyelim ki, bizi engellememek değil, bize yardım etmek içindir. tonlarca araştırma yapmanın bir anlamı yok.

Başka bir deyişle: Her şey bizim zamanımızda verimli olmakla ilgili, eğer bu (buradaki) maddeyi kullanarak kılavuz, uzun vadede kullanımda zamandan tasarruf etmemi sağlıyor, eğer düşürmezseniz ve akıl sağlığınızdan tasarruf etmemi sağlıyor.

Bazı Magento'ya özgü "kötü uygulamalar" kırmızı bayraklar:

• herhangi bir kod app/code/local/Mage
• üzerine yazılmış şablonlar ( app/designçekirdekte zaten var olan dosyalar )
• gibi temel sınıfların yeniden yazılması catalog/product. Genel olarak, kaçınılması mümkün olup olmadığını görmek için her yazıya dikkatlice bakarım.
• Zend / Magento kodlama standartlarının ciddi şekilde ihlal edilmesi. Bu sadece kod biçimlendirme ile ilgili olmakla birlikte, standartlar konusunda dikkatsiz olan devlerin büyük olasılıkla diğer, daha önemli şeyler için de dikkatsiz olacağı sonucuna varıyorum.
• çekirdek veritabanı tablolarındaki değişiklikler
• Sert kodlanmış metinlerin şablonlarda (çeviri mekanizmasını kullanmadan) ve başka yerlerde
• şablonlarda iş mantığı (temel kural: Mage::getModelşablonlar dizininde herhangi bir oluşumu genellikle kötü bir işarettir)

PHP ile ilgili bazı kırmızı bayraklar (bu çok seçici ve eksik bir listedir):

• Hata bildirimi etkinleştirilmiş tüm Bildirimler ve Uyarılar ( E_STRICT)
• @operatörün kullanımı
• çıktıdan önce kullanıcı verilerini dezenfekte etmemek

Performansla ilgili bazı kırmızı bayraklar:

• döngüler içindeki veritabanı sorguları
• bir koleksiyonunu sadece bir kısmını kullanmak için yüklemek

Ayrıca genel Kod Kokularına da dikkat edin , bunlar zorunlu kırmızı bayraklar değil, genel kaliteyi tahmin etmeye yardımcı olur.

Adım # 1 - Geliştirici AWOL giderse müşteriniz bu eklentiyi destekleyebilir mi?

Hayır ise, uzantıyı kullanamazsınız.

Evetse, uzatma değerlendirmesine geçin.

Inchoo'daki iyi insanlar 3. parti modül kodunu analiz etmeye ilişkin bir makaleye sahipler . Makale, sınıf yeniden yazımlarından, cron işlerinden, düzen güncellemelerinden ve olay gözlemcilerinden bahsediyor.

Olay gözlemci kodunu, en yüksek performansa ulaşma potansiyeline sahip buldum. Yoğun gönderilen olaylar için çalışan, kaynak yoğun, üçüncü taraf kodunu arayın. Controller_action_predispatch veya koleksiyon yükleri gibi olaylar.

Kullandığım bu yarar modülünü yeniden yazar ve gözlemcilerin güzel özetini almak için Prattski dan.

Herhangi bir şablon ve kaplama varlıklarının baz / varsayılan yerine varsayılan / varsayılan (veya profesyonel veya kurumsal) olarak konumlandırılması oldukça can sıkıcıdır.

Gizli kod, dikkat edilmesi gereken bir şeydir - eval (), base64_decode () ve benzerlerine yapılan aramaları arayın. Bu genellikle lisans doğrulama için kullanılır, ancak kötü amaçlı veya korkutucu olabilir - Bir RSS beslemesinden sağlık kodunu değerlendiren en az bir bileşen gördüm.

Dl () çağrıları arayın - gördüğüm en az bir ödeme ağ geçidi bileşeni, bağlantılarını yapmak için bir PHP eklentisi kurmanızı gerektirir!

Haklısın.

Maalesef sihir yok: iyi test edilip edilmediğini görmek için kodları kontrol etmeniz, kodlarını kontrol etmeniz, forumlara ya da sorularınız için hızlı olmalarından dolayı ticari modüller için iyi bir destek almanız gerekiyor.

Magento Connect'te bazı incelemeler var ve bir uzantının popülaritesi değerli olup olmadığını bilmenize yardımcı olabilir ancak dürüst olmak gerekirse, çok fazla hata içeren çok popüler modüller bulabilirsiniz. MailChimp modülüyle geçen hafta iyi bir örnek aldım, çoğunlukla iyi iş çıkardım, ancak bazı hataları düzeltip geliştiriciye verdim. Her zaman risk vardır, test etmeniz gerekir.

WebShopApp bu yöne itme fikrine sahipti, modüller hakkında iyi bilgi edinmek için bir platform getirmek istiyorum. Fikir Magento’yu bu yöne itmektı. Yani modül kalitesi gerçek bir sorudur.

Tavsiyem: Çekirdek tablolardaki değerleri değiştiren yükleme / yükseltme komut dosyalarına sahip olan modüllere büyük özen gösterin çünkü bu tür değişiklikleri geri almak her zaman kolay değildir.

Bulabileceğim bir numaralı test, kodlarında sıfır günlük bir istismar bulmak (genellikle Magento uzantılarıyla pek de zor değil), yalnızca kendi güvenlik ekibine yapılan sahte bir istismarın verdiği hasarı rapor ediyor (bunun hangi olduğuna dair hiçbir bilgi vermeksizin) kodun bir kısmı savunmasızdır) ve kronometreyi başlat - çünkü siteniz saldırıya uğradığında tam olarak olacak olan budur. Destek personeli global FTP ve mysql erişimi istediğinde, PCI-DSS'yi ihlal ettiğini ve kaynak kod deponuza salt okunur erişime izin vermelerini önermeyi reddetti.

Yaptığım 2 numaralı test, satıcıyı çağırıp güvenlik görevlisini yakalamak. Ne tür davranış / birim testleri yaptıklarını, hangi kaynak kontrol sistemlerini kullandıklarını, hangi PHP sürümlerini test ettiklerini, Magento sürümlerinin test edildiğini, hangi web sunucularının test edildiğini, tarayıcı kullanıp kullanmadıklarını sorun. Ön uç bileşenleri, vs. test etmek için istifleyin ... Satıcı ne hakkında konuştuğunu bilmiyorsa, sessizleşir veya "size e-posta göndermek için bir uzmana başvurmak" isterse, cehennem gibi koşun, çünkü büyük olasılıkla numaralı kullanın "sürüm kontrolü" için zip dosyaları ve sadece müşterileri tarafından bildirildikten 3 ay sonra hataları düzeltin.

PCI-DSS'den bahsedersek, tüm sistem değişikliklerinin de bir reversiyon stratejisine sahip olmaları gerekir. Çekirdek tablolara kopyalanamayan sütunlar ekleyen modüller sayesinde, denetimden geçecek olan bir tersine çevirme stratejisi sürdürülürken, bu hemen hemen imkansız hale gelir. Devre dışı bırakıldığında sorunlara neden olan (okuma: SQL Hataları) herhangi bir modülden cehennem gibi çalıştırın.

PCI-DSS v3

6.4.5.4 Yedekleme prosedürleri.

Örneklenen her değişiklik için yedek prosedürlerin hazırlandığını doğrulayın.

Her değişiklik için, değişikliğin başarısız olması veya bir uygulamanın veya sistemin güvenliğini olumsuz yönde etkilemesi durumunda, sistemin önceki durumuna geri döndürülmesini sağlamak için belgelenmiş yedekleme prosedürleri bulunmalıdır.

Bu, diğer cevaplara ek olarak. IMO, bu platformda ortaya çıkmış bazı tehlikeli saçmalıklar için bir utanç duvarı olmalı.