Leçons apprises lors du développement de plugins WordPress

Résoudre un problème

Si votre plugin ne résout pas un problème, il ne sera pas téléchargé. C'est aussi simple que cela.

Prenez le plugin Advanced Cron Manager (plus de 8 000 installations actives). Il aide les utilisateurs de WordPress qui ont du mal à déboguer leur cron. Le plugin a été écrit sur un besoin – j'avais besoin de quelque chose pour m'aider. Je n'avais pas besoin de commercialiser celui-ci, car les gens en avaient déjà besoin. D'un autre côté, il y a le plugin Bug – fly sur l'écran (70+ installations actives). Il simule aléatoirement une mouche sur l'écran. Cela ne résout pas vraiment un problème, donc cela ne va pas avoir un énorme public. C'était un plugin amusant à développer, cependant.

Focus sur un problème. Quand les gens ne voient pas leur référencement performant, ils installent un plugin SEO. Lorsque les gens veulent accélérer leur site Web, ils installent un plugin de mise en cache. Quand les gens n'arrivent pas à trouver une solution à leur problème, ils trouvent un développeur qui leur écrit une solution.

Comme David Hehenberger l'atteste dans son article sur l'écriture d'un plugin réussi le besoin est une clé facteur dans la décision de l'utilisateur WordPress d'installer un plugin particulier.

Si vous avez l'occasion de résoudre le problème de quelqu'un, prenez une chance.

2. Soutenez votre produit

"3 Américains sur 5 essaieraient une nouvelle marque ou entreprise pour une meilleure expérience de service. 7 sur 10 ont dit qu'ils étaient prêts à dépenser plus avec des entreprises qui, selon eux, fournissent un excellent service. "

– Nykki Yeager

Ne négligez pas votre soutien. Ne le traitez pas comme un must, mais plutôt comme une opportunité.

Un support de bonne qualité est essentiel à la croissance de votre plugin. Même un plugin avec le meilleur code obtiendra quelques tickets de support. Plus vous utiliserez votre plugin, plus vous aurez de tickets. Une meilleure expérience utilisateur vous permettra d'obtenir moins de tickets, mais vous n'atteindrez jamais la boîte de réception 0.

Chaque fois que quelqu'un publie un message sur un forum de support, j'obtiens une notification par email immédiatement et je réponds dès que possible. Ça rapporte. La grande majorité de mes bonnes critiques ont été gagnés en raison du soutien. Ceci est un effet secondaire: Un bon support se traduit souvent par des critiques 5 étoiles.

Lorsque vous fournissez un excellent support, les gens commencent à vous faire confiance et votre produit. Et un plugin est un produit, même si c'est complètement gratuit et open-source.

Un bon support est plus complexe que d'écrire une réponse courte une fois par jour. Lorsque votre plugin gagne en popularité, vous recevrez plusieurs tickets par jour. C'est beaucoup plus facile à gérer si vous êtes proactif et répondez aux questions des clients avant même de le demander.

Voici une liste d'actions que vous pouvez effectuer:

• Créer une section FAQ dans votre référentiel. "Avant de poser" fil en haut de votre forum de support, en soulignant les conseils de dépannage et FAQ.
• Assurez-vous que votre plugin est simple à utiliser et que les utilisateurs savent ce qu'ils devraient faire après leur installation. UX est important.
• Analysez les questions de support et corrigez les points douloureux. Mettre en place un forum où les gens peuvent voter pour les fonctionnalités qu'ils veulent.
• Créer une vidéo montrant le fonctionnement du plugin, et l'ajouter à la page principale de votre plugin dans le dépôt WordPress.org

Peu importe quel logiciel vous utilisez pour soutenir votre produit. Le forum de support officiel de WordPress.org fonctionne aussi bien que le courrier électronique ou votre propre système de support. J'utilise le forum de WordPress.org pour les plugins gratuits et mon propre système pour les plugins premium.

3. Ne pas utiliser Composer

Composer est un logiciel de gestion de paquets. Un référentiel de packages est hébergé sur packagist.org et vous pouvez facilement les télécharger sur votre projet. C'est comme NPM ou Bower pour PHP. Gérer vos paquets tiers comme le fait Composer est une bonne pratique, mais ne l'utilisez pas dans votre projet WordPress.

Je sais, j'ai laissé tomber une bombe. Laissez-moi vous expliquer.

Composer est un excellent logiciel. Je l'utilise moi-même, mais pas dans des projets WordPress publics. Le problème réside dans les conflits. WordPress n'a pas de gestionnaire de paquets global, donc chaque plugin doit charger ses propres dépendances. Lorsque deux plugins chargent la même dépendance, cela provoque une erreur fatale.

Il n'y a pas vraiment de solution idéale à ce problème, mais Composer l'aggrave. Vous pouvez regrouper la dépendance dans votre source manuellement et toujours vérifier si vous êtes sûr de le charger.

Problème de compositeur avec les plugins WordPress n'est toujours pas résolu, et il n'y aura pas de solution viable à ce problème dans un avenir proche. Le problème a été soulevé il y a de nombreuses années, et, comme vous pouvez le lire dans l'article de WP Tavern de nombreux développeurs tentent de le résoudre, sans aucune chance.

Le mieux que vous pouvez faire est de vous assurer les conditions et l'environnement sont bons pour exécuter votre code.

4. Supporter raisonnablement de vieilles versions de PHP

Ne supporte pas de très vieilles versions de PHP, comme 5.2. Les problèmes de sécurité et de maintenance ne valent pas le coup, et vous ne gagnerez pas plus d'installations à partir de ces anciennes versions.

Aller avec PHP 5.6 comme une exigence minimale, même si le support officiel sera abandonné à la fin de 2018 . WordPress lui-même nécessite PHP 7.2.

Il y a un mouvement qui décourage la prise en charge des anciennes versions de PHP . L'équipe Yoast a publié la bibliothèque Whip que vous pouvez inclure dans votre plugin et qui affiche pour vos utilisateurs des informations importantes sur leur version de PHP et pourquoi ils devraient être mis à niveau.

Indiquez aux utilisateurs les versions que vous supportez , et assurez-vous que leur site ne se casse pas après l'installation de votre plugin sur une version trop basse.

5. Mettre l'accent sur le code de qualité

Écrire un bon code est difficile au début. Il faut du temps pour apprendre les principes "SOLID" et les modèles de conception et pour changer les vieilles habitudes de codage.

Il m'a fallu trois jours pour afficher une simple chaîne dans WordPress, quand j'ai décidé de réécrire l'un de mes plugins. . C'était frustrant de savoir que cela aurait dû prendre 30 minutes. Changer d'état d'esprit était douloureux mais ça en valait la peine.

Pourquoi était-ce si difficile? Parce que vous commencez à écrire du code qui semble d'abord être trop compliqué et pas très intuitif. Je me demandais: «Est-ce vraiment nécessaire?» Par exemple, vous devez séparer la logique en différentes classes et vous assurer que chacun est responsable d'une seule chose. Vous devez également séparer les classes pour la traduction, l'enregistrement du type de publication personnalisée, la gestion des ressources, les gestionnaires de formulaire, etc. Ensuite, vous composez les structures les plus grandes à partir des simples petits objets. C'est ce qu'on appelle l'injection de dépendance . C'est très différent d'avoir des classes "front end" et "admin", où vous bourrez tout votre code.

L'autre pratique contre-intuitive consistait à garder toutes les actions et tous les filtres en dehors de la méthode constructeur. De cette façon, vous n'invoquez aucune action lors de la création des objets, ce qui est très utile pour les tests unitaires. Vous avez également un meilleur contrôle sur les méthodes qui sont exécutées et quand. Je souhaite que je le savais avant que j'aie écrit un projet avec une boucle infinie causée par les actions dans les méthodes de constructeur. Ces types de bogues sont difficiles à tracer et difficiles à réparer. Le projet a dû être refactorisé

Ce qui précède ne sont que quelques exemples, mais vous devriez apprendre à connaître les principes SOLID . Ils sont valables pour n'importe quel système et n'importe quel langage de codage.

Lorsque vous suivez toutes les meilleures pratiques, vous atteignez le point où chaque nouvelle fonctionnalité s'intègre. Vous n'avez rien à modifier ni à faire d'exceptions à l'existant code. C'est incroyable. Au lieu de devenir plus complexe, votre code devient plus avancé, sans perte de flexibilité.

Aussi, formatez votre code correctement, et assurez-vous que chaque membre de votre équipe suit un standard. Les normes rendront votre code prévisible et plus facile à lire et à tester. WordPress a ses propres normes que vous pouvez implémenter dans vos projets.

6. Testez votre plugin à venir

J'ai appris cette leçon à la dure. Le manque de tests m'a conduit à sortir une nouvelle version d'un plugin avec une erreur fatale. Deux fois. Les deux fois, j'ai obtenu une note de 1 étoile, que je ne pouvais pas transformer en critique positive.

Vous pouvez tester manuellement ou automatiquement. Travis CI est un produit de test continu qui s'intègre à GitHub. J'ai construit une suite de tests vraiment simple pour mon plugin Notification qui vérifie juste si le plugin peut démarrer correctement sur toutes les versions de PHP. De cette façon, je peux être sûr que le plugin est sans erreur, et je n'ai pas à faire attention à le tester dans tous les environnements.

Chaque test automatisé prend une fraction de seconde. 100 tests automatisés prendront environ 10 minutes à compléter, alors que les tests manuels nécessitent environ 2 minutes pour chaque cas.

Plus vous investissez de temps pour tester votre plugin, plus il vous sauvera à long terme. [19659006PourcommenceraveclestestsautomatisésvouspouvezutiliserlacommandeWP-CLI\`wpéchafaudageplugin-test\`qui installe toute la configuration dont vous avez besoin. Documentez votre travail

C'est un cliché que les développeurs n'aiment pas écrire de la documentation. C'est la partie la plus ennuyeuse du processus de développement, mais un peu va un long chemin.

Écrire du code auto-documenté. Faites attention aux noms de variable, de fonction et de classe. Ne créez pas de structures compliquées, comme des cascades qui ne peuvent pas être lues facilement.

Une autre façon de documenter le code est d'utiliser le "bloc doc", qui est un commentaire pour chaque fichier, fonction et classe. Si vous écrivez comment la fonction fonctionne et ce qu'elle fait, elle sera tellement plus facile à comprendre lorsque vous aurez besoin de la déboguer dans six mois. WordPress Coding Standards couvre cette partie en vous forçant à écrire les blocs doc.

L'utilisation des deux techniques vous fera gagner du temps lors de l'écriture de la documentation, mais la documentation du code ne sera pas lue par tout le monde. utilisateur, vous devez écrire des articles de haute qualité, courts et faciles à lire expliquant comment le système fonctionne et comment l'utiliser. Les vidéos sont encore meilleures. Beaucoup de gens préfèrent regarder un court tutoriel que de lire un article. Ils ne vont pas regarder le code, alors leur faciliter la vie. Une bonne documentation réduit également les tickets de support

Conclusion

Ces sept règles m'ont aidé à développer des produits de bonne qualité, qui commencent à être une activité principale à BracketSpace . J'espère qu'ils vous aideront aussi dans votre voyage avec les plugins WordPress.

Faites-moi savoir dans les commentaires quelle est votre règle de développement en or ou si vous avez trouvé l'une de ces réponses particulièrement utile.

Source link