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

Chaque développeur de plugin WordPress est aux prises avec des problèmes difficiles et un code difficile à maintenir. Nous passons des nuits tardives à soutenir nos utilisateurs et nous nous arrachons les cheveux lorsqu'une mise à jour casse notre plugin. Laissez-moi vous montrer comment le rendre plus facile.

Dans cet article, je vais partager mes cinq années d'expérience dans le développement de plugins WordPress. Le premier plugin que j'ai écrit était un simple plugin marketing. Il affichait un bouton d'appel à l'action (CTA) avec la phrase de recherche de Google. Depuis lors, j'ai écrit 11 autres plugins gratuits, et je les maintiens presque tous. J'ai écrit environ 40 plugins pour mes clients, des plus petits aux plus maintenus depuis plus d'un an maintenant.

Un bon développement et un bon support conduisent à plus de téléchargements. Plus de téléchargements signifie plus d'argent et une meilleure réputation. Cet article vous montrera les leçons que j'ai apprises et les erreurs que j'ai commises, afin que vous puissiez améliorer le développement de votre plugin.

1. 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 ça.

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 à partir d'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. Cela a gratté leur démangeaison.

D'un autre côté, il y a le plugin Bug — fly on the screen (plus de 70 installations actives). Il simule au hasard une mouche sur l'écran. Cela ne résout pas vraiment un problème, donc ça n'aura pas un public énorme. C'était un plugin amusant à développer, cependant.

Concentrez-vous sur un problème. Lorsque les gens ne voient pas leur référencement bien fonctionner, ils installent un plugin SEO. Lorsque les gens veulent accélérer leur site Web, ils installent un plugin de mise en cache. Lorsque les gens ne trouvent pas de solution à leur problème, ils trouvent un développeur qui rédige une solution pour eux.

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

Si vous avez l'occasion de résoudre le problème de quelqu'un, tentez votre 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 déclaré 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 pour que votre plugin se développe. Même un plugin avec le meilleur code recevra des tickets de support. Plus il y a de personnes qui utilisent votre plugin, plus vous obtiendrez de tickets. Une meilleure expérience utilisateur vous rapportera moins de tickets, mais vous n'atteindrez jamais la boîte de réception 0.

Chaque fois que quelqu'un publie un message dans un forum d'assistance, je reçois immédiatement une notification par e-mail et je réponds dès que possible. Ça rapporte. La grande majorité de mes bonnes critiques ont été gagnées grâce au support. Ceci est un effet secondaire : un bon support se traduit souvent par des avis 5 étoiles.

Lorsque vous fournissez un excellent support, les gens commencent à vous faire confiance, à vous et à votre produit. Et un plugin est un produit, même s'il est entièrement gratuit et open-source.

Un bon soutien est plus complexe que d'écrire une réponse courte une fois par jour. Lorsque votre plugin gagne du terrain, vous obtenez 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 qu'ils ne les posent.

Voici une liste de certaines actions que vous pouvez effectuer :

• Créez une section FAQ dans votre référentiel.
• Épinglez le fil "Avant de demander" en haut de votre forum d'assistance, en mettant en évidence les conseils de dépannage et la FAQ.
• Assurez-vous que votre plugin est simple à utiliser et que les utilisateurs savent ce qu'ils doivent faire après l'avoir installé. L'expérience utilisateur est importante.
• Analysez les questions de support et corrigez les points faibles. Créez un tableau où les gens peuvent voter pour les fonctionnalités qu'ils souhaitent.
• Créez une vidéo montrant le fonctionnement du plugin et ajoutez-la à la page principale de votre plugin dans le référentiel WordPress.org.

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

3. N'utilisez pas le compositeur

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

Je sais, j'ai lâché une bombe. Laisse-moi 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 manuellement la dépendance dans votre source et toujours vérifier si vous pouvez la charger en toute sécurité.

Le problème de Composer avec les plugins WordPress n'est toujours pas résolu, et il n'y aura pas de solution viable à ce problème dans un proche avenir. 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 puissiez faire est de vous assurer que les conditions et l'environnement sont bons pour exécuter votre code.

4. Supporte raisonnablement les anciennes versions de PHP

Ne supporte pas les très anciennes versions de PHP, comme la 5.2. Les problèmes de sécurité et de maintenance n'en valent pas la peine, et vous n'allez pas gagner plus d'installations à partir de ces anciennes versions.

Optez pour PHP 5.6 comme exigence minimale, même si le support officiel sera abandonné d'ici la fin de 2018. WordPress lui-même nécessite PHP 7.2.

Il existe 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 à vos utilisateurs des informations importantes sur leur version PHP et pourquoi ils doivent mettre à jour.

Dites à vos utilisateurs quelles versions vous prenez en charge et assurez-vous que leur site Web ne tombe pas en panne après l'installation de votre plugin sur une version trop basse.

5. Concentrez-vous sur le code de qualité

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

Une fois, il m'a fallu trois jours pour afficher une simple chaîne dans WordPress, lorsque j'ai décidé de réécrire l'un de mes plugins en utilisant de meilleures pratiques de codage. C'était frustrant de savoir que cela aurait dû prendre 30 minutes. Changer mon état d'esprit était douloureux mais ça valait le coup.

Pourquoi était-ce si dur ? Parce que vous commencez à écrire du code qui semble au premier abord exagéré et peu intuitif. Je n'arrêtais pas de me demander: "Est-ce vraiment nécessaire?" Par exemple, vous devez séparer la logique en différentes classes et vous assurer que chacune est responsable d'une seule chose. Vous devez également séparer les classes pour la traduction, l'enregistrement du type de publication personnalisé, la gestion des actifs, les gestionnaires de formulaires, etc. Ensuite, vous composez les plus grandes structures à partir de 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 entasser tout votre code.

L'autre pratique contre-intuitive était de garder toutes les actions et tous les filtres en dehors de la méthode du 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 exécutées et à quel moment. J'aimerais le savoir avant d'écrire un projet avec une boucle infinie causée par les actions dans les méthodes du constructeur. Ces types de bugs sont difficiles à tracer et difficiles à corriger. Le projet a dû être repensé.

Ce qui précède ne sont que quelques exemples, mais vous devriez apprendre à connaître les principes SOLID. Celles-ci sont valables pour tout système et tout langage de codage.

Lorsque vous suivez toutes les meilleures pratiques, vous atteignez le point où chaque nouvelle fonctionnalité s'intègre parfaitement. Vous n'avez pas besoin de modifier quoi que ce soit ou de faire des exceptions au code existant. C'est incroyable. Au lieu de devenir plus complexe, votre code devient simplement plus avancé, sans perdre en flexibilité.

Formatez également votre code correctement et assurez-vous que chaque membre de votre équipe respecte une norme. 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 à l'avance

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

Vous pouvez tester manuellement ou automatiquement. Travis CI est un produit de test continu qui s'intègre à GitHub. J'ai créé une suite de tests très simple pour mon plugin de notification qui vérifie simplement si le plugin peut démarrer correctement sur chaque version de PHP. De cette façon, je peux être sûr que le plug-in est sans erreur et je n'ai pas à faire très attention à le tester dans chaque environnement.

Chaque test automatisé prend une fraction de seconde. 100 tests automatisés prendront environ 10 minutes, tandis que les tests manuels prendront environ 2 minutes pour chaque cas.

Plus vous investissez de temps à tester votre plugin à l'avance, plus il vous fera économiser à long terme.

Pour commencer avec les tests automatisés, vous pouvez utiliser la commande WP-CLI \\`wp scaffold plugin-test\\`, qui installe toute la configuration dont vous avez besoin.

7. 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 suffit.

Écrire du code auto-documenté. Faites attention aux noms de variables, de fonctions et de classes. Ne faites pas de structures compliquées, comme des cascades qui ne peuvent pas être lues facilement.

Une autre façon de documenter le code consiste à 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, il sera tellement plus facile de comprendre quand vous devrez 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.

Pour l'utilisateur final, vous devez rédiger des articles de haute qualité, courts et faciles à lire expliquant le fonctionnement du système et comment l'utiliser. Les vidéos sont encore meilleures ; beaucoup de gens préfèrent regarder un court tutoriel plutôt que de lire un article. Ils ne vont pas regarder le code, alors facilitez-leur la vie. Une bonne documentation réduit également les tickets d'assistance.

Conclusion

Ces sept règles m'ont aidé à développer des produits de bonne qualité, qui commencent à être un cœur de métier chez BracketSpace. J'espère qu'ils vous aideront également dans votre voyage avec les plugins WordPress.

Faites-moi savoir dans les commentaires quelle est votre règle d'or de développement ou si vous avez trouvé l'un des éléments ci-dessus particulièrement utile.