Quelle est l'importance d'écrire un < WP 3.x plugin compatible de nos jours?
J'écris actuellement un plug-in simple avec des publications personnalisées et quelques fonctions, en utilisant des métadonnées de publication et en ajoutant quelques variables à la table "options" de la base de données. Au cours de mes recherches, le WP Codex nous a donné des références sur la compatibilité en amont du plug-in avec les versions antérieures à WP 3.x et je me demandais simplement à quel point il était important de l'intégrer maintenant. compatibilité.
Par exemple, la version la plus ancienne de WP que j'ai jamais vue installer (par un client) était la version 3.2, ou quelque part dans les environs. Je ne peux pas imaginer que beaucoup de gens aient plus de 3 ans, mais je peux me tromper. Je sais qu'en théorie, vous devriez toujours essayer de le rendre parfaitement compatible, mais de manière réaliste, est-ce que quelqu'un sait à quel point il est important d'inclure cette capacité?
Merci
Écrivez toujours des plugins pour la version actuelle et gardez à l'esprit les versions nocturnes des versions à venir. Tout le reste n'a pas d'importance.
Modifier Comme l'a souligné @toscho dans un commentaire:
Une explication pourrait être nécessaire pour expliquer pourquoi est ainsi.
- Parce que je le dis.
- Les plugins doivent seulement être compatibles avec le noyau, car si tous jouent avec les règles, rien n'échouera. Si un plugin ne joue pas avec les règles, alors il a un bogue . Et ce bogue doit être corrigé et rien d’autre ni un autre plugin ou thème.
- Les utilisateurs qui ne mettent pas à jour WordPress sont le résultat de plugins buggy utilisés et qui ne peuvent pas être abandonnés dans des systèmes sans beaucoup de travail. Comme écrit dans (2), ce sont des insectes dont vous n'avez pas à vous soucier. Les bogues doivent être corrigés, pas votre plugin en considérant le code tiers cassé.
- Legacy Code ne nécessite aucun support. Il doit être remplacé. Pas votre problème.
- Les choses changent à grande échelle par rapport aux principales versions de X.X. Lorsque vous essayez de prendre en charge les versions précédentes, vous avez souvent besoin de solutions de contournement différentes et de nombreuses vérifications de version. C’est-à-dire que (a) un cauchemar de maintenance (b) augmente la base de code (c) rend les tests unitaires impossibles, car ils doivent fonctionner sur une version - ni moins, ni plus et enfin ( d) réduire l’espace disque et les performances du serveur (dans la plupart des cas).
- WordPress a déjà une base de code très ancienne qui manque d'améliorations dans de nombreux bords et angles. En bref: WordPress est ancien, utilise au minimum une version PHP non prise en charge et vous prenez donc déjà en charge les versions précédentes à des niveaux bien inférieurs à ceux de l'API publique de votre application.
Maintenant, va te demander:
Lorsque vous prenez déjà en charge une version non prise en charge PHP, pourquoi voudriez-vous prendre en charge une application qui n'est même pas prise en charge par ses créateurs?
La plupart des installations WordPress sont obsolètes . Actuellement, seulement 5,2% de toutes les installations fonctionnent sur la dernière version 3.6.
27,3% sont toujours sur la version 3.0.
Vous pourriez penser que vous devez prendre en charge ces anciennes versions avec un code compatible. Mais réfléchissez aux implications:
- Vous devez tester toutes les versions officiellement prises en charge.
- Vous devez gérer des API incompatibles, comme le programme de téléchargement de média, qui a radicalement changé dans la version 3.5.
- Vous incitez vos utilisateurs à penser qu'il est normal de ne pas mettre à jour WordPress, car cela fonctionne toujours.
- Vous avez besoin de plus de code, de plus de tests et de plus de temps pour que le support puisse faire la même chose.
Et les utilisateurs de ceux-ci n'installeront probablement même pas votre plug-in, car ils savent déjà que de nouveaux plug-in détruisent leur site. En termes de portée du marché, vous pourriez gagner un peu avec un code rétrocompatible. En termes d'efficacité, vous perdez.
Rappelez-vous la version de WordPress 3.0 requise PHP5. À l'époque, de nombreuses sociétés d'hébergement n'exécutaient pas encore PHP5 sur leurs serveurs. Il y a donc eu une période au cours de laquelle certains sites WordPress NE PEUVENT PAS mettre à jour WordPress 3.0 car leurs sociétés d’hébergement ne tenaient pas leurs serveurs à jour.
De nombreuses années ont maintenant passé (3 ans et plus) depuis la sortie de WordPress 3.0. Par conséquent, être rétrocompatible avec WordPress <3.x n’est pas très courant en plugins.
Ma règle d'or pour les plugins que j'écris est la prise en charge de la version actuelle moins 1, donc tous les plugins que j'écrirais seraient compatibles avec les versions 3.6.x et 3.5.x. Bien qu'un plugin particulier puisse fonctionner sur des versions antérieures, je ne le garantis pas, ni ne le supporte en cas de problème.
Il y a quatre mois, j'ai pris en charge la maintenance d'un plugin populaire. Avant de commencer à travailler dessus, le plugin n'avait pas eu de mise à jour depuis 2 ans. J'ai corrigé plusieurs bugs, publié la nouvelle version et, deux jours plus tard, j'ai entendu un gars dire que la nouvelle version causait l'écran blanc de la mort sur son site. Après l’avoir étudié, il exécutait toujours WordPress 2.9.2 et ma mise à jour utilisait la fonction home_url, introduite dans la version 3.0. Je ne sais pas pourquoi le gars a décidé de mettre à jour ce plugin immédiatement, alors qu'il n'avait pas mis à jour son installation WordPress depuis 3 ans. Quand j'ai créé la nouvelle version, je n'ai jamais pensé à tester WordPress 2.9.2.
Voici la morale de l'histoire: Dans le fichier readme.txt de votre plugin, il existe un numéro de version "Nécessite au moins" dans l'en-tête. Utilise le. Au fur et à mesure que vous effectuez des mises à jour, incrémentez-les si vous ne souhaitez pas tester les anciennes versions. Cela découragera les utilisateurs refusant de mettre à jour leurs installations WordPress de mettre à jour votre plugin.
Je suis en train d'écrire un nouveau plugin connexe, et je prévois de le faire uniquement avec WordPress 3.6, car je veux utiliser la bibliothèque getid3 incluse dans le noyau. Je n'ai aucune envie de publier un nouveau plugin pour une ancienne version de base.