Presque depuis l’aube de l’inclusion des mécanismes de mise à niveau des plugins et des thèmes dans le noyau il y a plus de dix ans, les développeurs tiers ont demandé un moyen simple de contourner le système. WordPress 5.8 va enfin répondre à cette demande de fonctionnalité.

Bien qu’il soit depuis longtemps possible de filtrer le système de mise à jour, les méthodes pour le faire étaient plus complexes que nécessaire. Ils ont également exigé que le plugin lui-même soit actif sur un site. Un simple indicateur pour activer / désactiver la fonctionnalité sur une base par plugin est attendu depuis longtemps.

“L’utilité est qu’il s’agit d’une API abstraite qui permet deux choses,” a écrit Dion Hulse dans une demande d’extraction GitHub qui a corrigé le code:

  • Un plugin pour déclarer un URI / une chaîne qui, s’il est défini, les API de mise à jour de WordPress.org ignorent le plugin.
  • Le code en cours d’exécution sur le site peut utiliser ces en-têtes hostname / data pour offrir une mise à jour du plugin à stocker dans le transitoire de mise à jour, sans avoir à sauter à travers des obstacles tels que le remplacement du transitoire / vérifier trop souvent / etc.

WordPress 5.8 aura un nouveau Update URI champ d’en-tête du plugin. Si sa valeur correspond à autre chose que https://wordpress.org/plugins/{$slug}/ ou alors w.org/plugin/{$slug}, WordPress n’essaiera pas de le mettre à jour.

Au-delà de cela, les développeurs peuvent déployer leurs propres solutions s’ils souhaitent gérer les mises à jour des plugins non-WordPress.org. C’est là que le nouveau update_plugins_{$hostname} le filtre entre en jeu. WordPress analysera l’URL incluse dans le plugin Update URI en-tête et utilisez le nom d’hôte comme valeur. Les développeurs peuvent alors s’y connecter et faire tout ce dont ils ont besoin.

Les auteurs de plugins avec des extensions hébergées par WordPress.org n’auront pas à se soucier de l’ajout de ce nouvel en-tête. Règle n ° 8 des directives du plugin interdit déjà l’envoi de code exécutable via des systèmes tiers. La sous-section suivante couvre plus spécifiquement ce scénario:

Servir des mises à jour ou installer des plugins, des thèmes ou des modules complémentaires à partir de serveurs autres que WordPress.org

La discussion a pris de l’ampleur il y a 13 mois sur un billet enfant de six ans. “Un plugin a maintenant été supprimé sans ménagement du site Web d’un client lors de l’exécution de la mise à jour automatique programmée du plugin,” a écrit un contributeur avec le nom d’utilisateur apedog. «C’est en fait la deuxième fois que je rencontre ce problème de conflit de noms pour l’un de mes plugins. Dans les deux cas, j’avais choisi un nom de plugin sans conflit de dénomination apriori. Cependant, plus tard, quelqu’un d’autre avait également écrit un plugin avec le même nom générique et l’avait soumis au dépôt wp.org. À partir de ce moment, le bon fonctionnement de mon plugin est interrompu. »

Bien que le problème de suppression ne se soit pas avéré être un problème du côté de WordPress, c’était peut-être l’étincelle nécessaire pour poursuivre la conversation.

Une discussion active n’indique pas toujours qu’une fonctionnalité obtient le feu vert. Cela ne signifie pas non plus que quelqu’un écrira le code. Beaucoup de ces billets ont eu des mois ou des années de conversation, pour finalement languir et mourir. Ce billet semblait aussi correspondre à cette facture. Il a été ouvert en 2015. Cependant, les nouvelles fonctionnalités sont parfois plus une question de timing, juste du pur hasard, ou un développeur avec un accès de commit principal faisant simplement le travail.

Le ticket pour les plugins a été accepté et engagé sur WordPress. Cependant, il reste la question de savoir si cela va atterrir pour les thèmes. Le mouvement dans le Billet à thème 11 ans indique que cela pourrait arriver.


Source link