Salut,
J’ai du forker une fonction de SPIP pour faire en sorte que l’on puisse lire plusieurs dossiers de plugins comme par exemple sur du mutualisé avec le dossier plugins/ du site maitre et le dossier plugins/ du site esclave.
Voici ce que j’ai fait :
on définit dans le mes_options du site esclave ceci : $GLOBALS[‘pg_pth_dir’] = array(’…/plugins/’, '…/web/lesite.fr/plugins’); où l’on peut mettre autant de dossiers de plugins que l’on veut.
on modifie la fonction liste_plugin_files() de inc/plugin.php comme ci :
function liste_plugin_files(){
static $plugin_files=array();
$pg_d_pth = $GLOBALS[‘pg_pth_dir’];
if (is_array($pg_d_pth))
$nb = count($pg_d_pth);
else
$nb = 1;
if (!count($plugin_files)){
if ($nb == 1) {
foreach (preg_files($pg_d_pth, ‘/plugin[.]xml$’) as $plugin) {
$plugin_files[]=substr(dirname($plugin), strlen(_DIR_PLUGINS));
}
}
else if ($nb > 1) {
foreach ($pg_d_pth as $path_pg) {
foreach (preg_files($path_pg, ‘/plugin[.]xml$’) as $plugin) {
$plugin_files[]=substr(dirname($plugin), strlen($path_pg));
}
}
}
sort($plugin_files);
}
return $plugin_files;
}
Et hop ! j’ai autant de dossiers de plugins que je veux…
Le problème est le fork… Ne pourrait-on pas envisager de passer cette fonction en _dist pour peut-être rajouter ceci dans le plugin mutualisation ?
Ou aussi tout autrement, je pense(avec mon humble avis) que l’on pourrait peut-être même passer ça dans le core (en modifiant un peu ma fonction bien sûr).
Salut Fil,
Je suis désolé pour mon patch, je m'aperçois qu'il ne "marchait" que pour lister les plugins, merci de l'avoir amélioré.
Je vais donc tester ceci et si tout marche bien en mutu je l'intégrerais.
Maintenant que ceci est géré en "native" par SPIP, ce ne serait pas une bonne idée de faire une petite interface dans la 2.1 pour pouvoir sélectionner les chemins des plugins dans la conf ? On pourrait alors choisir un dossier www/core pour les plugins du core et www/plugins pour tous les autres plugins (où le webmaster choisirait les chemins).
Comme je vois que le code est à refaire, peut-être ceci pour plus tard ^^.
Je vais donc tester ceci et si tout marche bien en mutu je l'intégrerais.
super !
Maintenant que ceci est géré en "native" par SPIP, ce ne serait pas une
bonne idée de faire une petite interface dans la 2.1 pour pouvoir
sélectionner les chemins des plugins dans la conf ? On pourrait alors
choisir un dossier www/core pour les plugins du core et www/plugins pour
tous les autres plugins (où le webmaster choisirait les chemins).
Je vais donc tester ceci et si tout marche bien en mutu je l'intégrerais.
super !
Maintenant que ceci est géré en "native" par SPIP, ce ne serait pas une
bonne idée de faire une petite interface dans la 2.1 pour pouvoir
sélectionner les chemins des plugins dans la conf ? On pourrait alors
choisir un dossier www/core pour les plugins du core et www/plugins pour
tous les autres plugins (où le webmaster choisirait les chemins).
Non car ce serait un trou de sécurité précisément
Hum... Pourquoi donc ? Si c'est limité seulement au(x) webmestre(s), l'auteur 1 sait en qui il a confiance...
Hum... Pourquoi donc ? Si c'est limité seulement au(x) webmestre(s),
l'auteur 1 sait en qui il a confiance...
Parce que l'auteur1 du site mutualisé toto n'est pas "webmestre du
serveur" si tu vois ce que je veux dire.
Ah oui effectivement en mutu ça ouvre une faille potentielle car on pourrait "piquer" les plugins d'un autre site. Donc à moins que cette interface soit utilisé que par un admin de tous les sites, ce n'est pas possible de faire ça.
L'usage le plus adapté à mon sens c'est d'avoir un éventuel répertoire
sites/xxxx/plugins/ en plus des plugins/ de la racine.
Oui, en mutu c'est l'essentiel !
Par contre, ce qui serait peut-être possible avec PHP, ce serait de bloquer la remontée dans l'arborescence au repertoire tmp/ du site local avec une constante et on pourrait débloquer ceci en redéfinissant la constante dans mes_options.
Là c'est sur que ça devient compliqué et ça serait un casse tête de coder tout ça mais ça pourrait être intéressant...
Salut,
Alors voilà, mes tests :
J'ai défini 2 dossiers de plugins avec
define('_DIR_PLUGINS_SUPPL', _DIR_RACINE.'core/:'._DIR_RACINE.'autres/plugins/');
ça marche super bien.
Les plugins s'y retrouvent dans tous ces dossiers.
* Yohann Prigent tapuscrivait, le 28/08/2009 00:34:
Salut,
Alors voilà, mes tests :
J'ai défini 2 dossiers de plugins avec
define('_DIR_PLUGINS_SUPPL', _DIR_RACINE.'core/:'._DIR_RACINE.'autres/plugins/');
ça marche super bien.
Les plugins s'y retrouvent dans tous ces dossiers.
Pour moi c'est donc bon pour intégrer en stable
Donc, d'après Yohann, il suffit de faire ce define dans le mes_options des sites mutualisés en ayant besoin.
D'après moi, ça introduit un problème de sécurité si l'utilisateur d'un site a,
- soit un accès FTP à sites/sonnomdedomaine/ parce que ça lui permet d'installer un plugin tel que skeleditor qui du coup donne accès à tous les fichiers depuis la racine de la mutualisation
- soit une possibilité d'utiliser les plugins auto
Par contre, sans accès FTP ni à auto, ça peut permettre de donner accès à une liste de plugins spécifique à un site particulier, en plus de ceux communs à tous.
Mais est-ce vraiment intéressant par rapport a définir pour un site particulier que son dossier plugins/ est ailleurs que celui par défaut ?
Salut,
Si l'utilisateur a un ftp c'est déjà une faille, donc je pense qu'on ne peut se fier à ça.
Pour les plugins auto par contre là c'est une bonne question, il suffit de ne pas donner l'accès à apache en écriture.
Pour l'intêret, imaginons le site maitre qui utilise skeleditor.
S'il ne veut pas que les autres aient accès à ce plugin, il faut mettre le define dans son mes_options seulement avec le chemin de skeleditor.
Ca permettrait par exemple à certains utilisateurs d'avoir accès à plus de fonctions avec plus de plugins
Si l'utilisateur a un ftp c'est déjà une faille, donc je pense qu'on ne peut
se fier à ça.
exact
Pour les plugins auto par contre là c'est une bonne question, il suffit de
ne pas donner l'accès à apache en écriture.
il ne faut pas d'auto/ en mutualisation
Pour l'intêret, imaginons le site maitre qui utilise skeleditor.
idem. Si tu permets de modifier les squelettes, en mutualisation, tu
n'as plus aucune étanchéité entre les sites mutualisés. Car dans un
squelette on met ce qu'on veut comme code php.
idem. Si tu permets de modifier les squelettes, en mutualisation, tu
n'as plus aucune étanchéité entre les sites mutualisés. Car dans un
squelette on met ce qu'on veut comme code php.
Pour les sites mutualisés, les autoriser à utiliser skeleditor c'est une faille énorme car comme tu le dit, le php va dans un squelette. D'où mon exemple comme si que le site maitre voulait l'utiliser.
Juste pour le signaler aux autres : j'ai fait un plugin multiplug qui est un fork de ce qui est présent pour la 2.1 dans la 2.0 ici : http://zone.spip.org/trac/spip-zone/browser/plugins/multiplug
Pour tout ceux qui voudraient donc tester en 2.0 sans avoir à passer en 2.1... allez y, petit hic, ça ne marche qu'en mutu je pense le temps que je modifie quelques choses.
