[SPIP Zone] r100791 - _plugins_/mutualisation/trunk

RealET · Novembre 30, 2016, 11:04

prigent.yohann@gmail.com a écrit le 30/11/2016 à 23:54 :

J’ai été confronté à un soucis : J’ai voulu faire en sorte que sur tous mes sites mutualisés, on inclus le fichier squelettes/mes_options.php

Alors, d'après la doc : Le fichier mes_options.php - SPIP
Ce fichier est à créer (s’il n’existe pas déjà) dans le répertoire config/

Donc, le mettre dans squelettes/ c'est une aberration

AMHA : revert.

D'autres avis ?

--
RealET

Mist_GraphX · Décembre 1, 2016, 9:19

Le 01/12/2016 à 00:04, RealET a écrit :

prigent.yohann@gmail.com a écrit le 30/11/2016 à 23:54 :

J’ai été confronté à un soucis : J’ai voulu faire en sorte que sur
tous mes sites mutualisés, on inclus le fichier
squelettes/mes_options.php

Alors, d'après la doc : Le fichier mes_options.php - SPIP
Ce fichier est à créer (s’il n’existe pas déjà) dans le répertoire config/

Donc, le mettre dans squelettes/ c'est une aberration

AMHA : revert.

D'autres avis ?

Au passage quand je regarde la fonction, le dossier squelette est marqué en dur, autant utiliser : $GLOBALS['dossier_squelettes'].

Mais effectivement c'est dans config, que le fichier est pris en compte.

Sinon je profite du fil de discussion :

Pour certains sites j'aimerais avoir des rêgles de réécriture différentes et donc un htaccess par site, j'ai fait quelques test mais sans plus, quelqu'un as t'il déjà fait ça sur une mutualisation ?

--
Bonne journée
Arnaud B. (Mist. GraphX)

jeanmarie · Décembre 1, 2016, 10:16

Salut,

C’est mal La solution que j’utilise pour que les règles s’appliquent a un seul domaine et pas aux autres malgré un seul .htaccess à la racine : RewriteCond %{HTTP_HOST} !=www.domaine1.net RewriteRule .* - [S=3] (règle 1) (règle 2) (règle 3) jean marie

RealET · Décembre 2, 2016, 7:02

RealET a écrit le 01/12/2016 à 00:04 :

prigent.yohann@gmail.com a écrit le 30/11/2016 à 23:54 :

J’ai été confronté à un soucis : J’ai voulu faire en sorte que sur
tous mes sites mutualisés, on inclus le fichier
squelettes/mes_options.php

Alors, d'après la doc : Le fichier mes_options.php - SPIP
Ce fichier est à créer (s’il n’existe pas déjà) dans le répertoire config/

Donc, le mettre dans squelettes/ c'est une aberration

AMHA : revert.

D'autres avis ?

Revert fait (avec documentation) :

--
RealET

marcimat · Décembre 3, 2016, 2:16

Le 02/12/2016 à 20:02, RealET a écrit :

AMHA : revert.

D'autres avis ?

Revert fait (avec documentation) :
Connexion · GitLab

Alors oui et non, non ?

Parce que le avant_initialisation ajouté, n'était pas forcément fait pour ajouter un mes_options (meme si c'est ce que disait le message, ça ne reste qu'un exemple). Ça me semblait juste un point d'entrée pour faire des choses, et ça ne gênait rien (ie: déclarer une fonction, qui, si c'est fait est exécutée à un moment donné).

Cela étant dit ce n'était pas utile pour l'exemple indiqué. Ce point d'entrée ne me semblait pas particulièrement gênant.

(je n'avais pas regardé le détail du premier commit qui avait introduit ça).

Peut être que c'était juste la documentation à revert.

MM.

Yohann_Prigent · Décembre 19, 2016, 9:12

Hello hello,

J’ai manqué les mails sur ce sujet, désolé.

Effectivement, logiquement le fichier d’options est à mettre dans le répertoire config/mes_options. Je vais donc rééexpliquer mon contexte :

je suis sur une mutualisation avec plusieurs sites
je veux appliquer des options (ici en loccurence la définition d’un dossier de plugins supplémentaires) à tous mes sites SPIP
sauf que pour l’appliquer à tous mes sites automatiquement - donc sans passer par un sites/x/config/mes_options.php par site (ce qui est vite difficile à maintenir), je dois le mettre dans le mes_options.php global
sauf que… ça ne fonctionne pas au début du fichier, car j’ai besoin de _DIR_SITE qui est défini après
sauf que… ça ne fonctionne pas tout le temps à la fin du fichier, car les fonctions d’initialisations sont déjà executées par demarrer_site

La seule solution que j’ai donc trouvé pour appliquer des options globalement à mes sites est donc de faire une fonction avant_initialisation. Ça ne casse rien, ça ne réduit même pas la comptabilité PHP si on ne la définit pas, et surtout ça permet donc de définir globalement des options pour tous ses sites.

Alors après l’exemple de l’include du squelettes/mes_options a peut-être induit en erreur Jacques, mais après tout un fichier config/mes_options.php c’est… un fichier PHP. Donc libre à moi de faire un simple include, si je veux inclure mes options dans mon dossier squelettes/ qui lui seul est versionné.

Du coup, je ne comprends vraiment pas le revert. Faute d’explications du pourquoi ça n’a pas sa place, je rereverterai dans l’après-midi. Puis comme dit Marcimat : [c’est] juste un point d’entrée pour faire des choses, et ça ne [gêne] rien

Yohann

From: Matthieu Marcillaud marcimat@rezo.net
Date: 3 December 2016 at 03:16:09
To: spip-zone@rezo.net spip-zone@rezo.net
Subject: Re: r100791 - plugins/mutualisation/trunk

Le 02/12/2016 à 20:02, RealET a écrit :

AMHA : revert.

D’autres avis ?

Revert fait (avec documentation) :
Connexion · GitLab

Alors oui et non, non ?

Parce que le avant_initialisation ajouté, n’était pas forcément fait
pour ajouter un mes_options (meme si c’est ce que disait le message, ça
ne reste qu’un exemple). Ça me semblait juste un point d’entrée pour
faire des choses, et ça ne gênait rien (ie: déclarer une fonction, qui,
si c’est fait est exécutée à un moment donné).

Cela étant dit ce n’était pas utile pour l’exemple indiqué. Ce point
d’entrée ne me semblait pas particulièrement gênant.

(je n’avais pas regardé le détail du premier commit qui avait introduit
ça).

Peut être que c’était juste la documentation à revert.

MM.

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

RealET · Décembre 19, 2016, 2:58

Yohann Prigent a écrit le 19/12/2016 à 10:12 :

Hello hello,

J'ai manqué les mails sur ce sujet, désolé.

Il n'est jamais trop tard ici

Effectivement, logiquement le fichier d'options est à mettre dans le
répertoire config/mes_options. Je vais donc rééexpliquer mon contexte :
1) je suis sur une mutualisation avec plusieurs sites
2) je veux appliquer des options (ici en loccurence la définition d'un
dossier de plugins supplémentaires) à tous mes sites SPIP
3) sauf que pour l'appliquer à tous mes sites automatiquement - donc
sans passer par un sites/x/config/mes_options.php par site (ce qui est
vite difficile à maintenir), je dois le mettre dans le mes_options.php
global

Juste une remarque pour cette partie-là pour ceux qui en aurait besoin, ça se fait avec
define('_DIR_PLUGINS_SUPPL', _DIR_RACINE.'sites/x/plugins/');
Alors qu'hors d'une mutualisation, on n'a pas besoin du _DIR_RACINE.

4) sauf que... ça ne fonctionne pas au début du fichier, car j'ai besoin
de _DIR_SITE qui est défini après
5) sauf que... ça ne fonctionne pas tout le temps à la fin du fichier,
car les fonctions d'initialisations sont déjà executées par demarrer_site

La seule solution que j'ai donc trouvé pour appliquer des options
globalement à mes sites est donc de faire une fonction
avant_initialisation. Ça ne casse rien, ça ne réduit même pas la
comptabilité PHP si on ne la définit pas, et surtout ça permet donc de
définir globalement des options pour tous ses sites.

Alors après l'exemple de l'include du squelettes/mes_options a peut-être
induit en erreur Jacques, mais après tout un fichier
config/mes_options.php c'est... un fichier PHP. Donc libre à moi de
faire un simple include, si je veux inclure mes options dans mon dossier
squelettes/ qui lui seul est versionné.

Peut-être que ça serait plus clair avec un fichier nommé :
mutualisation_options.php
le mes_options.php contraire à la doc de SPIP m'a vraiment choqué.

Du coup, je ne comprends vraiment pas le revert. Faute d’explications du
pourquoi ça n’a pas sa place, je rereverterai dans l'après-midi. Puis
comme dit Marcimat : [c'est] juste un point d'entrée pour faire des
choses, et ça ne [gêne] rien

Alors, dans ce cas-là, oui, ça me semble correct de refaire ton commit, (avec un autre nom pour le fichier d'options ?) et une doc plus explicite comme tu viens de le faire dans ton mail.
Et une mise à jour de la doc ici pour ne pas perdre la procédure :
https://contrib.spip.net/La-mutualisation-facile-modifications-manuelles

Merci
--
RealET

Yohann_Prigent · Décembre 19, 2016, 3:11

From: RealET real3t@gmail.com
Reply: RealET real3t@gmail.com
Date: 19 December 2016 at 15:59:10
To: spip-zone@rezo.net spip-zone@rezo.net
Subject: Re: [SPIP Zone] r100791 - plugins/mutualisation/trunk

Juste une remarque pour cette partie-là pour ceux qui en aurait besoin,
ça se fait avec
define(‹ _DIR_PLUGINS_SUPPL ›, _DIR_RACINE.‹ sites/x/plugins/ ›);
Alors qu’hors d’une mutualisation, on n’a pas besoin du _DIR_RACINE.

Autant utiliser _DIR_SITE. C’est une constante définie justement par la mutualisation qui sert à indiquer le chemin de mon site.

sauf que… ça ne fonctionne pas au début du fichier, car j’ai besoin
de _DIR_SITE qui est défini après

sauf que… ça ne fonctionne pas tout le temps à la fin du fichier,
car les fonctions d’initialisations sont déjà executées par demarrer_site

La seule solution que j’ai donc trouvé pour appliquer des options
globalement à mes sites est donc de faire une fonction
avant_initialisation. Ça ne casse rien, ça ne réduit même pas la
comptabilité PHP si on ne la définit pas, et surtout ça permet donc de
définir globalement des options pour tous ses sites.

Alors après l’exemple de l’include du squelettes/mes_options a peut-être
induit en erreur Jacques, mais après tout un fichier
config/mes_options.php c’est… un fichier PHP. Donc libre à moi de
faire un simple include, si je veux inclure mes options dans mon dossier
squelettes/ qui lui seul est versionné.
Peut-être que ça serait plus clair avec un fichier nommé :
mutualisation_options.php
le mes_options.php contraire à la doc de SPIP m’a vraiment choqué.

Les options globales sont (encore une fois) un exemple qui montre dans quel contexte j’étais.

Un autre exemple est par exemple où tu autorises tes utilisateurs mutualisés à personnaliser leur dossier squelettes/ seulement, mais pas l’accès au dossier config. Dans ce cas là, pour leur permettre de définir leurs variables de personnalisation, tu peux faire un simple include_once _DIR_SITE.'squelettes/mes_options.php’; qui leur permettra d’avoir leur fichier mes_options.php à disposition.

Après tout, le fichier mes_options.php est un fichier PHP comme je le disais. Tu peux très bien avoir un eval(file_get_contents(‘http://je-suis-suicidaire.com/mes_options.php.txt’)), tu as tout autant le droit de le faire. Alors je ne vois pas ce qui m’interdirait de faire depuis ce fichier, un include d’un autre fichier.

Du coup, je ne comprends vraiment pas le revert. Faute d’explications du
pourquoi ça n’a pas sa place, je rereverterai dans l’après-midi. Puis
comme dit Marcimat : [c’est] juste un point d’entrée pour faire des
choses, et ça ne [gêne] rien
Alors, dans ce cas-là, oui, ça me semble correct de refaire ton commit,
(avec un autre nom pour le fichier d’options ?) et une doc plus
explicite comme tu viens de le faire dans ton mail.
Et une mise à jour de la doc ici pour ne pas perdre la procédure :
https://contrib.spip.net/La-mutualisation-facile-modifications-manuelles

Non, car c’est juste le deuxième exemple de ce que je montre qui pourrait être fait avant_initialisation (d’où le nom de mon entrée dans le tableau). Il y en a d’autres. Donc mon commit est bien ok, il faut juste se rappeler que la dernière phrase du log commence par « Par exemple »

Mais effectivement, je vais documenter cette option avec un ou deux exemples dans l’article de SPIP-Contrib.

Yohann

RealET · Décembre 19, 2016, 4:27

Yohann Prigent a écrit le 19/12/2016 à 16:11 :

Mais effectivement, je vais documenter cette option avec un ou deux
exemples dans l’article de SPIP-Contrib.

Merci.

En revoyant tes commits, je me souviens maintenant aussi de ce qui avait été déplaisant (et l'est donc toujours) : ton commit contient :
- une mise à jour du formatage
- ET une mise à jour du code

Mais la mise à jour du formatage rend le diff illisible

Tant pis.

--
RealEt

Yohann_Prigent · Décembre 19, 2016, 7:59

Oui, la mise à jour du formatage m’a bien énervé aussi et pourtant, la première fois j’avais svn up avant… j’ai pas trop cherché ce qu’il s’est passé…

Mais sinon le diff exact est en PJ.

Yohann

From: RealET real3t@gmail.com
Reply: RealET real3t@gmail.com
Date: 19 December 2016 at 20:55:54
To: spip-zone@rezo.net spip-zone@rezo.net
Subject: Re: [SPIP Zone] r100791 - plugins/mutualisation/trunk

Yohann Prigent a écrit le 19/12/2016 à 16:11 :

Mais effectivement, je vais documenter cette option avec un ou deux
exemples dans l’article de SPIP-Contrib.
Merci.

En revoyant tes commits, je me souviens maintenant aussi de ce qui avait
été déplaisant (et l’est donc toujours) : ton commit contient :

une mise à jour du formatage

ET une mise à jour du code

Mais la mise à jour du formatage rend le diff illisible

Tant pis.

–
RealEt

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

changeset_100791.diff (2.16 KB)