Wie evaluiere ich Erweiterungen von Drittanbietern?

Magento macht zwar eine Menge "out of the box", aber wir haben festgestellt, dass es unvermeidlich Funktionen und Einrichtungen gibt, die für Kundengeschäfte benötigt werden, für die eine Erweiterung von Drittanbietern erforderlich ist.

Angesichts der Art des Mediums kann es jedoch ein riskantes Unterfangen sein, einen "fremden" Code in ein so komplexes System einzuführen, das sich mit kommerziellen Transaktionen befasst.

Worauf achten Sie bei der Evaluierung von Magento-Erweiterungen? Was sind die „roten Fahnen“, auf die Sie gestoßen sind (Leistungsschwein, Sicherheitsrisiken, schlechte Architekturpraktiken)?

Hier einige Gedanken zur Evaluierung von Drittanbieter-Modulen:

Grundlagen:

• Unterstützung der aktuellen Magento-Version - Unterstützt sie die neueste Version von Magento (einschließlich der aktuellen Version, für die wir sie entwickeln)?

  Wenn ein Modul die neueste Version von Magento nicht unterstützt, wird es wahrscheinlich schwierig sein, es zum Laufen zu bringen, ohne dafür wertvolle Entwicklungszeit aufzuwenden.

• Support - Unterstützen die Entwickler, die das Modul erstellt haben, das Produkt?

  Ein Zeichen für ein gesundes Modul ist, dass die Entwickler es aktiv unterstützen. Wenn sie es nicht unterstützen, ist es eine rote Fahne, warum werden sie das Produkt nicht unterstützen, wenn es gut ist?

  Wenn ein Modul unterstützt wird, können wir in der Regel wichtige Informationen von den Entwicklern per E-Mail erhalten (verwendet dieses Modul beispielsweise jQuery oder Prototype).

• Rezensionen - Was sagen andere Benutzer? Wie war ihre Erfahrung?

  Wenn wir die Bewertungen lesen, können wir einen besseren Überblick über das Gesamtbild gewinnen. Gibt es ein Installationsproblem? Reagieren die Entwickler rechtzeitig und hilfreich? Funktioniert es wie angekündigt?

• Rückerstattung - Werden sie Ihnen Ihr Geld zurückgeben, wenn es nicht wie beabsichtigt funktioniert?

  Oft möchten wir das Modul ausprobieren, damit wir es testen können, ob es funktioniert und unseren Spezifikationen entspricht! Wenn dies nicht der Fall ist, möchten wir, dass Sie es zurücksenden und eine Rückerstattung erhalten.

Mittlere:

• Klassenüberschreibungen - Überschreibt das Modul Kernklassen?

  Generell sollte ein gutes Modul keine Kernklassen überschreiben, sondern Observer verwenden.

  Ein Grund dafür ist, dass es schwierig sein kann, Magento zu aktualisieren. Darüber hinaus hängen andere Module möglicherweise von einem Ausgang einer bestimmten Funktion ab, und dieses Modul stellt einen anderen zur Verfügung.

  Manchmal ist dies nicht möglich, wenn dies der Fall ist, sollte es einen sehr guten Grund geben, warum es eine Kernklasse überschreibt.

• Layout-Updates - Ändert das Modul einige meiner Layout-Einstellungen?

  Einige Module ändern die Layout-Einstellungen Ihrer Site (zum Beispiel: Produktseite), stellen sicher, dass Ihr aktuelles Layout nicht beschädigt wird, und ob dies erforderlich ist (lesen Sie: Wie viel Zeit benötigen wir, um das Problem zu beheben) .

• Vorlagenänderungen - Enthält das Modul Vorlagen, die mein aktuelles Design ändern?

  Führt dieses Modul neue Vorlagen ein? Wenn ja, brechen sie mein Design? Wie viel Zeit wird es brauchen, um das Design so zu gestalten, wie wir es wollen?

• Abhängigkeiten - Ist das Modul von einem anderen Modul abhängig?

  Wenn das Modul von anderen abhängig ist, müssen wir sicherstellen, dass diese vorhanden und installiert sind. Außerdem müssen wir uns fragen, ob wir das Modul, von dem es abhängt, in Zukunft ausschalten möchten.

Fortgeschrittene:

• SQL-Upgrade-Skripte - Aktualisiert das Modul die Datenbank auf irgendeine Weise?

  Sobald ein Modul die Datenbank aktualisiert, müssen wir einige Dinge sicherstellen.

  Aktualisiert es eine Kerntabelle? Wenn ja, ist das nicht gut, wir mögen unsere Datenbanken sauber und bereit für ein Upgrade.

  Speichert es die Informationen auf vernünftige Weise? Wenn wir die Rohdaten selbst aus der Datenbank abrufen möchten, können wir dann einen Sinn daraus ziehen?

• Ereignisse - Beobachtet oder versendet das Modul Ereignisse?

  Wenn ein Modul Ereignisse auslöst oder beobachtet, möchten wir Folgendes wissen:

  Welche Ereignisse beobachtet / sendet es? Betrifft dies ein anderes Modul, das im System arbeitet? Wenn beispielsweise eines unserer Module den Namen unserer geladenen Produkte in Großbuchstaben ändert und dieses Modul dem Namen des geladenen Produkts das Wort "free" hinzufügt, wie funktioniert es? Kommt das Wort "frei" auch in Großbuchstaben heraus?

• Code Review - Verwendet das Modul akzeptable Codierungstechniken?

  Dies hat mehr mit PHP-Codierungstechniken zu tun als mit Magento.

  Verwendet der Code Try / Catch-Blöcke?

  Entgeht der Code der Benutzereingabe?

  Die Einzelheiten hängen wirklich von unseren Fähigkeiten / Anforderungen ab.

• Mögliche Probleme - Welche potenziellen Probleme können durch die Installation dieses Moduls auftreten?

  Versuchen Sie sich die fünf wichtigsten Probleme vorzustellen, die bei der Installation dieses Moduls auftreten könnten. So überraschend es auch sein mag, es gibt wirklich einen Einblick in das gesamte Projekt.

Endeffekt:

All diese Dinge sind schön in einer idealen Welt zu haben, in realen Szenarien müssen wir dieses Ding namens "Kompromiss" machen :)

Darüber hinaus sollen diese Richtlinien uns helfen und nicht behindern, da wir nur ein Modul installieren, beispielsweise ein Social-Sharing-Modul, und es für einen Kunden ist, der dort eine einfache Site-Einrichtung benötigt Es macht keinen Sinn, eine Menge Forschung zu betreiben.

Mit anderen Worten: Es geht darum, effizient mit unserer Zeit umzugehen, wenn die Verwendung dieser (in der Richtlinie genannten) Richtlinie mir hilft, auf lange Sicht Zeit zu sparen, sie zu verwenden, wenn sie nicht fallen gelassen wird, und Ihre geistige Gesundheit zu retten.

Einige Magento-spezifische "Bad Practice" -Rotflags sind:

• irgendein Code in app/code/local/Mage
• überschriebene Vorlagen (Dateien app/design, die bereits im Core vorhanden sind)
• Umschreibungen wesentlicher Klassen wie catalog/product. Im Allgemeinen schaue ich mir jedes Umschreiben genau an, um festzustellen, ob es hätte vermieden werden können
• schwere Verstöße gegen die Zend / Magento-Kodierungsstandards. Während es hier nur um die Formatierung von Code geht, komme ich zu dem Schluss, dass Entwickler, die sich nicht mit Standards befassen, höchstwahrscheinlich auch nicht mit anderen, wichtigeren Dingen befasst sind.
• Änderungen in Kerndatenbanktabellen
• fest codierter Text in Vorlagen (ohne Verwendung des Übersetzungsmechanismus) und an anderer Stelle
• Geschäftslogik in Vorlagen (Faustregel: Jedes Vorkommen Mage::getModelim Vorlagenverzeichnis ist normalerweise ein schlechtes Zeichen)

Einige PHP-bezogene rote Fahnen (dies ist eine sehr selektive und unvollständige Liste):

• Hinweise und Warnungen mit aktivierter Fehlerberichterstattung ( E_STRICT)
• Nutzung des @Betreibers
• Benutzerdaten werden vor der Ausgabe nicht bereinigt

Einige leistungsbezogene rote Fahnen:

• Datenbankabfragen innerhalb von Schleifen
• Laden einer ganzen Sammlung, nur um einen Teil davon zu nutzen

Achten Sie auch auf allgemeine Code-Gerüche . Diese sind keine notwendigen roten Fahnen, sondern helfen bei der Einschätzung der Gesamtqualität.

Schritt 1 - Kann sich Ihr Kunde leisten, diese Erweiterung zu unterstützen, wenn der Entwickler AWOL verwendet?

Wenn nein, können Sie die Erweiterung nicht verwenden.

Wenn ja, fahren Sie mit der Evaluierung der Erweiterung fort.

Die feinen Leute bei Inchoo haben einen Artikel über das Analysieren von Modulcode von Drittanbietern. In dem Artikel werden Umschreibungen von Klassen, Cron-Jobs, Layout-Aktualisierungen und Ereignisbeobachter erwähnt.

Ich habe festgestellt, dass Event-Observer-Code das Potenzial für den höchsten Leistungstreffer hat. Achten Sie auf ressourcenintensiven Code von Drittanbietern, der für häufig ausgelöste Ereignisse ausgeführt wird. Ereignisse wie controller_action_predispatch oder Auflistungsladevorgänge.

Ich benutze dieses Utility-Modul von Prattski, um einen schönen Überblick über das Umschreiben und Beobachten zu bekommen.

Es ist ziemlich ärgerlich, wenn sich Vorlagen und Skin-Assets in default / default (oder pro oder enterprise) anstelle von base / default befinden.

Verschleierter Code ist etwas, auf das Sie achten müssen - suchen Sie nach Aufrufen von eval (), base64_decode () und dergleichen. Dies wird häufig für die Lizenzüberprüfung verwendet, kann jedoch bösartig oder beängstigend sein. Ich habe mindestens eine Komponente gesehen, die beliebigen Code aus einem RSS-Feed ausgewertet hat.

Suchen Sie nach dl () -Aufrufen - für mindestens eine Zahlungsgateway-Komponente, die ich gesehen habe, muss eine PHP-Erweiterung installiert werden, damit die Verbindungen hergestellt werden können!

Du hast recht.

Es gibt leider keine Magie: Sie müssen sie testen, den Code überprüfen, um zu sehen, ob er gut entwickelt ist, eine gute Unterstützung für kommerzielle Module haben, dank ihres Forums oder der schnellen Beantwortung Ihrer Fragen ...

Es gibt einige Rezensionen zu Magento Connect und die Beliebtheit einer Erweiterung kann helfen zu wissen, ob sie wertvoll ist oder nicht, aber ehrlich gesagt, finden Sie sehr beliebte Module mit vielen Fehlern. Ich hatte letzte Woche ein gutes Beispiel mit einem MailChimp-Modul, hauptsächlich gut gemacht, aber ich musste einige Fehler beheben und sie dem Entwickler zur Verfügung stellen. Es gibt immer Risiken, die Sie testen müssen.

WebShopApp hatte die Idee, in diese Richtung zu gehen, ich meine, eine Plattform zu bringen, um gute Informationen über die Module zu erhalten. Die Idee war, Magento in diese Richtung zu treiben. Die Modulqualität ist also eine eigentliche Frage.

Mein Rat: Achten Sie besonders auf Module mit Installations- / Aktualisierungsskripten, die Werte in Kerntabellen ändern, da es nicht immer einfach ist, diese Änderungen rückgängig zu machen.

Der beste Test, den ich finden kann, besteht darin, einen Zero-Day-Exploit in ihrem Code zu finden (normalerweise nicht sehr schwierig bei Magento-Erweiterungen) und nur den resultierenden Schaden eines nachgebildeten Exploits ihrem Sicherheitsteam mitzuteilen (ohne Angabe eines Exploits) Ein Teil des Codes ist angreifbar. Starten Sie die Stoppuhr, denn genau dies wird passieren, wenn Ihre Site gehackt wird. Wenn ihre Support-Mitarbeiter nach globalem FTP- und MySQL-Zugriff fragen, lehnen Sie höflich ab, dass dies einen Verstoß gegen das PCI-DSS darstellt, und bieten Sie ihnen an, nur Lesezugriff auf Ihr Quellcode-Repository zu gewähren.

Der Test Nr. 2, den ich durchführe, besteht darin, den Verkäufer anzurufen und ihn unvorbereitet zu erwischen. Fragen Sie sie, welche Art von Verhaltens- / Unit-Tests sie durchführen, welches Quellcodeverwaltungssystem sie verwenden, auf welchen PHP-Versionen sie testen, auf welchen Magento-Versionen sie testen, auf welchen Webservern sie Browser verwenden oder nicht -Stack zum Testen von Front-End-Komponenten usw. Wenn der Anbieter nicht weiß, wovon Sie sprechen, sich ausschaltet oder "einen Experten dazu bringen möchte, Sie per E-Mail zurückzuschicken", laufen Sie wie verrückt, weil er höchstwahrscheinlich nummerierte Komponenten verwendet zip-Dateien für die "Versionskontrolle" und die Behebung von Fehlern erst 3 Monate, nachdem ihre Kunden sie gemeldet haben.

Apropos PCI-DSS: Alle Systemmodifikationen erfordern auch eine Umkehrstrategie. Mit Modulen, die Kerntabellen nicht nullfähige Spalten hinzufügen, wird dies nahezu unmöglich, während eine Reverse-Strategie beibehalten wird, die eine Prüfung bestehen würde. Führen Sie alle Module aus, die bei Deaktivierung Probleme verursachen (siehe SQL-Fehler).

PCI-DSS v3

6.4.5.4 Verfahren zum Zurücksetzen.

Stellen Sie sicher, dass für jede Stichprobenänderung ein Zurücksetzungsverfahren vorbereitet wurde.

Für jede Änderung sollte ein Verfahren zum Zurücksetzen dokumentiert werden, falls die Änderung fehlschlägt oder die Sicherheit einer Anwendung oder eines Systems beeinträchtigt, damit das System in den vorherigen Zustand zurückversetzt werden kann

Dies zusätzlich zu den anderen Antworten. IMO sollte es eine Mauer der Schande für den gefährlichen Mist geben, der auf dieser Plattform aufgetaucht ist.