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)?
performance
extensions
Junap
quelle
quelle
Antworten:
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.
quelle
Einige Magento-spezifische "Bad Practice" -Rotflags sind:
app/code/local/Mageapp/design, die bereits im Core vorhanden sind)catalog/product. Im Allgemeinen schaue ich mir jedes Umschreiben genau an, um festzustellen, ob es hätte vermieden werden könnenMage::getModelim Vorlagenverzeichnis ist normalerweise ein schlechtes Zeichen)Einige PHP-bezogene rote Fahnen (dies ist eine sehr selektive und unvollständige Liste):
E_STRICT)@BetreibersEinige leistungsbezogene rote Fahnen:
Achten Sie auch auf allgemeine Code-Gerüche . Diese sind keine notwendigen roten Fahnen, sondern helfen bei der Einschätzung der Gesamtqualität.
quelle
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.
quelle
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.
quelle
*_afterEreignisse anstelle von*_beforeEreignissen zu verwenden, wenn dies möglich ist. In Bezug auf die Leistung gibt es überhaupt keine Aussage über Beobachter.controller_action_predispatcheinmal pro Anfrage verschickt, also ist das vielleicht nicht das beste Beispiel. Aber obwohl Sie nur ein hohes Potenzial für Leistungsprobleme erwähnen und es Ereignisse gibt, die viel häufiger pro Anfrage ausgelöst werden, bin ich anderer Meinung: Beobachter sind nicht mehr oder weniger anfällig für Leistungsprobleme als jeder andere Code. Wenn Sie Dinge tun, die sich wirklich auf die Leistung auswirken, wie z. B. das Laden aller Produkte, ist dies ein eigenständiges Problem, unabhängig davon, wo es auftritt.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!
quelle
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.
quelle
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.
quelle
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).
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.
quelle