Matt Mullenweg, développeur de WordPress et PDG d’Automatic, a proposé de ne plus ajouter de nouvelles fonctionnalités à WordPress, en passant plutôt à une politique de plugin-first.
Cette nouvelle approche de l’avenir de WordPress a déjà abouti à l’abandon complet d’une nouvelle fonctionnalité destinée à la prochaine version de WordPress.
On dit que les plugins canoniques offrent un moyen de continuer à améliorer WordPress selon un calendrier plus rapide.
Mais certains contributeurs principaux de WordPress ont exprimé l’opinion que l’expérience utilisateur de l’éditeur pourrait en souffrir.
Sommaire
Plugins canoniques
Abordés pour la première fois en 2009, les plugins canoniques sont un moyen de développer de nouvelles fonctionnalités sous la forme de plugins.
Le but de cette approche est de garder le noyau WordPress rapide et léger tout en encourageant le développement de fonctionnalités expérimentales sous la forme de plugins.
La proposition originale de 2009 l’a décrit comme ça:
« Les plugins canoniques seraient des plugins développés par la communauté (plusieurs développeurs, pas une seule personne) et répondraient aux demandes de fonctionnalités les plus populaires avec une exécution exceptionnelle.
… Il y aurait une relation très forte entre le noyau et ces plugins qui garantissait que a) le code du plugin serait sécurisé et le meilleur exemple possible de normes de codage, et b) que les nouvelles versions de WordPress seraient testées par rapport à ces plugins avant la sortie pour assurer la compatibilité.
Cette approche des fonctionnalités et des options est également appelée Plugin First, pour souligner la façon dont les fonctionnalités apparaîtront d’abord sous la forme de plugins.
Ces plugins sont appelés canoniques car ils sont développés par l’équipe de développement principale de WordPress par opposition aux plugins non canoniques créés par des tiers qui pourraient limiter les fonctionnalités afin d’encourager l’achat d’une version pro.
L’intégration de plugins canoniques dans le noyau WordPress lui-même serait envisagée une fois que la technologie de plugin s’est avérée populaire et essentielle pour la majorité des utilisateurs.
L’avantage de cette nouvelle approche de WordPress serait d’éviter d’ajouter de nouvelles fonctionnalités qui pourraient ne pas être nécessaires à la majorité des utilisateurs.
Plugin-first pourrait être considéré comme conforme à la philosophie de WordPress appelée Des décisions, pas des optionsqui vise à éviter de surcharger les utilisateurs avec des couches d’options techniques.
En déchargeant différentes fonctionnalités et fonctionnalités vers des plugins, un utilisateur n’aura pas à parcourir l’activation ou la désactivation des fonctionnalités dont il a besoin, dont il n’a pas besoin ou qu’il ne comprend pas.
La philosophie de conception de WordPress stipule :
« Il est de notre devoir en tant que développeurs de prendre des décisions de conception intelligentes et d’éviter de faire peser le poids des choix techniques sur nos utilisateurs finaux. »
Les plugins canoniques du futur ?
Matt Mullenweg a publié un article intitulé, Plugins canoniques revisitésdans lequel il a expliqué que c’est ainsi que WordPress devrait être développé à l’avenir.
Il a écrit:
« Nous atteignons un point où le noyau doit être plus éditorial et dire » non « aux fonctionnalités qui arrivent aussi ponctuellement qu’elles le font parfois, et j’espère que davantage d’équipes Make utiliseront cela comme une opportunité d’influencer l’avenir de WordPress à travers une approche axée sur le plugin qui leur donne le luxe de cycles de développement et de publication plus rapides (au lieu de trois fois par an), moins de frais généraux de révision et un chemin à suivre si le plugin devient un succès fulgurant.
La première victime de cette nouvelle approche est la annulation de l’intégration de la conversion d’image WebP dans la prochaine version de WordPress, WordPress 6.1, actuellement prévue pour novembre 2022.
Plugin-First est controversé
Le passage à un processus de développement basé sur le plugin a fait l’objet d’un débat dans la section des commentaires.
Certains développeurs, tels que le contributeur principal Jon Brownont exprimé des réserves quant à la proposition de passer au développement avec des plugins canoniques.
Ils commenté:
« Le problème reste qu’il y a trop de plugins compliqués qui remplacent ce qui serait une simple fonctionnalité optionnelle.
Les plugins ne sont _pas_ une option conviviale pour les paramètres de base. Les premiers utilisateurs doivent découvrir qu’il existe un plugin, puis ils ont négocié un autre écran de paramètres et les mises à jour et la maintenance de ce plugin.
Le commentateur a utilisé l’exemple d’une fonctionnalité de commentaire qui est actuellement servie par plusieurs plugins gonflés comme une expérience utilisateur moins qu’idéale.
Ils ont noté qu’avoir un plugin canonique pour résoudre un problème est préférable à l’état actuel où les options souhaitables ne peuvent être trouvées que sur des plugins tiers gonflés.
Mais ils ont également déclaré qu’avoir une option de paramètres dans le noyau, sans avoir besoin d’un plugin, pourrait offrir une meilleure expérience utilisateur.
Ils ont poursuivi :
« Maintenant, je pense que les plugins canoniques sont une meilleure situation que 6+ plugins gonflés comme ceux qui existent ici, mais il en serait de même pour une seule case à cocher ajoutée à la page des paramètres dans le noyau pour ce faire. Ce qui améliorerait encore l’UX et les problèmes de découverte inhérents aux plugins.
En fin de compte, le commentateur a exprimé l’idée que le concept de plugins canoniques semblait être un moyen de mettre fin aux discussions sur les fonctionnalités à prendre en compte, de sorte que la conversation n’ait jamais lieu.
Les « plugins canoniques » semblent être un outil armé pour faire dérailler les discussions de la même manière que les « décisions et non les options » le sont depuis des années. »
Cette dernière déclaration fait référence aux frustrations ressenties par certains contributeurs principaux face à l’incapacité d’ajouter des options pour les fonctionnalités en raison de la philosophie « des décisions, pas des options ».
D’autres n’étaient pas non plus d’accord avec l’approche du plugin :
« Le plug-in canonique semble grandiose, mais il augmentera encore la charge de maintenance des responsables.
A mon avis, c’est pas possible.
Il sera bien plus préférable d’inclure certaines fonctionnalités de base dans le noyau lui-même au lieu de dire plus loin – C’est un bon endroit pour le plugin.
Quelqu’un d’autre a souligné une faille dans le plugin-first en ce sens que la collecte des commentaires des utilisateurs pourrait ne pas être facile. Si tel est le cas, il se peut qu’il n’y ait pas de bon moyen d’améliorer les plugins d’une manière qui réponde aux besoins des utilisateurs si ces besoins sont inconnus.
Ils a écrit:
« Comment pouvons-nous mieux recueillir les commentaires des utilisateurs ?
À moins que les propriétaires de sites ne soient suffisamment informés pour signaler des problèmes sur GitHub ou Trac (soyons honnêtes, personne ne signale de problèmes de plugins sur Trac), il n’y a vraiment aucun moyen de recueillir les commentaires des utilisateurs pour améliorer ces plugins recommandés/officiels. «
Plugins canoniques
Le développement de WordPress évolue pour apporter des améliorations plus rapidement. Les commentaires des principaux contributeurs indiquent qu’il existe de nombreuses questions non résolues sur la façon dont ce système fonctionnera pour les utilisateurs.
Un indicateur précoce sera dans ce qui se passera avec la fonctionnalité WebP annulée qui était auparavant destinée à être intégrée dans le noyau et deviendra désormais un plugin.
Image sélectionnée par Shutterstock/Studio Romantique
