Lors de la journée des contributeurs de WordCamp US ce week-end, Matt Mullenweg publié un nouvel appel aux équipes de WordPress’ Make pour qu’elles adoptent une approche axée sur les plugins lors du développement de nouvelles fonctionnalités pour le noyau. Il a relancé la notion de plugins canoniques, introduit pour la première fois dans la communauté WordPress en 2009 comme moyen de fournir des fonctionnalités optionnelles aux utilisateurs avec un niveau de confiance plus élevé que les plugins classiques :
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. Ces plugins seraient GPL et vivraient dans le repo WordPress.org, et seraient développés en étroite connexion avec le noyau WordPress. Il y aurait une relation très forte entre le noyau et ces plugins qui garantirait 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 leur sortie sur assurer la compatibilité. Il y aurait un écran dans la section Plugins de l’administrateur WordPress pour présenter ces plugins canoniques comme une sorte de choix de l’éditeur ou de garantie vérifiée. Ces plugins seraient une véritable extension du cœur de WordPress en termes de compatibilité, de sécurité et de support.
Jen Mylo– Plugins canoniques (Dites quoi ?)
La Annuaire des plugins WordPress n’est qu’à un plugin de franchir les 60 000 (au moment de la publication). Contrairement à l’idée des plugins canoniques, le répertoire officiel est toujours comme le Far West en termes de ce que les utilisateurs peuvent attendre des auteurs de plugins. Mullenweg a cité plusieurs scénarios de plugins qui ne sont pas idéaux pour les utilisateurs – comme un plugin contrôlé par une seule entreprise et évoluant pour aller davantage vers une version pro ou supprimer des fonctionnalités auparavant gratuites et les mettre derrière une mise à niveau.
Les plugins canoniques sont destinés à fournir une alternative fiable aux plugins où les motivations des auteurs peuvent ne pas donner la priorité aux utilisateurs. Il offre également aux principaux contributeurs un moyen de démontrer la demande de fonctionnalités qu’ils souhaitent intégrer à WordPress. Quelques projets comme MP6, Gutenberg et l’API REST ont pris cette voie au cœur.
« 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 », a déclaré Mullenweg.
« Je suis très conscient que lorsque les gens visent à avoir quelque chose dans le noyau, un » non « ou » pas maintenant « peut être frustrant et parfois créer une pression artificielle pour mettre quelque chose avant qu’il ne soit prêt, comme je pense que cela s’est produit avec l’API REST dans WP 4.4. »
Dans un domaine connexe Publier qui a inspiré la discussion renouvelée sur les plugins canoniques, Mullenweg a pesé sur la proposition controversée WebP par défaut qui avait récemment reçu de nouvelles objections de la part des développeurs principaux de WordPress. Les contributeurs ont travaillé fébrilement pour réviser leur approche à temps pour la version 6.1.
Mullenweg a recommandé ces nouvelles fonctionnalités comme candidats de choix pour la voie du plugin canonique, suggérant que cela donnerait plus de temps à l’écosystème autour de WebP pour mûrir :
Je suis intéressé par la prise en charge de nouveaux formats et l’amélioration des performances, mais je pense que ce changement poussé par défaut aux utilisateurs lors de la mise à niveau vers 6.1 est beaucoup pour le moment, y compris avec certaines des interactions maladroites que les systèmes d’exploitation ont encore autour de webp (et HEIC ! ) des dossiers.
Je suis heureux que le support pour travailler avec les fichiers webp et HEIC reste dans le noyau, car nous devrions être libéraux dans ce que nous acceptons et travailler avec, mais pas avec le changement pour tout convertir en webp lorsque les JPEG sont téléchargés.
L’équipe Performances envisage de discuter ceci dans le chat programmé de demain. Il n’est pas encore clair si les efforts récents de WebP par défaut seront mis au statut de plug-in canonique ou si une partie de celui-ci peut encore atterrir dans 6.1.
Les réponses à l’appel pour plus de plugins canoniques ont été mitigées, car certains ont immédiatement reconnu la charge accrue pour les mainteneurs de ces plugins.
« WP a juste besoin de surmonter son aversion pour les fonctionnalités optionnelles », a déclaré le développeur WordPress Jon Brown. « Fonctionnalités pouvant être activées/désactivées. « Decisions not options » est une excellente philosophie lorsqu’il s’agit de garder les choses simples pour les utilisateurs, mais il semble avoir été jeté par la fenêtre avec Gutenberg UX, et transformé en axiome lors de la discussion sur l’ajout d’options trivialement simples à la page des paramètres.
Le contributeur parrainé par iThemes, Timothy Jacobs, a déclaré qu’il n’était pas nécessairement favorable à l’ajout de plus d’options à Core, mais pense que les plugins canoniques pourraient être présentés de la même manière que les options.
« Cela ne signifie pas que l’interface utilisateur doit simplement rechercher dans le répertoire des plugins quelque chose que vous voulez », a déclaré Jacobs. « Les plugins canoniques pourraient être exposés dans une interface utilisateur » de type paramètres « . Je pense que les méthodes d’importation sont un peu cachées dans le menu Outils, mais quelque chose comme ça peut-être.
Le contributeur principal Torsten Landsiedel a déclaré que la différence entre les plugins canoniques et plugins de fonctionnalités n’est pas clair. La distinction peut être que les plugins canoniques incluent ceux qui n’appartiennent peut-être jamais au noyau mais qui sont toujours importants pour les utilisateurs.
« Il semble que le plugin ‘WordPress importer’ pourrait être un plugin canonique », a déclaré Landsiedel. « Je ne sais pas si c’est un bon exemple pour un plugin * prospère *. Ne prend pas en charge les images en vedette, lutte avec de grandes quantités de messages/médias, etc.
« Le plugin Health Check utile a du mal à aider les personnes disparues.
« Comment pouvons-nous empêcher ces plugins (quel qu’en soit le nom) de ne pas avoir suffisamment de contributeurs ? Je pense qu’un importateur est un outil crucial, mais pas non plus nécessaire dans le noyau (je peux l’installer si j’en ai besoin, ça va) – mais cela devrait fonctionner et pour le moment cela ne fonctionne pas bien. Mais je ne vois pas beaucoup d’intérêt de la part de la communauté des développeurs pour aider à résoudre ce problème (peut-être parce qu’ils utilisent WP CLI et ne se soucient pas de ce plugin ?) »
Le contributeur principal de WordPress, Colin Stewart, a déclaré que bien qu’il reconnaisse que les fonctionnalités, car les plugins sont d’abord utiles pour les nouvelles fonctionnalités, cela nécessite « une métrique bien meilleure que le » succès fulgurant « pour être incluse dans le noyau.
« Certaines fonctionnalités sont importantes pour la stabilité et protègent les utilisateurs contre les problèmes qui leur causent des maux de tête plusieurs fois au cours de la durée de vie de leur site Web, mais ce n’est pas quelque chose que les utilisateurs pourraient penser à rechercher dans le référentiel de plugins ou à installer à vue », a déclaré Stewart. «La restauration est une telle fonctionnalité, tout comme la santé du site, l’exportation / l’effacement de la confidentialité, etc.
« Un processus formel de prise de décision pour les propositions serait extrêmement utile. Ce sujet revient régulièrement maintenant.
Mullenweg a proposé près de deux douzaines d’idées de plugins canoniques que les équipes Make pourraient envisager et a suggéré que les équipes elles-mêmes pourraient probablement proposer de meilleures idées. En imaginant toutes ces nouvelles fonctionnalités en jeu, ce serait comme une renaissance de l’innovation dans l’administration. C’est une perspective passionnante qui pourrait profiter aux utilisateurs de WordPress tant que les plugins sont présentés de manière à être faciles à adopter. Les premiers commentateurs de l’idée soulèvent des inquiétudes légitimes concernant le manque de responsables, car l’histoire montre que la prise en charge de certains des plugins canoniques existants est quelque peu inégale.
« J’espère que cela suscitera des discussions lors de la journée des contributeurs et au-delà sur la façon dont nous pouvons mieux utiliser les plugins pour augmenter la vitesse d’évolution de WordPress, garder le noyau léger, rapide et opiniâtre, et le faire tout en disant » oui « à plus d’idées et d’expérimentation, », a déclaré Mullenweg.
#Matt #Mullenweg #renouvelle #poussée #pour #les #plugins #canoniques
