Et ça n’est pas une bonne nouvelle !
Je cause des plugins et accessoirement des thèmes tiers de la galaxie Dotclear, évidemment.
Hier en cherchant la cause d’un blocage inopiné et involontaire d’une installation Dotclear fraîchement mise à jour vers la dernière version, j’ai découvert un plugin qui n’avait pas supporté cette étape et qui, de plus, provoquait une erreur telle que l’ensemble était bloqué.
Bref, il y a un problème pas résolu que de laisser actif des plugins non testés avec une version de Dotclear donnée.
Jusqu’à maintenant on indiquait, souvent, la version minimale attendue pour un plugin, ce dernier étant désactivé s’il était installé sur une version moins récente. L’inverse n’est pas vrai par contre, historiquement parce qu’on ne peut prévoir à l’avance les évolutions de Dotclear et par conséquent il est difficile d’indiquer une version maximale
compatible.
Il faudrait donc que ce soit Dotclear, forcément au courant de ses évolutions, qui désactive, a minima temporairement, les plugins non marqués comme compatibles. C’est une solution un peu extrême je trouve, mais qui a le mérite d’empêcher un blocage du blog.
J’avoue que ça me plaît à moitié …
Parce qu’un plugin peut très bien continuer à fonctionner, même en mode dégradé
, sur une version plus récente ; j’en connais quelques uns dans ce cas là, plus maintenus par leurs auteurs mais toujours suffisamment fonctionnels pour remplir peu ou prou leur rôle.
Par ailleurs le mode de secours de Dotclear, qui permet d’ouvrir une session d’administration sans aucun plugin actif, n’est pas d’un grand secours, à part éventuellement pour supprimer un plugin, vu qu’il ne permet même pas de mettre à jour un plugin obsolète1.
Bref, y’a un os dans le potage !
Je m’inquiète un peu de ça parce que la prochaine 2.24 de Dotclear, même si je tente d’assurer une compatibilité ascendante, risque de va provoquer pas mal d’erreurs dans du code pas mis à jour et pour lequel aucune évolution n’est prévue.
Essentiellement parce que la plupart des méthodes des classes PHP du code de la 2.24 ont des signatures
typées et que PHP va lever des exceptions avec du code ancien les utilisants avec des arguments typés différemment.
Pour ma part, parmi les plugins que je développe et/ou maintiens, il y en a quelques uns qui seront concernés (une nouvelle version sera publiée pour chacun d’entre eux) :
- cloneEntry
- dcRevisions
- growUp
- logNotices (mais je pense que je dois être le seul à l’utiliser celui-ci)
- private
- rosetta
- series
- sysInfo
- tweakurls
- typo
- wordCount
Donc une fois la mise à jour de Dotclear faite de la 2.23.1 à la 2.24, il suffira de mettre à jour ceux-ci dans la foulée pour que ça retombe en marche.
Le problème se posera pour les autres, ceux que je ne gère pas… Et à ce jour je n’ai pas de solution hormis celle évoquée plus haut mais que je trouve un peu trop radicale.
Idéalement il faudrait pouvoir tester ces plugins tiers sur une version 2.24 de test, mais qui est en mesure de le faire à la demande ?
-
Il y a possiblement un ticket à ouvrir à ce sujet d’ailleurs ! ↩︎
1 De Biou -
J’ai une idée, et si tu appelais la nouvelle version Dotclear 3, comme ça t’as le droit de tout casser la compatibilité ;)
2 De Franck -
Ah mais je peux pas, y’a déjà une branche Dotclear 3 (gérée par JcDenis) qui casse tout :-D
3 De Bernard -
Je me souviens d’un temps où on avait testé les plugs: Testage des plugins déposés sur DA
Faudrait peut-être relancer l’opération -écopage :-) en permettant, en plus, d’informer sur les erreurs pouvant survenir sur les contacts du concepteur des plugs (et éventuellement les pages support non existantes ou celles qui renvoient vers le forum sans précision de billet destiné au pb spécifique du plug) ?
En gros, on pourrait avoir une liste de plugs qui fonctionnent avec la version X de Dc et une liste de plugs qui “rouillent” et sont (ou pas) en maintenance…
Quant au mode de secours, je me demande s’il n’y a pas moyen de désactiver uniquement les plugins qui ne sont pas intégrés à Dc (qui, en principe sont à jour). Parce que, tester dans tout un tas de plugs pour séparer le bon grain de l’ivraie, n’est pas une sinécure ;-)
4 De Franck -
En ce qui concerne le mode de secours, je suis d’accord qu’il y a des choses à revoir dedans, mais peut-être pas pour tout de suite (2.25 ?)
J’avais oublié cette page du wiki de test des plugins de l’époque (2013), merci pour le rappel :-)
Maintenant la force de travail s’étant légèrement amenuisée depuis une dizaine d’année (c’est un euphémisme), je pense que c’est hors de portée. Ou alors une bonne volonté dans le public… ?
5 De Philippe -
Au sujet de des thèmes et plugins obsolètes, pourrait-on ajouter automatiquement dans la fiche de chacun sur Dotaddict la mention :
Juste avant le titre Informations générales
En récupérant le numéro de version minimale qui est, selon l’auteur, la dernière version de Dotclear pour laquelle l’extension a été publiée.
6 De Guillaume [Matos Vélo] -
La difficulté viendra notamment des plugins non suivis depuis des années et qui sont pourtant utilisés par pas mal de monde. Le premier qui me vient à l’esprit, Galleryinsert. Plus de suivi depuis 2017. J’ai tenté de joindre l’auteur, sans succès, même via Linkedin.
Comme je l’indique dans le dernier billet de ce post ( https://forum.dotclear.org/viewtopic.php?id=45455&p=11 ), pour moi, impossible de m’en passer. Je suis prêt à payer quelqu’un pour une mise à jour personnelle de ce plugin, mais encore faut-il trouver une personne compétente ET qui connaisse Dotclear à y être.
7 De Franck -
Philippe c’est possible en effet d’ajouter une métadonnée du coté de DotAddict avec cette information, éventuellement s’en servir du côté de Dotclear pour afficher aussi celle-ci dans la liste des plugins qu’on propose d’installer ; cela dit ça ne règle pas grand chose.
Guillaume, exactement, ce n’est pas une question de fric, juste de disponibilité, et ça on n’y peut rien.
Au passage je comprends parfaitement ceux qui ont joué un temps avec Dotclear et c’était cool et qu’ils soient ensuite passé à autre chose ; tous les projets libres fonctionnent ainsi.
8 De Guillaume [Matos Vélo] -
En effet Franck, ce n’est nullement une critique.
9 De Tomek -
Comme Guillaume, je serais très emmerdé de ne plus pouvoir utiliser gallery insert qui est tout de même pas mal foutu (sauf sur des sites avec beaucoup de dossiers dans le gestionnaire de médias, a priori, car il liste tout…) pour intégrer rapidement des galeries.
Quelle solution peut-on avoir ? Essayer de trouver quelqu’un qui veut bien le reprendre ? Au hasard JCDenis ? :-D
10 De Franck -
Tomek ça m’étonnerait que JcDenis ait du temps à consacrer à la reprise d’un plugin en ce moment, il est full occupé par autre chose, même ses développements sur la branche Dotclear 3.0 sont à l’arrêt depuis le début juillet.
Peut-être qu’il me contredira ici même, on verra bien (mais j’en doute) :-)
11 De Guillaume [Matos Vélo] -
Oui Tomek, la limite de gallery insert, c’est son temps de réaction quand on a beaucoup de dossiers et sous dossiers. Je pense que réétudier le plugin serait l’occasion de corriger ce souci. Mais en effet, il faut trouver la personne capable de faire ça et qui en a le temps. Pas évident et c’est compréhensible pour tous les plugins. Comme le dit Franck, c’est le souci du modèle “libre”. Certains se sont investis et sont passés à autre chose. Et la communauté Dotclear est assez limitée, surtout si on compare à Wordpress. Ca a des avantages (le code Dotclear plus propre par exemple), mais des limites pour le suivi de certains plugins.
Mais bon, on a tout de même la chance que certains tiennent à bout de bras Dotclear, ils sont peu nombreux, mais y passent du temps.
12 De Franck -
Au sujet de ce plugin, une petite et quelques recommandations ;-)
13 De Franck -
Une raison pour laquelle il est, à mon humble avis, d’utiliser Dotclear pour autre chose que des blogs perso, ou alors c’est avec connaissance de cause.
14 De Guillaume [Matos Vélo] -
Risqué ? D’un autre côté, j’ai commencé à utiliser Dotclear il y a plus de 10 ans… pour un blog perso devenu pro. Difficile de passer à autre chose maintenant, d’autant que ce CMS me convient parfaitement.
15 De Tomek -
Alors j’aime vivre avec le risque ! :-P
16 De Feuilledethé -
Je réagis tardivement à ce billet. Est-ce qu’il y a toujours un intérêt à tester les plugins ? A mon avis oui, d’autant plus qu’il n’y a pas d’information sur la version minimale de DC ou autre pré-requis quand on en installe à partir du gestionnaire de plugins.
Dans le cas d’une reprise de la campagne de tests, qu’est-ce qu’il serait pertinent de faire, quelles versions tester (les versions archivées 2.16 à 2.20 ne semblent pas utilisables) et comment ?
Ce genre de fiche est-elle utilisable ? à améliorer ? https://lite.framacalc.org/compatibilite_dc-9wt0
17 De Franck -
, ça c’était vrai du temps où il y avait a minima une dizaine de volontaires pour le faire, mais vu l’état de la troupe restante, c’est illusoire.
Comme je l’ai déjà dit, je m’occuperai des plugins que je gère ; je n’aurai pas le temps pour faire plus.
Maintenant si une initiative se met en place, ça sera le bienvenu, et je conseillerai dans ce cas d’utiliser le forum pour l’organiser ;-)
18 De Bernard -
Franck: Au regard de ceux qui suivent encore certes! mais amha un petit appel aux aides serait-il possiblement négatif ? (sur le blog DC et à partir des contacts encore existants sur le blog et les plugins)
19 De Bernard -
Je ne suis pas sûr d’avoir le temps; mébon, avec une motivation “groupiste” ça me permettrait de me remettre à l’ouvrage…
peut-être trouver aussi dans ce tableau les versions php et Dotclear (stable, unstable et/ou testing) utilisées ?
20 De Bernard -
Vu le chemin parcouru depuis des lustres, on va quand même pas finir par devenir Dotpress ou Wordclear, non ?
oki, je sors ;-p