Vous soutenez les anciennes versions de WordPress dans un plugin/thème?
La pratique consistant à ne prendre en charge que la dernière version de WP _ semble être populaire dans les cercles de développement WP, mais il existe un pourcentage considérable de blogs exécutant des versions obsolètes . Ne pas supporter ces plugins semble conduire à une utilisation beaucoup moins importante que si (certaines) versions antérieures sont supportées.
La prise en charge des versions plus anciennes pose des problèmes majeurs, notamment:
- Test compliqué pour plusieurs versions (tests unitaires?);
- Pas d'accès aux dernières fonctionnalités ni de backport.
- Incompatibilités de votre code entre WP versions (fonctionne dans une, casse une autre);
- La plage des besoins en hébergement est plus large (versions antérieures PHP et MySQL, abandonnées par WP).
-
Dans votre expérience, aviez-vous déjà eu à supporter les anciennes versions de WP dans votre code?
Quelles pratiques organisationnelles et techniques ont produit de bons résultats?
Quel type de code utilisez-vous pour gérer le support des versions multiples?.
Soutenir les anciennes versions de WordPress semble raisonnable, mais est-ce vraiment nécessaire? Personnellement, je pense que supporter les anciennes versions est une perte de temps et d’argent et empêche les utilisateurs finaux de mettre à jour leurs installations WordPress. Quel est l'intérêt d'être un développeur WordPress si vous encouragez les utilisateurs à continuer à utiliser des versions non sécurisées et obsolètes?
Le simple fait d'ajouter une fonction qui vérifie la version de la version DB/WP et d'afficher un message d'avertissement si la version obsolète du site est en cours d'exécution rappelle à l'utilisateur de se mettre à jour; Tout le monde sait comment mettre à jour WordPress ces jours-ci - quelques clics et WoW, WP exécute la dernière version.
Je pense que la prise en charge de la rétrocompatibilité d'au moins une version majeure de WordPress est raisonnable, même si rien ne nous empêche de demander la version actuelle. Certaines fonctionnalités ne peuvent tout simplement pas être implémentées de manière à se dégrader de manière élégante (voir par exemple: Post Formats).
Il existe des cas où 2 versions majeures peuvent être nécessaires, mais tout ce qui est au-delà de cela commence vraiment à repousser les limites de la raison. Le rythme de développement de WordPress - sans parler du rythme de découverte/création de nouveaux vecteurs d’exploitation - est tel qu’il est impératif, tant du point de vue de la fonctionnalité que de la sécurité.
WordPress est constamment amélioré, je dis créer pour la version actuelle et laisser le reste derrière.
Quelle est la probabilité que les administrateurs décident de ne pas mettre à jour WordPress, mais mettent quand même à jour les plugins individuels? Ne vont-ils pas simplement oublier le site? Configurez-le pour un client, puis ne le touchez que lorsqu'il doit être amélioré (ou est piraté car les vulnérabilités n'ont pas été corrigées ...).
Si vous ne souhaitez pas inclure trop de piratages rétrocompatibles dans votre code, mais accordez tout de même un soutien aux utilisateurs d'anciennes versions de WP, vous pouvez envisager de développer de nouvelles fonctionnalités uniquement pour les utilisateurs de nouvelles versions de WordPress. toujours des problèmes de sécurité. Ils peuvent donc toujours utiliser les fonctionnalités et s'assurer que les vulnérabilités découvertes seront corrigées.
Supposons que la version 1.5 est la dernière où vous avez encore testé sur WP 3.0, puisque 1.6 vous ne testez que sur WP 3.1 et 3.2. Si vous voulez de nouvelles fonctionnalités, vous devrez mettre à jour le plugin version 1.6 et mettre à jour WordPress (ou bugs de risque). Toutefois, si vous êtes satisfait des fonctionnalités de la version 1.5, vous pouvez installer la version 1.5.1 si elle est publiée pour résoudre un problème de sécurité dans la version 1.5.