Comment écrire une extension personnalisée?

Comme j'ai récemment eu beaucoup de problèmes avec les extensions gratuites et commerciales, j'ai décidé de poser cette question et d'y répondre avec les étapes que je suis habituellement en train d'écrire une extension. N'hésitez pas à modifier la réponse ou à en ajouter une nouvelle.
Dans la plupart des cas, lors de l'installation d'une extension ou d'un thème, je dois passer quelques heures (parfois plus, parfois moins) à le faire fonctionner dans tous les environnements dont j'ai besoin:

• dev: généralement localhostoù le projet est dans un sous-dossier
• preprod & live

Ce qui est arrivé même avec des extensions de grands fournisseurs d'extension (qui doivent rester anonymes au moins jusqu'à ce que je suis vraiment vraiment en colère et ajouter leur nom ici)
Donc , la question principale is..what étapes dois - je considérer lors de l' écriture d' une extension pour assurer la qualité du code et faciliter son utilisation par un technicien ou un non-technicien et un technicien pour le modifier?

Voici ce que je fais habituellement:

1. Toujours développer avec error_reportingsur.
2. Toujours développer avec isDeveloperModeset to true. Ajoutez simplement SetEnv MAGE_IS_DEVELOPER_MODE 1à votre httpd.conffichier (ou fichier correspondant pour Nginx ou autre chose)
3. Si l'extension est liée à une fonctionnalité principale, ajoutez la dépendance dans le fichier de déclaration. <depends><Mage_Catalog /></depend>
4. Si le module est destiné à la communauté, utilisez-le communitycomme pool de codes pour donner aux développeurs la possibilité de remplacer certaines classes sans modifier directement le code.
5. Placez vos fichiers de conception frontaux app/design/frontend/base/default pour les rendre disponibles pour tous les thèmes.
6. Mettez vos fichiers de conception d'admin dans app/design/adminhtml/default/defaultet ne changez pas le thème d'admin. Je peux vouloir le changer dans un de mes modules.
7. Préfixez les noms de fichier de votre disposition et le nom du dossier de modèle avec le nom de la société pour faciliter leur isolation. easylife_articles.xmletapp/design/.../easylife_articles
8. Placez vos ressources statiques (JavaScript, CSS et images) dans un dossier similaire à celui des fichiers de modèle. easylife_articles/images/doh.png
9. Joignez un fichier texte simple avec la procédure de désinstallation de l'extension: Quels fichiers doivent être supprimés, quelles tables doivent être supprimées, quels paramètres de configuration doivent être supprimés de la core_config_datatable.
10. N'écrivez pas de requêtes directement dans des modèles, des blocs ou des aides, utilisez un modèle de ressource pour cela.
11. N'écrivez pas de requêtes utilisant directement les noms de table Select * from sales_flat_order where .... Utilisez a Zend_Selectet transformez les noms de table avec ->getTable('sales/order').
12. Utilisez l'URL de base pour inclure des jsfichiers dans le modèle. Mal <script type="text/javascript" src="../js/some.js"></script> . Droite <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
13. Ne réécrivez pas les classes sauf si cela est nécessaire. Utilisez des observateurs et s'il n'est pas possible d'utiliser des méthodes d'assistance recevant comme paramètre et instance d'une classe que vous souhaitez remplacer. Wrong : Ignore Mage_Catalog_Model_Productpour ajouter la méthode getProductArticles(). Droit . Dans votre aide ajouter getProductArticles(Mage_Catalog_Model_Product $product)
14. Si vous substituez des classes, mettez-en une liste dans un readme.txtfichier
15. Utilisez le chemin d'accès par défaut pour la section admin de votre module. URL d'administrateur incorrecte articles/adminhtml_articles/index . URL d'administrateur de droite admin/articles/index
16. Ajoutez des ACL pour vos sections d’administrateur. Je souhaite peut-être limiter l'accès à certains administrateurs.
17. N'ajoutez pas d'autre framework JavaScript (jQuery, MooTools, etc.) s'il n'est pas nécessaire. Ecrivez votre code dans le prototype.
18. Assurez-vous que le modèle HTML W3C est valide (il s’agit de développeurs OCD comme moi).
19. Ne mettez pas d'images dans le mediadossier. Utilisez skin. Le media dossier n'est généralement pas versionné, ce qui rend plus difficile le déplacement du site Web vers différents environnements.
20. Testez votre extension avec le catalogue à plat sur et en dehors. Afin de ne pas doubler le temps de développement, utilisez Chaos Monkey .
21. Testez votre extension avec cache onet cache off.
22. Évitez d’utiliser des lettres majuscules dans les noms de module et de classe. S'il n'est pas correctement testé, cela peut entraîner des problèmes sur différents systèmes d'exploitation. Ceci est plus une recommandation, pas un «must».
23. Répartissez les événements dans votre code pour permettre aux développeurs de modifier plus facilement les fonctionnalités.
24. Suivez les mêmes normes de codage que Magento et commentez votre code.
25. N'utilisez pas de balises courtes PHP ( <? $this->doSomething() ?>). Utilisez des balises complètes ( <?php $this->doSomething()?>). Aussi, n'utilisez pas encore de balises écho courtes. ( <?="D'oh";?>) Utiliser ( <?php echo "D'oh";?>)
26. Traduisez vos textes en utilisant $this->__et ajoutez le fichier de traduction des paramètres régionaux avec vos textes ( app/local/en_US/Easylife_Articles.csv) au moins pour la en_USlangue. Tous les sites Web ne sont pas construits en anglais et l'identification des textes à traduire prend beaucoup de temps.
27. Si vous vendez une extension, offrez au moins une assistance de base. Ou du moins, répondez aux e-mails de support que vous recevez.
28. N'appelez pas constamment vos serveurs via votre extension pour la validation de licence. Une fois, l'installation est plus que suffisante (je n'aime pas cette approche non plus, mais c'est mieux que de faire des appels tout le temps). (Inspiré par cette question )
29. Développez avec le journal activé et examinez de temps en temps le var/log/system.logfichier. Les erreurs répertoriées ici ne sont pas affichées même lorsque le mode développeur est activé. S'il y a au moins une erreur, vous vous retrouvez avec un fichier journal volumineux après quelques mois d'exécution de l'extension.
30. Si votre extension affecte le processus de commande ou les commandes d'une manière ou d'une autre, assurez-vous que cela fonctionne avec plusieurs envois, ou s'il ne fonctionne pas avec plusieurs envois, assurez-vous que cela ne l'affecte pas.
31. Ne remplacez pas la barre de notification de l'administrateur (ou l'URL du flux) par défaut. Si ce que vous proposez m'intéresse, je m'inscrire à votre newsletter. Laissez-moi voir ce que Magento a à dire. C'est plus important pour moi.
32. Si vous cryptez vos fichiers de code avec Ioncube (ou autre chose) ... eh bien ... je vous déteste et j'espère que votre entreprise fera faillite

C'est ce qui a jusqu'à présent. J'ajouterai plus dès que je penserai à autre chose.

Je suis un grand partisan de l’utilisation de modman, ce qui me permet de développer et de contrôler simplement le code source de mon extension, tout en laissant la structure de fichiers et la structure de dossiers inchangées. Cela facilite également les tests sur différentes installations.

Oh, et un conseil massif essayez toujours d’installer votre extension packagée localement sur une nouvelle installation de magento avant de la télécharger sur Magento Connect. J’ai manqué tant de fichiers dans le gestionnaire de paquets.

Andreas von Studnitz et Nikolai Krambrock ont ​​fait une bonne présentation de la qualité du code sur le Meet Magento DE 2014. Ils font la distinction entre la qualité du code général et la qualité du code spécifique à Magento. En bref, il y a les règles générales suivantes:

• L'utilisation d'éléments de structure - tout comme les classes et les méthodes - doit être organisée en classes de classe moyenne. Ces éléments de la structure n'ont de sens que lorsqu'ils sont utilisés pour la structuration. Par conséquent, ils doivent être de taille moyenne. Il est considéré d'utiliser 100-200 lignes de code pour les classes et 3-20 lignes de code pour les méthodes.
• En raison de l'utilisation de "if" ou "while", le code est en retrait. S'il y a plus de 3 empreintes, il est préférable de les réviser. Trop d'indentations témoignent de la complexité du code et doivent donc être évitées.
• Le code mort doit être évité et supprimé. Les analyses statiques aident à le trouver, le cas échéant.

Les règles spécifiques à Magento sont encore plus importantes:

• Les modules devraient fonctionner indépendamment. Ils ne devraient avoir qu'une faible dépendance à l'égard d'autres modules et aucune dépendance à l'égard des modèles. Une solution consiste à utiliser les mises à jour de présentation (base / par défaut) au lieu d'une adaptation aux fichiers de modèle et d'un module qui couvre des fonctions supplémentaires du modèle.
• Pour maintenir la capacité des mises à jour dans Magento, les piratages de base et les piratages de modules externes doivent être évités. Un meilleur moyen consiste à utiliser plutôt des réécrivains ou des observateurs.
• Pour les modifications, il est préférable d’utiliser des scripts d’installation plutôt que des modifications directes de la base de données ou de l’administrateur. Grâce à eux, les changements ne doivent être effectués qu’une fois.

Voici quelques détails supplémentaires et une vidéo de la présentation: http://www.code4business.de/code-quality-magento/

Si vous vendez votre extension ou si vous la partagez avec d'autres, songez à écrire un code lisible par l'homme.

1. ne pas rendre la méthode trop complexe
2. ajouter des blocs DOC à vos méthodes ^*
3. utiliser des noms de variables appropriés, comme $productIdsau lieu de$ids
4. idem pour les méthodes, public function myOnProductSaveMethod() {...}dit ... rien, mais tryDisableInternetOnProductSave()donnera un indice sur le besoin planifié
5. utiliser des indications de type là où cela a du sens someMethod(Varien_Data_Db_Collection $collection)
6. éviter les chiffres et les chaînes magiques ^**
7. si vous utilisez la $_eventPrefixpropriété set set (et $_eventObject) pour les rendre plus accessibles aux observateurs
8. si vous ajoutez des champs de configuration du système
   • définir les valeurs par défaut dans config.xml
   • ajouter des <validate>noeuds aux champs danssystem.xml
   • ajouter des ressources ACL à adminhtml.xml
9. N'ajoutez pas d'entrées de menu de premier niveau inutiles / publicitaires dans le backend de l'administrateur - ni dans les sections topbar ni dans les sections config.
10. ajouter des ressources ACL pour toutes les actions du contrôleur (aussi pour les actions massives!)
11. assurez-vous que vos requêtes fonctionnent avec les préfixes des tables de base de données
12. penser à la (non) compatibilité arrière (c'est vraiment basé sur l'opinion)
    • ne supporte pas les Mysql4cours
    • ne pas utiliser de méthodes obsolètes
13. assurez-vous que votre extension fonctionne comme prévu dans tous les cas - ajoutez UnitTests (PhpUnit par exemple)
14. en plus de David Manners ... ajouter un composer.jsonaussi pour faciliter le déploiement
15. puisque PHP5.6 est EOL, écrivez votre code pour PHP7. Utiliser declare(strict_types=1);et définir vos types d'entrée et de sortie
16. Magento2: vérifiez votre code avec des outils d'analyse de code statique comme phpstan . Support pour les méthodes magiques ici . (le dernier commit fonctionne avec 2.3, avant pour 2.1 / 2.2 - cela nécessite phpstan 0.8.5)

^{* Blocs DOC:}

Si vous vérifiez votre code Magento-1 avec PHP_CodeSniffer pour PSR2 standard ou PHPMD, vous voudrez peut-être ajouter ces lignes (là où cela a un sens) ...

• aux cours
  • @phpcs:disable PSR1.Classes.ClassDeclaration.MissingNamespace
  • @phpcs:disable PSR2.Classes.PropertyDeclaration.Underscore - propriétés héritées
  • @phpcs:disable Squiz.Classes.ValidClassName.NotCamelCaps
  • @SuppressWarnings(PHPMD.CamelCaseClassName)
  • @SuppressWarnings(PHPMD.CamelCasePropertyName) - propriétés héritées
• aux méthodes
  • @SuppressWarnings(PHPMD.CamelCaseMethodName) - méthodes héritées
  • @SuppressWarnings(PHPMD.StaticAccess)- si vous utilisez Mage::ou d'autres appels statiques

^{** Souvent utilisé:}

• ID magasin admin
  • 0 > Mage_Core_Model_App::ADMIN_STORE_ID
• produit status
  • 1 > Mage_Catalog_Model_Product_Status::STATUS_ENABLED
  • 2> Mage_Catalog_Model_Product_Status::STATUS_DISABLED (pas 0comme peut-être prévu)
• produit 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
• produit 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

Idem pour SQL ASCvs vs Zend_Db_Select::SQL_ASC (par exemple) .

Dire "Ce n'est pas nécessaire, cela ne changera jamais" ? Par exemple ID d' entité pour les catalog_productattributs a changé quelque part entre 1,5 et 1,9 Magento de 10à 4, donc cela pourrait briser votre extension:

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

Utiliser cette option à la place ajoute une requête, mais vous serez en sécurité ...

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

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

@marius, concernant les normes de codage (point 24 de votre liste).

J'aime utiliser PHP_CodeSniffer avec EQP et ECG CS pour appliquer automatiquement ces normes.

L' utilisation PHP_CodeSniffer vous n'avez pas à vous soucier d'oublier des choses comme remplaçant array()avec [], évitez d' utiliser is_null, les congés non variables locales ou même une méthode sans bloc PHPDoc.

PHP_CodeSniffer vous en parlera toujours.