Tandis que Magento fait beaucoup de choses «prêtes à l'emploi», nous avons découvert qu'il existait inévitablement des fonctionnalités et des installations nécessaires pour les magasins clients nécessitant une extension tierce.
Toutefois, étant donné la nature du support, il peut être risqué d’introduire un code "étranger" dans un système aussi complexe traitant de transactions commerciales.
Que recherchez-vous lorsque vous évaluez des extensions Magento? Quels sont les "drapeaux rouges" que vous avez rencontrés (performances, risques de sécurité, mauvaises pratiques architecturales)?
performance
extensions
Junap
la source
la source
Réponses:
Voici quelques réflexions sur l’évaluation des modules tiers:
Bases:
Prise en charge de la version actuelle de Magento - Supporte-t-il la dernière version de Magento (y compris la version actuelle pour laquelle nous la développons)?
Si un module ne prend pas en charge la dernière version de Magento, il sera probablement difficile de le faire fonctionner sans consacrer un temps précieux au développement.
Support - Les développeurs qui ont créé le module prennent-ils en charge le produit?
L'un des signes d'un module sain est que les développeurs le soutiennent activement. S'ils ne supportent pas, c'est un drapeau rouge, pourquoi ne prendront-ils pas en charge le produit s'il est bon?
De plus, lorsqu'un module est pris en charge, nous pouvons généralement obtenir des informations importantes des développeurs avec un simple courrier électronique (par exemple, ce module utilise-t-il jQuery ou Prototype).
Avis - Que disent les autres utilisateurs? Comment était leur expérience?
En lisant les commentaires, nous pouvons avoir une meilleure idée de la situation dans l’ensemble, y at-il un problème d’installation? Les développeurs répondent-ils de manière rapide et utile? Cela fonctionne-t-il comme annoncé?
Remboursement - Est-ce qu'ils vont vous rendre votre argent si cela ne fonctionne pas comme prévu?
Plusieurs fois, nous voulons essayer le module afin de pouvoir le tester, si cela fonctionne et répond à nos spécifications, super! Mais dans le cas contraire, nous souhaitons pouvoir le retourner et obtenir un remboursement.
Intermédiaire:
Remplacement de classe - Le module remplace-t-il des classes principales?
En règle générale, un bon module ne devrait pas remplacer les classes de base, mais plutôt utiliser Observers.
Une des raisons est que cela peut rendre difficile la mise à niveau de Magento. En outre, d'autres modules peuvent dépendre d'une sortie d'une fonction donnée et ce module en fournit une autre.
Parfois, cela n’est pas possible. Si tel est le cas, il doit exister une très bonne raison pour laquelle elle remplace une classe principale.
Mises à jour de la mise en page - Le module modifie-t-il certains de mes paramètres de mise en page?
Certains modules modifient les paramètres de présentation de votre site (par exemple: page de produit), assurez-vous que cela ne rompt pas votre présentation actuelle et, le cas échéant, ce qu'il faudrait faire (lisez: combien de temps cela nous prendra-t-il) pour y remédier .
Modifications de modèle - Le module inclut-il des modèles qui modifient ma conception actuelle?
Ce module présentera-t-il de nouveaux modèles? Si oui, vont-ils briser ma conception? Combien de temps faudra-t-il pour que la conception soit comme nous le souhaitons?
Dépendances - Le module dépend-il d'un autre module?
Si le module dépend d’autres, nous devons nous assurer qu’ils sont là et installés. De plus, nous devons nous demander si nous allons vouloir désactiver le module dont il dépend dans le futur.
Avancée:
Scripts de mise à niveau SQL - Le module met-il à jour la base de données?
Une fois qu'un module met à jour la base de données, nous devons nous assurer de certaines choses.
Met-il à jour une table principale? Si c'est le cas, nos bases de données sont propres et prêtes à être mises à niveau.
Stocke-t-il les informations de manière judicieuse? Si nous voulons extraire nous-mêmes les données brutes de la base de données, serions-nous en mesure de les comprendre?
Événements - Le module observe-t-il ou envoie-t-il des événements?
Si un module distribue ou observe des événements, nous voulons savoir:
Quels événements observe-t-il / envoie-t-il? Cela affectera-t-il un autre module fonctionnant dans le système? Par exemple, si l'un de nos modules change le nom de nos produits en charge en majuscule et que ce module ajoute le mot «gratuit» au nom du produit en charge, comment cela fonctionnera-t-il? Le mot «gratuit» viendra-t-il aussi en majuscule?
Examen du code - Le module utilise-t-il des techniques de codage acceptables?
Cela a plus à voir avec les techniques de codage PHP que Magento.
Le code utilise-t-il des blocs Try / Catch?
Le code échappe-t-il à l'utilisateur?
Les détails de cela dépendent vraiment de notre niveau de compétence / exigences.
Problèmes potentiels - Quels problèmes potentiels peuvent survenir suite à l'installation de ce module?
Essayez d’imaginer les cinq principaux problèmes qui pourraient survenir si nous installons ce module, aussi surprenant soit-il, cela donne vraiment un aperçu du projet dans son ensemble.
Résultat final:
Toutes ces choses sont bien d'avoir dans un monde idéal, dans des scénarios du monde réel, nous devons faire ce qu'on appelle "compromis" :)
De plus, ces consignes ont pour but de nous aider et non de nous gêner. Par conséquent, si nous installons un seul module, disons un module de partage sur les réseaux sociaux, il s’agit d’un client qui a besoin d’une configuration simple du site. est inutile de faire une tonne de recherches.
En d’autres termes: c’est une question d’efficacité avec notre temps. Si l’utilisation de cette ligne directrice (article dans la) me permet de gagner du temps à long terme, utilisez-la, sinon jetez-la et gardez votre santé mentale.
la source
Certains drapeaux rouges "mauvaise pratique" spécifiques à Magento sont:
app/code/local/Mageapp/designqui existent déjà dans le noyau)catalog/product. En général, je regarde attentivement chaque réécriture, pour voir si cela aurait pu être évitéMage::getModeldans le répertoire des modèles est généralement un mauvais signe)Quelques drapeaux rouges liés à PHP (cette liste est très sélective et incomplète):
E_STRICT)@opérateurQuelques drapeaux rouges liés aux performances:
Surveillez également les odeurs de code générales , ce ne sont pas des signaux d'alarme, mais elles permettent d'estimer la qualité globale.
la source
Étape n ° 1 - Votre client peut-il se permettre de prendre en charge cette extension si le développeur devient AWOL?
Si non, vous ne pouvez pas utiliser l'extension.
Si oui, passez à l'évaluation de l'extension.
la source
Les spécialistes d’Inchoo ont publié un article sur l’analyse du code de module tiers. L'article mentionne les réécritures de classes, les tâches cron, les mises à jour de présentation et les observateurs d'événements.
J'ai constaté que le code d'observateur d'événement avait le potentiel de succès maximal. Recherchez le code tiers, gourmand en ressources, qui s'exécute pour les événements fréquemment distribués. Des événements tels que controller_action_predispatch ou des chargements de collection.
J'utilise ce module utilitaire de Prattski pour obtenir un bon aperçu des réécritures et des observateurs.
la source
*_afterévénements plutôt que des*_beforeévénements, si possible. Sur le plan des performances, il n’ya aucune déclaration sur les observateurs.controller_action_predispatchest envoyé une fois par demande, alors ce n'est peut-être pas le meilleur exemple. Mais bien que vous ne mentionniez qu’un potentiel élevé de problèmes de performances et que certains événements soient envoyés plus de fois par requête, je ne suis pas d’accord: les observateurs ne sont pas plus ou moins sujets aux problèmes de performances que n’importe quel autre code. Si vous faites des choses qui ont vraiment un impact sur les performances, comme charger tous les produits, cela pose un problème, peu importe où il se produit.Avoir des modèles et des ressources de skin situés dans default / default (ou pro ou entreprise) au lieu de base / default est assez ennuyant.
Il faut faire attention au code masqué - recherchez les appels à eval (), base64_decode (), etc. Ceci est souvent utilisé pour la validation de licence, mais peut être malveillant ou effrayant - j'ai vu au moins un composant qui a évalué le code arbitraire à partir d'un flux RSS.
Recherchez les appels dl () - au moins un composant de passerelle de paiement que j'ai vu nécessite l'installation d'une extension PHP pour établir ses connexions!
la source
Vous avez raison.
Il n’ya malheureusement pas de magie: vous devez les tester, vérifier le code pour voir s’il est bien développé, avoir un bon support pour les modules commerciaux grâce à leur forum ou leur rapidité à répondre à vos questions ...
Il y a quelques critiques sur Magento Connect et la popularité d'une extension peut aider à savoir si elle est valable ou non, mais honnêtement, vous pouvez trouver des modules très populaires avec beaucoup de bugs. J'ai eu un bon exemple la semaine dernière avec un module MailChimp, en grande partie bien fait, mais je devais corriger quelques bugs et les fournir au développeur. Il y a toujours des risques, vous devez tester.
WebShopApp a eu l’idée d’aller dans cette direction, c’est-à-dire d’apporter une plate-forme pour obtenir de bonnes informations sur les modules. L'idée était de pousser Magento dans cette direction. La qualité du module est donc une question réelle.
la source
Mon conseil: portez une attention particulière aux modules dotés de scripts d'installation / de mise à niveau qui modifient les valeurs des tables principales car il n'est pas toujours facile de revenir en arrière de ce type de modification.
la source
Le test n ° 1 que je peux trouver est de trouver un exploit de type zéro jour dans leur code (ce qui n’est généralement pas très difficile avec les extensions Magento), de ne signaler que les dommages résultant d’un exploit simulé à leur équipe de sécurité (sans indiquer une partie du code est vulnérable) et lancez le chronomètre - car c’est exactement ce qui se passera lorsque votre site sera piraté. Lorsque leur équipe de support technique demande un accès FTP et mysql global, refusez poliment de déclarer qu'il enfreint la norme PCI-DSS et proposez-leur de laisser un accès en lecture seule à votre référentiel de code source.
Le test n ° 2 que j'effectue consiste à appeler le vendeur et à le prendre au dépourvu. Demandez-leur quel type de test comportemental / unitaire ils font, quel système de contrôle de source ils utilisent, quelles versions de PHP ils testent, quelles versions de Magento sont testées, sur quels serveurs Web sont testés, qu'ils utilisent ou non un navigateur -stack pour tester les composants front-end, etc ... Si le fournisseur ne sait pas de quoi vous parlez, se tait ou veut "demander à un expert de vous renvoyer un e-mail", courez à fond, car ils utilisent probablement une numérotation Fichiers zip pour "contrôle de version" et ne corrige que les bogues 3 mois après que leurs clients les ont signalés.
En parlant de la norme PCI-DSS, toutes les modifications du système doivent également avoir une stratégie de réversion. Avec les modules qui ajoutent des colonnes non nullables aux tables principales, cela devient presque impossible tout en maintenant une stratégie de réversion qui passerait un audit. Exécutez-vous comme un diable à partir de n'importe quel module qui causera des problèmes (lisez: Erreurs SQL) lorsqu'il est désactivé.
Ceci, en plus des autres réponses. OMI, il devrait y avoir un mur de honte pour certaines des merdes dangereuses qui ont été engendrées sur cette plate-forme.
la source