Author: esj@rezo.net
Date: 2010-01-07 23:49:29 +0100 (jeu, 07 jan 2010)
New Revision: 14843
Log:
Retour sur [14842]: il y a des plugins installés qui ne sont pas désinstallables, Kolosalle finesse.
Modified:
branches/spip-2.0/ecrire/inc/plugin.php
Le 7 janv. 2010 à 23:54, cedric.morin@yterium.com a écrit :
Sinon je crois qu'une coquille s'est glissée dans
unset($liste[$k]);
comme dans ton commit precedent plutot que
unset($liste);
Je savais bien que j'étais trop fatigué pour travailler....
Il y a néanmoins une incohérence dans ta modif :
si une procédure d'instal echoue, tu retire le plugin de la liste des plugins actifs au moment de l'affichage.
Le plugin n'apparait plus actif dans la liste, mais dans les faits, il l'est encore (cf les fichier tmp/cache/charger_*.php).
Ouille, mais quelle idée d'avoir mis l'appel "verif_plugin()" a milieu des echo 50 lignes avant!
Et je ne comprends pas pourquoi on vérifie d'abord les plugins pour ensuite essayer de les installer.
Ne pourrait-on pas l'appeler APRES, en lui indiquant ceux qu'on a réussi à installer ?
Toute cette interface est à refaire, c'est un sujet de reflexion en cours.
En effet!
Committo,Ergo:Sum
Le 8 janv. 2010 à 08:45, Emmanuel Saint-James a écrit :
Le 7 janv. 2010 à 23:54, cedric.morin@yterium.com a écrit :
Sinon je crois qu'une coquille s'est glissée dans
unset($liste[$k]);
comme dans ton commit precedent plutot que
unset($liste);Je savais bien que j'étais trop fatigué pour travailler....
Il y a néanmoins une incohérence dans ta modif :
si une procédure d'instal echoue, tu retire le plugin de la liste des plugins actifs au moment de l'affichage.
Le plugin n'apparait plus actif dans la liste, mais dans les faits, il l'est encore (cf les fichier tmp/cache/charger_*.php).Ouille, mais quelle idée d'avoir mis l'appel "verif_plugin()" a milieu des echo 50 lignes avant!
Et je ne comprends pas pourquoi on vérifie d'abord les plugins pour ensuite essayer de les installer.
Ne pourrait-on pas l'appeler APRES, en lui indiquant ceux qu'on a réussi à installer ?
Ce sont deux fonctions totalement différentes.
verif_plugin() est appelée pour verifier si un plugin a été supprimé physiquement du disque, et dans ce cas l'enlever des plugins actifs().
Comme le plugin n'est plus là, il est possible de le désactiver puisqu'il n'a pas été chargé.
Lors du scenario qui te pose problème, si une installation échoue, il est trop tard pour désactiver un plugin sur le hit en cours puisque ses fichiers ont déjà été inclus (d'autre part, des plugins deja actifs, ont pu prendre note que ce plugin était actif. Scenario tordu mais plausible).
Il faudrait donc le désactiver (l'enlever de la liste des plugins actifs) puis relancer le hit sans ce plugin. Mais comme on a déjà commencé les affichages, on ne peut plus facilement faire une redirection.
Je pense que le plus propre serait un message d'avertissement, pour permettre à l'utilisateur d'aviser (désactivation ou recherche du problème) plutôt que ne rien dire comme actuellement.
Quand au fait qu'une installation qui plante fait planter tout le hit et donc bloque toutes les autres installations, c'est plus complexe à gérer. Il faudrait lancer chaque installation dans un contexte indépendant des autres. Avec par exemple une iframe par installation à faire.
Mais cela poserait un autre problème qui est le nombre de connexions maximum simultanées à SQL qui est limité sur certains hébergements.
Toute cette interface est à refaire, c'est un sujet de reflexion en cours.
En effet!
Committo,Ergo:Sum