Il y a eu beaucoup de références aux "plugins canoniques" de 2009 à aujourd'hui, en particulier chez Matt's WordCamps, mais nous n'avons rien publié d'officiel à propos de l'idée, et nous n'avons pas fait beaucoup de progrès au-delà des discussions sur la façon dont il serait formidable d'avoir plugins canoniques et combien ce serait bien pour la communauté.
Qu'est-ce qu'un plugin WordPress canonique ou un plugin canonique.
C'est l'une des nombreuses choses dont l'équipe principale de validation a parlé ces derniers jours et tout le monde s'accorde à dire que nous devons donner la priorité à cet aspect du projet le plus tôt possible. Voici donc une description de premier ordre de la façon dont nous pensons actuellement aux plugins canoniques, que nous aimerions utiliser pour démarrer une discussion communautaire ciblée sur le sujet.
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 populaires avec une exécution exceptionnelle. Ces plugins seraient GPL et résideraient dans le référentiel 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 était 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 version sur assurer la compatibilité. Il y aurait un écran au sein de la section des plugins d'administration de WordPress pour présenter ces plugins canoniques comme une sorte de garantie du choix de l'éditeur ou vérifié. Ces plugins seraient une véritable extension du noyau WordPress en termes de compatibilité,
Canonical Plugin et WordCamp 2022. L'appel de Matt Mullenweg.
Lors de la journée des contributeurs WordCamp US ce week-end, Matt Mullenweg a publié une invitation renouvelée aux équipes de WordPress Make à adopter une approche plug-in lors du développement de nouvelles fonctionnalités de base. Relance la notion de plug-ins canoniques, Introduit pour la première fois dans la communauté WordPress en 2009 comme moyen de fournir aux utilisateurs des fonctionnalités optionnelles avec un niveau de sécurité supérieur à celui des plug-ins 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 populaires avec une exécution exceptionnelle. Ces plugins seraient GPL et résideraient dans le référentiel 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 était 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 version sur assurer la compatibilité. Il y aurait un écran au sein de la section des plugins d'administration de WordPress pour présenter ces plugins canoniques comme une sorte de garantie du choix de l'éditeur ou vérifiée. Ces plugins seraient une véritable extension du noyau WordPress en termes de compatibilité,
Jen Mylo
La Répertoire des plugins WordPress ce n'est qu'un plug-in de plus de 60.000 XNUMX (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 plug-in qui ne sont pas idéaux pour les utilisateurs, comme un plug-in contrôlé par une seule entreprise et évoluant vers une version pro ou la suppression de fonctionnalités auparavant gratuites et la mise en place d'une mise à jour.
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 atteindre dans WordPress. Certains projets comme MP6, Gutenberg et l'API REST ont introduit ce chemin dans le noyau.
Nous atteignons un point où le noyau doit être plus éditorial et dire "non" aux fonctionnalités qui viennent ad hoc comme ils 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 plug-first 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 vers le noyau si le plug-in devient un succès retentissant,
dit Mullenweg.
Je suis très conscient que lorsque les gens visent à avoir quelque chose dans leur noyau, un "non" ou un "pas maintenant" peut être frustrant et parfois créer une pression artificielle pour insérer quelque chose avant qu'il ne soit prêt, comme je pense que c'est arrivé avec l'API REST dans WP 4.4.
Dans un poster connexe qui a inspiré la discussion renouvelée sur les plugins canoniques, Mullenweg a pesé la proposition controversée de WebP par défaut qui avait récemment reçu de nouvelles objections de la part des principaux développeurs 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 un excellent candidat pour le chemin du plugin canonique, suggérant que cela laisserait 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 envoyé par défaut aux utilisateurs lors de la mise à niveau vers 6.1 est beaucoup pour l'instant, même avec certaines des interactions maladroites que les systèmes d'exploitation ont encore autour de webp ( et HEIC ! ) dossier.
Je suis heureux que le support de travail pour 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 la modification pour tout convertir en webp lorsque les JPEG sont chargés.
L'équipe Performances prévoit d'en discuter dans le chat programmé de demain. On ne sait toujours pas si les tentatives récentes de WebP pointeront par défaut vers le statut de plug-in canonique ou si certains d'entre eux peuvent encore atteindre la version 6.1.
Les réponses à la demande de plug-ins plus canoniques ont été mitigées, car certains ont immédiatement reconnu la charge accrue pour les mainteneurs de ces plug-ins.
"WP a juste besoin de surmonter son aversion pour les fonctionnalités optionnelles», a déclaré le développeur WordPress Jon Brown.
Fonctions 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 un 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 il 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 du plugin quelque chose que vous voulez », a déclaré Jacobs. "Les plugins canoniques pourraient éventuellement ê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 peut-être quelque chose comme ça.
Le principal contributeur Torsten Landsiedel a déclaré que la différence entre les plug-ins canoniques et les plug-ins en fonctionnalité elle n'est pas claire. La distinction pourrait ê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' soit un plugin canonique. 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 une grande quantité de messages/médias, etc. Le plug-in Health Check utile se débat avec les personnes disparues qu'il aide.
dit Landsiedel.
Comment pouvons-nous empêcher ces plugins (quel que soit leur nom) de ne pas avoir suffisamment de contributeurs ? Je pense qu'un importateur est un outil crucial mais inutile dans le noyau (je peux l'installer si j'en ai besoin, d'accord) - mais cela devrait fonctionner et cela ne fonctionne pas bien pour le moment. 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 s'il convient que les fonctionnalités en tant que plugin sont utiles pour les nouvelles fonctionnalités, cela nécessite "une métrique bien meilleure qu'un" succès écrasant "pour l'inclusion 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 vie de leur site Web, mais ce ne sont pas des choses que les utilisateurs pourraient penser à rechercher dans le référentiel de plug-ins ou à les installer.. La restauration est une telle fonctionnalité, tout comme l'intégrité du site, l'exportation/effacement de la confidentialité, etc.
dit Stewart.
"La prise de décision formelle 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 aux équipes Make et a suggéré que les équipes elles-mêmes pourraient probablement proposer de meilleures idées. Imaginer toutes ces nouvelles fonctionnalités en jeu 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 d'une manière facile à adopter. Les premiers commentateurs de l'idée soulèvent des inquiétudes légitimes quant au 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 déclenchera une discussion pendant 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 en disant "oui" à plus d'idées et d'expérimentation.
dit Mullenweg.
