Wie schreibe ich eine benutzerdefinierte Erweiterung?

143

Da ich in letzter Zeit viele Probleme mit kostenlosen und kommerziellen Erweiterungen hatte, habe ich beschlossen, diese Frage zu stellen und mit den Schritten zu beantworten, die ich normalerweise beim Schreiben einer Erweiterung befolge. Sie können die Antwort jederzeit bearbeiten oder eine neue hinzufügen.
In den meisten Fällen muss ich beim Installieren einer Erweiterung oder eines Themas einige Stunden (manchmal mehr, manchmal weniger) aufwenden, damit es in allen von mir benötigten Umgebungen funktioniert:

  • dev: normalerweise, localhostwenn sich das Projekt in einem Unterordner befindet
  • preprod & live

Dies ist sogar bei Erweiterungen von großen Erweiterungsanbietern der Fall (die zumindest so lange namenlos bleiben sollten, bis ich wirklich verrückt werde und ihre Namen hier hinzufüge).
Die Hauptfrage ist also, welche Schritte ich beim Schreiben einer Erweiterung beachten muss, um die Qualität sicherzustellen des Codes zu ändern und es einer technischen und nichttechnischen Person zu erleichtern, ihn zu verwenden, und einer technischen Person, ihn zu ändern?

Marius
quelle
11
Es scheint, dass einer der großen Erweiterungsanbieter diese Frage nicht mochte und sie ablehnte. :)
Marius
1
Persönlich absolut kein Problem mit Wyomind, aber sie verschlüsseln ihren Code und sind immer noch "Premium-Partner" :( (nur zum Beispiel)
Sv3n

Antworten:

185

Folgendes mache ich normalerweise:

  1. Entwickeln Sie immer mit error_reportingauf.
  2. Entwickle immer mit isDeveloperModeset to true. Füge SetEnv MAGE_IS_DEVELOPER_MODE 1es einfach zu deiner httpd.confDatei hinzu (oder der entsprechenden Datei für Nginx oder etwas anderes)
  3. Wenn die Erweiterung mit einer Kernfunktionalität verknüpft ist, fügen Sie die Abhängigkeit in die Deklarationsdatei ein <depends><Mage_Catalog /></depend>
  4. Wenn das Modul für die Community bestimmt ist, können Sie es communityals Codepool verwenden, um den Entwicklern die Möglichkeit zu geben, einige Klassen zu überschreiben, ohne den Code direkt zu ändern
  5. Fügen Sie Ihre Frontend-Designdateien ein app/design/frontend/base/default , um sie für alle Themen verfügbar zu machen.
  6. Fügen Sie Ihre Admin-Designdateien ein app/design/adminhtml/default/defaultund ändern Sie das Admin-Design nicht. Ich möchte es vielleicht in einem meiner Module ändern.
  7. Stellen Sie Ihren Namen der Layoutdatei und des Vorlagenordners den Firmennamen voran, damit Sie sie leichter isolieren können. easylife_articles.xmlundapp/design/.../easylife_articles
  8. Platzieren Sie Ihre statischen Ressourcen (JavaScript, CSS und Bilder) in einem ähnlichen Ordner wie die Vorlagendateien easylife_articles/images/doh.png
  9. Hängen Sie eine einfache Textdatei an, in der angegeben ist, wie die Erweiterung deinstalliert werden soll: Welche Dateien müssen entfernt werden, welche Tabellen müssen gelöscht werden, welche Konfigurationseinstellungen müssen aus der core_config_dataTabelle entfernt werden.
  10. Schreiben Sie keine Abfragen direkt in Modelle, Blöcke oder Helfer, verwenden Sie dafür ein Ressourcenmodell.
  11. Schreiben Sie keine Abfragen direkt unter Verwendung der Tabellennamen Select * from sales_flat_order where .... Verwenden Sie a Zend_Selectund transformieren Sie die Tabellennamen mit ->getTable('sales/order').
  12. Verwenden Sie die Basis-URL, um jsDateien in die Vorlage aufzunehmen. Falsch <script type="text/javascript" src="../js/some.js"></script> . Richtig <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
  13. Schreiben Sie keine Klassen neu, es sei denn, dies ist erforderlich. Verwenden Sie Beobachter, und wenn es nicht möglich ist, Hilfsmethoden zu verwenden, die als Parameter und Instanz einer Klasse empfangen werden, die Sie überschreiben möchten. Falsch : Überschreiben Mage_Catalog_Model_Product, um die Methode hinzuzufügen getProductArticles(). Richtig . In Ihrem Helfer hinzufügen getProductArticles(Mage_Catalog_Model_Product $product)
  14. Wenn Sie Klassen überschreiben, fügen Sie eine Liste dieser Klassen in eine readme.txtDatei ein
  15. Verwenden Sie den Standard-Admin-Pfad für den Admin-Bereich Ihres Moduls. Falsche Admin-URL articles/adminhtml_articles/index . Rechte Admin-URL admin/articles/index
  16. Fügen Sie eine ACL für Ihre Administratorabschnitte hinzu. Ich möchte möglicherweise den Zugriff auf einige Administratoren einschränken.
  17. Fügen Sie kein weiteres JavaScript-Framework (jQuery, MooTools usw.) hinzu, wenn dies nicht erforderlich ist. Schreiben Sie Ihren Code in den Prototyp.
  18. Machen Sie Ihre HTML W3C-Vorlage gültig (dies ist für OCD-Entwickler wie mich).
  19. Legen Sie keine Bilder in den mediaOrdner. Verwenden Sie skin. Der media Ordner ist normalerweise nicht versioniert und dies erschwert das Verschieben der Website in andere Umgebungen.
  20. Testen Sie Ihre Erweiterung mit ein- und ausgeschaltetem Flat-Katalog. Verwenden Sie Chaos Monkey , um die Entwicklungszeit nicht zu verdoppeln .
  21. Testen Sie Ihre Erweiterung mit Cache onund Cache off.
  22. Vermeiden Sie die Verwendung von Großbuchstaben in den Modul- und Klassennamen. Wenn dies nicht ordnungsgemäß getestet wird, kann dies zu Problemen bei verschiedenen Betriebssystemen führen. Dies ist eher eine Empfehlung, kein "Muss".
  23. Versenden Sie Ereignisse in Ihrem Code, um Entwicklern das Ändern der Funktionalität zu erleichtern.
  24. Befolgen Sie die gleichen Codierungsstandards, die Magento verwendet, und kommentieren Sie Ihren Code.
  25. Verwenden Sie keine kurzen PHP-Tags ( <? $this->doSomething() ?>). Verwenden Sie vollständige Tags ( <?php $this->doSomething()?>). Verwenden Sie auch noch keine kurzen Echo-Tags. ( <?="D'oh";?>). Benutze ( <?php echo "D'oh";?>)
  26. Übersetzen Sie Ihre Texte mit $this->__und fügen Sie die Übersetzungsdatei für das Gebietsschema mit Ihren Texten ( app/local/en_US/Easylife_Articles.csv) hinzu, zumindest für die en_USSprache. Nicht alle Websites sind in englischer Sprache erstellt und die Identifizierung der zu übersetzenden Texte ist zeitaufwändig.
  27. Wenn Sie eine Erweiterung verkaufen, bieten Sie mindestens grundlegende Unterstützung an. Oder beantworten Sie zumindest die Support-E-Mails, die Sie erhalten.
  28. Rufen Sie Ihre Server nicht ständig über Ihre Nebenstelle an, um die Lizenz zu überprüfen. Einmal bei der Installation ist mehr als genug (ich mag diesen Ansatz auch nicht, aber es ist besser, als die ganze Zeit Anrufe zu tätigen). (Inspiriert von dieser Frage )
  29. Entwickeln Sie mit aktiviertem Protokoll und schauen Sie sich von Zeit zu Zeit die var/log/system.logDatei an. Die hier aufgeführten Fehler werden auch im Entwicklermodus nicht angezeigt. Wenn mindestens ein Fehler auftritt, wird nach einigen Monaten des Ausführens der Erweiterung eine große Protokolldatei angezeigt.
  30. Wenn Ihre Erweiterung den Bestellvorgang oder die Bestellungen in irgendeiner Weise beeinflusst, stellen Sie sicher, dass es mit Mehrfachversand funktioniert, oder wenn es nicht mit Mehrfachversand funktioniert, stellen Sie sicher, dass es keine Auswirkungen hat.
  31. Ersetzen Sie nicht die standardmäßige Administratorbenachrichtigungsleiste (oder Feed-URL). Wenn ich an Ihren Angeboten interessiert bin, abonniere ich Ihren Newsletter. Lassen Sie mich sehen, was Magento zu sagen hat. Es ist mir wichtiger.
  32. Wenn Sie Ihre Codedateien mit Ioncube (oder etwas anderem) verschlüsseln ... naja ... ich hasse Sie einfach und hoffe, dass Ihr Geschäft bankrott geht

Das ist was bisher. Ich werde mehr hinzufügen, sobald mir etwas anderes einfällt.

Marius
quelle
Ich stimme dir zu, es ist definitiv ein guter Anfang. Sie werden sicherlich auch verstehen, dass es nicht immer möglich ist, alle Arten von Konfigurationen und Problemen abzudecken, zumindest wird dies die mögliche reduzieren. Die meisten Probleme, die ich mit anderen Nebenstellen oder meinen habe, sind auf Überschreibungskonflikte zurückzuführen.
Sylvain Rayé
2
@ Marius, sicher 1+ von me.it deckt die meisten Fälle und Szenarien ab, mit denen wir in der Entwicklung konfrontiert sind.
Liyakat
4
@ColinM. Zunächst ist es mir eine Ehre, Ihren Kommentar hier zu haben. :). Ich bin damit einverstanden, dass es einen Unterschied gibt, ich werde die Antwort ändern, aber ich denke immer noch, dass beide vermieden werden sollten, zumindest bis PHP 5.3 das "neue PHP 4" wird. Ich meine, es wird immer noch in großem Maßstab verwendet.
Marius
4
@Marius, deine Punkte sind sehr hilfreich. Bis # 31 habe ich mich ernsthaft auf jeden Punkt konzentriert, aber auf # 32 habe ich nur laut gelacht. +1 speziell für Punkt # 32
MTM
1
If you encrypt your code files with Ioncube (or something else)...well...I just hate you and I hope your business goes bankruptIch fühle das gleiche. Es gibt einige Unternehmen, die keine aktualisierte Version anbieten, für die Sie bezahlen müssen. Für mich ist das sehr frustrierend und ich verstehe nicht, warum sie dasselbe Produkt immer wieder verkaufen möchten (um Geld zu verdienen? Natürlich). Ich kaufe ihr Produkt einfach nicht mehr. Sie wissen, über wen ich spreche.
Adarsh ​​Khatri
31

Ich bin ein großer Fan von Modman, damit ich nur meine Erweiterung entwickeln und die Quellcodeverwaltung durchführen kann und die Kerndateien und die Ordnerstruktur unverändert lassen kann. Dadurch wird auch das Testen über verschiedene Installationen hinweg reibungsloser.

Oh und ein großer Tipp: Versuchen Sie immer, Ihre paketierte Erweiterung lokal auf einer Neuinstallation von Magento zu installieren, bevor Sie sie auf Magento Connect hochladen. Ich habe so oft Dateien im Paket-Manager verpasst.

David Manners
quelle
3
Guter Anruf zum Thema "Installiere deine gepackte Erweiterung lokal". Ich denke, dies fällt in die Kategorie: "Testen Sie Ihre gottverdammte Erweiterung von oben nach unten".
Marius
Das hat mich auch schon mal erwischt. Stellen Sie sicher, dass Sie das Paket in einer sauberen Installation testen, die nicht mit der identisch ist , in der Sie es verpackt haben!
Joseph Leedy
22

Andreas von Studnitz und Dr. Nikolai Krambrock haben auf dem Meet Magento DE 2014 eine gute Präsentation zur Codequalität gehalten. Sie unterscheiden zwischen allgemeiner Codequalität und Magento-spezifischer Codequalität. Kurz gesagt gibt es die folgenden allgemeinen Regeln:

  • Die Verwendung von Strukturelementen sollte - ebenso wie Klassen und Methoden - in Klassen mittlerer Größe angeordnet werden. Diese Elemente der Struktur sind nur dann sinnvoll, wenn sie zur Strukturierung verwendet werden. Deshalb müssen sie mittelgroß sein. Es wird davon ausgegangen, dass 100-200 Codezeilen für Klassen und 3-20 Codezeilen für Methoden verwendet werden.
  • Aufgrund der Verwendung von "if" oder "while" wird der Code eingerückt. Wenn es mehr als 3 Einrückungen gibt, ist es besser, sie zu überarbeiten. Zu viele Einrückungen belegen die Komplexität des Codes und sollten daher vermieden werden.
  • Dead Code sollte vermieden und gelöscht werden. Statische Analysen helfen dabei, festzustellen, ob eine existiert.

Noch wichtiger sind die Magento-spezifischen Regeln:

  • Module sollten unabhängig voneinander arbeiten. Sie sollten nur eine geringe Abhängigkeit von anderen Modulen und keine Abhängigkeit von Vorlagen aufweisen. Eine Lösung besteht darin, Layout-Updates (Basis / Standard) anstelle der Anpassung an Vorlagendateien und ein Modul zu verwenden, das zusätzliche Funktionen der Vorlage abdeckt.
  • Um die Updatefähigkeit in Magento zu erhalten, sollten Core-Hacks und Hacks von externen Modulen vermieden werden. Ein besserer Weg ist der Einsatz von Redakteuren oder Beobachtern.
  • Für Änderungen ist es besser, Setup-Skripte anstelle von direkten Änderungen der Datenbank oder des Administrators zu verwenden. Dank ihnen müssen Änderungen nur einmal vorgenommen werden.

Hier einige Details und ein Video der Präsentation: http://www.code4business.de/code-quality-magento/

user3743859
quelle
1
Wenn Sie jedoch eine englische Version des von Ihnen geposteten Links hätten, wäre dies sogar noch besser.
Marius
Eine englische Version dieser Präsentation wird in Kürze veröffentlicht. Ich werde Sie auf dem Laufenden halten und den neuen Link teilen, sobald die englische Version veröffentlicht ist.
user3743859
Eine englische Version der Präsentation ist jetzt online. Hier ist der Link dazu: code4business.de/code-quality-magento
user3743859
huh? Es ist immer noch auf Deutsch. Aber ich war gerade vor ungefähr zwei Wochen auf Englisch bei MeetMagentRo. Tolles Zeug.
Marius
18

Wenn Sie Ihre Erweiterung verkaufen oder mit anderen teilen, sollten Sie darüber nachdenken, Code zu schreiben, der für Menschen lesbar ist.

  1. Mach die Methode nicht zu komplex
  2. Hinzufügen von DOC-Blöcken zu Ihren Methoden *
  3. Verwenden Sie richtige Variablennamen wie $productIdsanstelle von$ids
  4. das gleiche gilt für methoden, public function myOnProductSaveMethod() {...}sagt ... nichts, tryDisableInternetOnProductSave()will aber einen tipp geben der geplant ist
  5. Verwenden Sie Tippe, wo es Sinn macht someMethod(Varien_Data_Db_Collection $collection)
  6. Vermeiden Sie magische Zahlen und Zeichenketten **
  7. Wenn Sie Modelle verwenden, setzen Sie die $_eventPrefixEigenschaft (und $_eventObject), um sie den Beobachtern besser zugänglich zu machen
  8. Wenn Sie Systemkonfigurationsfelder hinzufügen
    • Standardwerte setzen in config.xml
    • Hinzufügen von <validate>Knoten zu Feldern insystem.xml
    • ACL-Ressourcen hinzufügen adminhtml.xml
  9. Fügen Sie keine nutzlosen / werbenden Menüeinträge der ersten Ebene im Admin-Backend hinzu - weder in der oberen Leiste noch in den Konfigurationsabschnitten
  10. ACL-Ressourcen für alle Controller-Aktionen hinzufügen (auch Massen!)
  11. Stellen Sie sicher, dass Ihre Abfragen mit Präfixen für DB- Tabellen funktionieren
  12. Denken Sie über (keine) Rückwärtskompatibilität nach (dies ist wirklich meinungsbasiert)
    • unterstütze keine Mysql4Klassen
    • Verwenden Sie keine veralteten Methoden
  13. Stellen Sie sicher, dass Ihre Erweiterung in jedem Fall wie erwartet funktioniert - fügen Sie UnitTests hinzu (z. B. PhpUnit).
  14. zusätzlich zu David Manners ... fügen Sie einen hinzu composer.json, um die Bereitstellung zu vereinfachen
  15. Da PHP5.6 EOL ist, schreiben Sie Ihren Code für PHP7. Verwenden declare(strict_types=1);und definieren Sie Ihre Ein- und Ausgabetypen
  16. Magento2: Überprüfen Sie Ihren Code mit statischen Code-Analyse-Tools wie phpstan . Unterstützung für magische Methoden hier . (Das letzte Festschreiben funktioniert mit 2.3, davor für 2.1 / 2.2 - erfordert Phpstan 0.8.5)

* DOC-Blöcke:

Wenn Sie Ihren Magento-1-Code mit PHP_CodeSniffer für PSR2-Standard oder PHPMD überprüfen, möchten Sie möglicherweise diese Zeilen hinzufügen (wo es Sinn macht) ...

  • zu Klassen
    • @phpcs:disable PSR1.Classes.ClassDeclaration.MissingNamespace
    • @phpcs:disable PSR2.Classes.PropertyDeclaration.Underscore - geerbte Eigenschaften
    • @phpcs:disable Squiz.Classes.ValidClassName.NotCamelCaps
    • @SuppressWarnings(PHPMD.CamelCaseClassName)
    • @SuppressWarnings(PHPMD.CamelCasePropertyName) - geerbte Eigenschaften
  • zu Methoden
    • @SuppressWarnings(PHPMD.CamelCaseMethodName) - geerbte Methoden
    • @SuppressWarnings(PHPMD.StaticAccess)- wenn Sie Mage::oder andere statische Anrufe verwenden

** Oft benutzt:

  • Admin Store ID
    • 0 > Mage_Core_Model_App::ADMIN_STORE_ID
  • Produkt status
    • 1 > Mage_Catalog_Model_Product_Status::STATUS_ENABLED
    • 2> Mage_Catalog_Model_Product_Status::STATUS_DISABLED (nicht 0wie erwartet)
  • Produkt type
    • simple > Mage_Catalog_Model_Product_Type::TYPE_SIMPLE
    • bundle > Mage_Catalog_Model_Product_Type::TYPE_BUNDLE
    • configurable > Mage_Catalog_Model_Product_Type::TYPE_CONFIGURABLE
    • grouped > Mage_Catalog_Model_Product_Type::TYPE_GROUPED
    • virtual > Mage_Catalog_Model_Product_Type::TYPE_VIRTUAL
  • Produkt visibity
    • 1 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_NOT_VISIBLE
    • 2 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_IN_CATALOG
    • 3 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_IN_SEARCH
    • 4 > Mage_Catalog_Model_Product_Visibility::VISIBILITY_BOTH

Gleiches gilt für die SQL-Reihenfolge im ASCVergleich zu Zend_Db_Select::SQL_ASC (zum Beispiel) .

Zu sagen, "es ist nicht notwendig, weil es sich nie ändern wird" ? Zum Beispiel Entity ID für catalog_productAttribute, die irgendwo zwischen Magento 1.5 und 1.9 von 10nach geändert wurden 4, so dass dies Ihre Erweiterung beschädigen könnte:

$collection->addFieldToFilter('entity_type_id', 10)

Wenn Sie dies verwenden, wird stattdessen eine Abfrage hinzugefügt, aber Sie sind sicher ...

$entityTypeId = Mage::getModel('eav/config')
    ->getEntityType(Mage_Catalog_Model_Product::ENTITY)
    ->getEntityTypeId();

$collection->addFieldToFilter('entity_type_id', $entityTypeId)
sv3n
quelle
8

@marius, bezüglich der Kodierungsstandards (Punkt 24 in Ihrer Liste).

Ich verwende gerne PHP_CodeSniffer zusammen mit EQP und ECG CS, um diese Standards automatisch durchzusetzen.

Mit PHP_CodeSniffer Sie müssen sich keine Sorgen über Dinge zu vergessen , wie zu ersetzen array()mit [], vermeiden Sie is_null, lassen Sie nicht verwendeten lokalen Variablen oder auch ein Verfahren ohne PHPDoc Block.

PHP_CodeSniffer wird Sie immer darüber informieren .

Diazwatson
quelle
Einverstanden! Mögliches Howto: magento.stackexchange.com/questions/178640/…
sv3n
Ich denke, es gibt keine Möglichkeit, beide CS in PHPStorm zu konfigurieren (für diejenigen, die PHPStorm verwenden), aber Sie können immer das Terminal verwenden, um die CS in Ihrem Code zu überprüfen. Es gibt auch Tools wie grumphp github.com/phpro/grumphp , die ein bisschen helfen.
Diazwatson
Es könnte Ihnen helfen, magento.stackexchange.com/questions/200022/…
Pramod Kharade