En l’état je pense que je suis allé trop vite dans la reprise du code depuis la dernière 2.23 de Dotclear, essentiellement parce que les modifs actuelles risquent fort de provoquer des erreurs du côté des plugins tiers au moment de la mise à jour, spécialement parce qu’il n’y a pas de moyen de les mettre à jour pendant la transition
.
Je pourrais éventuellement forcer la reconnexion en mode de secours1, juste après le passage en 2.24, pour laisser le temps de mettre à jour les plugins qui ont besoin de l’être, mais pour l’instant cette opération est impossible — le mode de secours ne sert en fait pas à grand chose tel qu’il a été conçu.
On pourrait imaginer qu’un super-administrateur
d’une installation Dotclear est quelqu’un capable d’aller modifier ou créer un fichier sur le serveur (je pense au fichier _disabled qui permet de désactiver un plugin) mais en réalité ce n’est souvent pas le cas.
Il va falloir régler prioritairement le ticket cité plus haut, et encore, je ne suis pas certain que ce soit suffisant.
Un moyen assez simple pour tester ça est de reproduire une installation actuelle en 2.23.1, comme celle qui fait tourner ce blog par exemple, et ensuite de basculer sur le canal unstable pour voir comment se passe la mise à jour et la reconnexion… 2
Ça sera à faire après mon prochain commit sur le dépôt Dotclear, il sera copieux !
Quoi qu’il en soit j’ai du mal à prévoir une sortie à l’heure de la prochaine release, tant qu’une solution efficace n’aura pas été définie et mise en place.
1 De Bernard -
Pour info, le fameux fichier
_disabledest accessible (peut être créé, copier ou supprimé) va FTP (dossier plug par dossier plug)2 De Bernard -
Le “SuperAdmin” pourrait être un admin qui n’a installé que les plugins faisant partie de DC (avec possibilité de tester d’autres plugs un part un). Ce qui amenerait la possibilité de vérifier :
si c’est pas un plug intégré à DC qui pose pb ;-)
quel autre plug testé pose pb
3 De Franck -
Je sais bien tout ça, mais le problème peut se poser bien avant, en affichant par exemple une erreur PHP dès l’authentification par exemple et de plus ne rien afficher d’autre sur la page ; dans ces conditions, il est plus difficile d’agir pour retrouver une situation stable.
4 De Philippe -
Alors ce n’est peut-être pas ce que tu demandais, mais j’ai constaté, depuis quelques mises à jour du canal unstable, qu’on pouvait avoir une page blanche lors de la reconnexion à l’admin.
Curieusement, j’ai résolu (…) le problème en allant sur la page publique d’abord, puis en revenant sur l’admin qui est retombée en marche.
Je viens aussi de tester la mise à jour depuis une version stable (2.23.1) vers une unstable (2.24-dev-r20220917.1113) et tout fonctionne comme il faut (PHP : 8.1.10) ;)
5 De Franck -
Intéressant Philippe, merci pour les retours !
Étrange pour la page blanche, je verrai si ça fait ça chez moi aussi, surtout demain vu le gros commit que je viens de pousser, ça risque de secouer le canal
unstable:-)Pour ton test stable → unstable, c’est avec des plugins tiers ou juste une installation basique ?
6 De Philippe -
Pour le test stable → unstable c’est sur une installation basique, en local, et donc sans autre plugin tiers que SysInfo.
7 De Franck -
Ok
Le prochain test, en ce qui me concerne, ça sera quand je reproduirai ce blog et tout les plugins en local et que je basculerai ensuite sur le canal
unstable:-p