Quelle est l'importance d'écrire un plugin compatible <WP 3.x de nos jours?

J'écris actuellement un plugin simple-ish avec des publications personnalisées et quelques fonctions, en utilisant les métadonnées de publication et en ajoutant quelques variables à la table "options" de la base de données. Au cours de mes recherches, j'ai vu quelques références dans le WP Codex pour rendre le plugin rétrocompatible avec les versions antérieures à WP 3.x et je me demandais simplement à quel point il était important d'intégrer cette compatibilité.

Par exemple, la version la plus ancienne de WP que j'ai jamais vue installée (par un client) était la 3.2, ou quelque part dans le coin. Je ne peux pas imaginer que beaucoup de gens aient plus de 3.x mais je peux me tromper. Je sais qu'en théorie, vous devriez toujours essayer de le rendre parfaitement compatible, mais, en réalité, quelqu'un sait-il à quel point il est important d'inclure cette capacité?

Merci

Toujours écrire des plugins pour la version actuelle et garder à l'esprit les versions nocturnes des versions à venir. Rien d'autre n'a d'importance.

Modifier comme @toscho l'a souligné dans un commentaire:

Il pourrait être nécessaire d'expliquer pourquoi il en est ainsi.

1. Parce que je le dis.
2. 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, il a un bug . Et ce bug doit être corrigé et pas autre chose et pas un autre plugin ou thème.
3. Les utilisateurs qui ne mettent pas à jour WordPress sont le résultat de plugins bogués qui sont utilisés et ne peuvent pas être abandonnés dans les systèmes sans beaucoup de travail. Comme écrit en (2), ce sont des bugs dont vous n'avez pas à vous soucier. Les bogues doivent être corrigés, pas votre plugin, compte tenu du code tiers cassé.
4. Legacy Code n'a besoin d'aucune assistance. Il a besoin d'être remplacé. Pas votre problème.
5. Les choses changent à grande échelle par rapport aux principales versions XX. 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 (a) un cauchemar de maintenance (b) augmente la base de code (c) rend les tests unitaires impossibles car ils doivent s'exécuter sur une seule version - pas moins, pas plus et enfin (d) diminuer l'espace disque et les performances du serveur (dans la plupart des cas).
6. WordPress possède déjà une très ancienne base de code qui manque d'améliorations dans de nombreux bords et coins. En bref: WordPress est ancien, utilise au minimum une version PHP non prise en charge et donc vous supportez déjà les versions précédentes à des niveaux beaucoup plus bas que dans l'API publique de votre application.

Maintenant, allez vous demander:

Lorsque vous prenez déjà en charge une version PHP qui n'est plus prise en charge, pourquoi voudriez-vous prendre en charge une application qui n'est même pas prise en charge par ses créateurs?

N'oubliez pas que la version de WordPress 3.0 nécessite 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 où certains sites WordPress ne pouvaient PAS mettre à jour WordPress 3.0 parce que leurs hébergeurs ne tenaient pas leurs serveurs à jour.

De nombreuses années ont passé (3+) depuis la sortie de WordPress 3.0, donc être rétrocompatible avec WordPress <3.x n'est pas des plugins très courants.

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 du 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 téléchargement de médias, qui a radicalement changé en 3.5.
• Vous faites croire à vos utilisateurs qu'il est acceptable de ne pas mettre à niveau 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 fasse les mêmes choses.

Et les utilisateurs de ceux-ci n'installeront probablement même pas votre plugin car ils savent que de nouveaux plugins cassent déjà leur site. En termes de portée sur le marché, vous pourriez gagner un peu avec un code rétrocompatible. En termes d'efficacité, vous perdez.

Ma règle générale 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 3.6.x et 3.5.x. Bien qu'un plugin particulier puisse fonctionner sur les versions antérieures, je ne le garantis pas et ne le supporte pas si vous rencontrez des problèmes.

Il y a quatre mois, j'ai repris 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 fait un tas de corrections de bugs, publié la nouvelle version et 2 jours plus tard, j'ai entendu un gars qui a dit que la nouvelle version avait provoqué l'écran blanc de la mort sur son site. Après l'avoir examiné, il exécutait toujours WordPress 2.9.2, et ma mise à jour utilisait la fonction home_url, introduite dans 3.0. Je ne sais pas pourquoi le gars a décidé de mettre à jour ce plugin immédiatement, même s'il n'avait pas mis à jour son installation WordPress depuis 3 ans. Quand j'ai fait 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 y a un numéro de version "Nécessite au moins" dans l'en-tête. Utilise le. Lorsque vous effectuez des mises à jour, si vous n'avez pas envie de tester les anciennes versions, incrémentez-le. Cela découragera les utilisateurs refusant de mettre à jour leurs installations WordPress de mettre à jour votre plugin.

J'écris actuellement un nouveau plugin connexe, et je prévois de le faire uniquement WordPress 3.6, car je veux utiliser la bibliothèque getid3 incluse dans le noyau. Je n'ai aucune envie de sortir un nouveau plugin pour une ancienne version core.