Un récit de l'utilisation de Composer dans un plugin WordPress

Cette pièce a été contribuée par l'auteur invité Peter Suhm. Peter est un développeur web du Pays des Danois. Il est le créateur de WP Pusher et un grand accro aux voyages, emportant son travail avec lui au fur et à mesure.

L'autre jour, j'ai publié un avertissement concernant l'utilisation de Composer dans les plugins WordPress sur le blog WP Pusher. Ce post a reçu beaucoup d'attention et je ressens le besoin de clarifier quelques points qui n'étaient pas tous clairs pour tout le monde. L'article était également un peu lourd sur les aspects techniques, donc dans cet article, je vais essayer de clarifier mon point principal en utilisant un récit simple pour l'illustrer.

Un narrateur

Imaginons un instant que vous et moi soyons tous les deux auteurs de plugins. Nous avons tous les deux une idée géniale pour un plugin que nous souhaitons distribuer via WordPress.org. Nous voulons inclure quelques fonctionnalités premium dans nos plugins que les utilisateurs de la version gratuite peuvent débloquer en saisissant une clé de licence.

Nous avons besoin d'un code capable de gérer ce processus. Nous réalisons tous les deux que ce problème a probablement déjà été résolu par quelqu'un d'autre. Aucun d'entre nous n'aime réinventer la roue, alors nous nous dirigeons vers Packagist et tapons "gestionnaire de licences". Il semble que notre hypothèse était justifiée. Yoast a déjà un paquet qui peut gérer cela. Nous décidons tous les deux de faire un composer require yoast/license-manager . Peasy facile. Nous pouvons maintenant passer à quelque chose qui compte vraiment - les fonctionnalités de base de nos plugins respectifs.

Avance rapide, prêt à publier votre plugin, vous réalisez quelque chose : votre utilisateur n'a pas nécessairement Composer à portée de main lors de l'installation de votre plugin à partir de WordPress.org, alors comment vont-ils obtenir le code pour le gestionnaire de licences ? Cette situation est un peu ennuyeuse, car la seule solution que vous voyez vraiment est de valider tout le répertoire des vendor généré par Composer dans votre plugin et de le pousser vers WordPress.org. Vous savez que ce n'est pas ainsi que Composer est censé fonctionner, mais peu importe. Vous n'avez pas vraiment d'autres options.

Pendant ce temps, je suis arrivé à la même conclusion avec mon plugin. Incluez simplement le code du gestionnaire de licence et finissez-en.

Avance rapide une fois de plus, nos deux plugins vivent maintenant dans le référentiel WordPress.org et de temps en temps, quelqu'un décide de passer à nos versions premium. Tout semble aller bien et nous sommes tous les deux reconnaissants de pouvoir simplement utiliser le code que Yoast a généreusement mis en open source et de ne pas avoir à réinventer la roue.

Un jour, vous recevez un e-mail étrange. Un client éprouve un comportement vraiment étrange lorsqu'il essaie de déverrouiller vos fonctionnalités premium. Cela n'a aucun sens pour vous, car personne d'autre ne l'a jamais signalé. Après des heures de débogage, vous demandez enfin à votre client de désactiver tout le reste, sauf votre plugin, et là : ça marche ! Hmm. Votre plugin semble en quelque sorte être incompatible avec un autre plugin. Mon plugin.

Vous vous en rendez compte après des heures passées à parcourir le code source de tous les autres plugins installés par le client. Lorsque vous vous rendez compte que nous utilisons tous les deux le gestionnaire de licence, une cloche sonne. Cela pourrait-il vraiment être ça ? Si c'est le cas, comment se fait-il qu'il n'y ait pas d' fatal errors: cannot redeclare class à cause de PHP ?

Une semaine plus tôt, j'avais remplacé la version requise du gestionnaire de licence de mon plugin par la dernière version, qui incluait des changements de rupture (fictifs). Après encore plus de débogage et var_dump() ', vous vous rendez compte que ma version du gestionnaire de licence est également la version chargée par PHP dans votre plugin. Vous trouvez cela vraiment étrange car vous aviez spécifiquement besoin d'une autre version du gestionnaire de licence avec Composer. Vous ne savez pas vraiment quoi faire à ce sujet.

Parce qu'il n'y a vraiment pas grand chose à faire.

Que s'est-il passé ici?

Maintenant que nous avons tous vu le problème, prenons un moment pour passer en revue ce qui s'est réellement passé dans le récit. Tout d'abord, pourquoi PHP n'a-t-il pas provoqué d'erreur fatale alors que deux classes avaient manifestement le même nom que nous incluions tous les deux le gestionnaire de licences ?

La raison en est que nous avons utilisé un chargeur automatique généré par Composer. Cet autochargeur analyse la structure de répertoire de nos dépendances et ajoute chaque classe à l'autochargeur. Si une classe a déjà été ajoutée, Composer l'ignorera. Silencieusement. J'ai écrit un petit exemple de code si vous voulez le voir par vous-même. C'est sur GitHub.

Pourquoi ma version du gestionnaire de licence était-elle incluse avant la vôtre ?

Cela s'est produit parce que mon plugin avait un nom qui l'a fait charger avant le vôtre. Peut-être qu'à l'avenir, nous nommerons tous nos plugins "Aaaaaa My Plugin" afin d'être chargés en premier !

Donc, pour résumer, le principal problème ici est que nous ne saurons pas quelle version de nos dépendances nous est disponible à quel moment. Cela dépend simplement de facteurs que nous ne pouvons pas entièrement contrôler en tant que développeurs de plugins.

Est-ce un problème spécifique à Composer ?

Non. Ce n'est vraiment pas le cas. WordPress n'a aucun moyen de gérer le code tiers dans les plugins ou les thèmes. C'est là que réside le problème. La raison pour laquelle je parle de Composer est qu'il gagne beaucoup de terrain ces jours-ci. Si les développeurs WordPress veulent utiliser Composer dans les plugins publiés via WordPress.org, cela doit être résolu d'une manière ou d'une autre. Sinon, nous verrons un véritable chaos lorsque tous les plugins commenceront à être incompatibles les uns avec les autres car ils utilisent des versions différentes. Bienvenue dans l'enfer du débogage.

Que pouvons-nous faire à ce sujet ?

Quelqu'un qui s'est vraiment inquiété de cela et qui a travaillé dur pour trouver une solution potentielle est Coen Jacobs. J'ai décidé de contacter Coen et de lui demander s'il pense que nous pouvons faire quelque chose à ce sujet.

De nombreux développeurs incluent déjà du code tiers dans leurs plugins. Est-ce vraiment un problème ?

Oui, c'est déjà un problème dans l'écosystème des plugins. Cela deviendra encore pire lorsque plus de gens comprendront que c'est une bonne idée de mettre les fonctionnalités communes dans des packages séparés. Ces packages peuvent ensuite être regroupés avec plusieurs plugins et le problème apparaîtra de plus en plus. J'ai parlé à quelques développeurs qui ont déjà traversé l'enfer du débogage pour essayer de découvrir la cause de ce problème.

À l'avenir, suggéreriez-vous aux développeurs d'arrêter d'inclure du code tiers dans leurs plugins ?

Je suis un peu partagé sur ce sujet. Cela n'a aucun sens du point de vue des développeurs de dire aux gens d'arrêter de regrouper des packages partagés dans leurs plugins. D'un autre côté, tout le monde veut la meilleure expérience utilisateur possible pour ses utilisateurs. C'est une décision difficile à prendre à coup sûr.

À ce stade, je veux faire avancer le développement lié à WordPress. Je veux partager des bibliothèques et utiliser des bibliothèques partagées par d'autres. Personne ne devrait réinventer la roue encore et encore. Je prendrais donc le risque de rencontrer des problèmes comme celui-ci, en résolvant les problèmes au fur et à mesure qu'ils se présentent.

Cela signifie également que je ferai de mon mieux pour trouver une solution à long terme à ce problème. Plus de gens commenceront à utiliser Composer, plus de gens regrouperont des bibliothèques avec leurs plugins. Ce problème apparaîtra plus souvent, il est donc temps de le résoudre.

Que peuvent faire les développeurs de plugins pour éviter ce problème ?

Il existe une solution de contournement que j'ai déjà vue utiliser par certaines personnes. Cela revient essentiellement à déplacer votre dépendance vers l'espace de noms de votre plugin. Danny van Kooten l'a fait pour l'un de ses plugins. Ce n'est pas idéal cependant. Chaque fois qu'il met à jour ses dépendances, il doit parcourir tous les fichiers et modifier à nouveau les espaces de noms. Maintenant, ce n'est pas une si grande tâche pour une bibliothèque relativement petite comme Pimple, mais une entreprise énorme pour les plus grandes bibliothèques.

Cependant, cela ne peut être fait qu'avec des espaces de noms, vous devrez donc faire en sorte que votre plugin nécessite également PHP 5.3+. Je ne vais pas mentir, je pense que chaque plugin devrait commencer à le faire tôt ou tard, mais c'est certainement quelque chose que vous devez prendre en compte lorsque vous décidez de le faire.

Quelle serait la solution idéale, si elle existe ?

La situation idéale serait d'utiliser une sorte de gestionnaire de dépendances. Il y a bien sûr Composer, le gestionnaire de dépendances le plus utilisé. Composer est très difficile, voire impossible, à utiliser pour la grande majorité des utilisateurs de WordPress. C'est un outil de développeur après tout.

WordPress devrait faciliter cela pour ses utilisateurs finaux, tout en permettant aux développeurs d'utiliser à peu près n'importe quel package de leur choix. Sur cette pensée, j'ai commencé à mettre en place le plugin WordPress Composer Installer, qui fait tout le travail difficile de Composer pendant que les gens installent des plugins comme ils l'ont toujours fait. Dès que j'aurai pu terminer cela, je l'intégrerai correctement dans l'ensemble du flux d'installation du plugin.

Maintenant, peut-être qu'un jour, cela pourra être intégré au cœur de WordPress. Le chemin est encore long, mais la preuve de concept fonctionne déjà.

Conclusion

Si vous avez lu jusqu'ici, tout d'abord : Merci. Deuxièmement, j'espère que vous voyez maintenant comment c'est quelque chose qui finira par devenir un problème. Notre situation actuelle est très frustrante, car nous n'avons tout simplement pas les outils dont nous avons besoin. Néanmoins, je pense qu'il est important que nous continuions à en parler et que nous nous assurions tous, en tant que développeurs WordPress, de comprendre les problèmes potentiels causés par des dépendances tierces conflictuelles dans notre code.

Enfin, je tiens à mentionner une fois de plus que ce n'est pas un problème de compositeur. C'est un problème WordPress.