[spip-dev] squelette et thème dans leur r épertoire

----Message d'origine----

Date: Tue, 9 Dec 2003 12:33:40 +0100
Sujet: Re: [spip-dev] squelette et thème dans leur r
A: Minh Ha Duong <haduong@centre-cired.fr>
De: Déesse A. <esj@vertsdesevres.net>
Copie à: spip-dev@rezo.net

Dites, vous trouvez pas que ça serait une bonne idée de mettre tous
les fichiers du squelette utilisés dans un répertoire, mettre
"squelette" tous les -dist dans un répertoire "squelette-dist". Et
puis tant qu'on y est de renommer IMG en "theme", y mettre les *.css
et de même distribuer un theme-dist ?

Oui, mais il faut voir à plus long terme. Spip grandit, ce qui veut
dire que l'espace disque
qui lui est nécessaire va devenir un problème. Il faut viser une
architecture où Spip serait
installable par l'hébergeur pour l'ensemble des abonnés (comme c'est le
cas pour SQL, PHP etc)
et non par chacun des abonnés, qui "dépensent" ainsi beaucoup de leur
espace disque

Permettre de mettre à coté, séparer de chaque site web, mettre en commun tout ecrire/ qui est commun ?
C'est pas bête, c'est même plutôt une bonne idée,
pour économiser de l'espace disque sur un serveur mutualisé spécialisé pour SPIP.
Dans le version 1.7b4, ecrire/ fait environ 9 Mo,
ecrire/aide/ et ecrire/lang/ font environ 8 Mo.

et plombent
les performances générales du serveur (s'il n'y avait qu'une seule
installation de Spip, le
système de fichiers aurait plus souvent les fichiers Spip en cache).

Pour y arriver, il faut donc arreter d'écrire dans les répertoires des
sources de Spip, afin
qu'aucun abonné n'impose aux autres ses squelettes, feuilles de style
et autres images.

??

C'est une des raisons pour lesquelles j'ai écrit une nouveau gérant de
cache qui utilise
le serveur SQL et plus le répertoire CACHE (je l'ai posté ici:
http://www.uzine.net/spip_contrib/ecrire/articles.php3?id_article=309
La solution la plus propre est en effet de ne plus écrire que dans le
serveur SQL,
ce qui veut dire prévoir autant de tables que de types de fichiers
actuels.

Le cache/ est entre autres utilisé en cas d'absence d'accès au serveur sql...

Une autre solution, certainement plus rapide à mettre en oeuvre, est
d'avoir un répertoire par
abonnné, où l'on mettrait tout ce qui lui est personnel (squelette etc)
et d'avoir un système de
hiérarchie pour aller taper dans le répertoire de distribution en cas
d'absence de ce qu'on
cherche dans le répertoire perso. Ca demande là aussi de préciser la
liste des types de fichiers.

Par contre je ne pense pas que le système que je décrit plus haut doive être intégré à SPIP. Cela devrait plutôt être une version spéciale; même si des modifications de la branche principale de SPIP pourraient être faites si nécessaires pour la création de cette version spéciale.

Nicolas Krebs écrivait:

Permettre de mettre à coté, séparer de chaque site web, mettre en commun tout ecrire/ qui est commun ?

C'est précisément ce que je recherche. J'ai déjà décrit ce que je souhaiterai voir implémenté dans les prochaines versions de SPIP.
En fait, je travaille chez un fournisseur de services Internet (un tout petit) et j'ai proposé de facilité l'installation de SPIP sur notre plateforme. Dans la discussion un de mes collègues m'a proposé d'utiliser la même instance de l'application pour tous les utilisateurs. Ils nous faut donc séparer strictement l'application des templates, du cache et des images.

L'utilisation de variables d'environnement permettraient de cloisonner les utilisateurs et un serveur mysql spécifique à cet usage serait mis en place.

C'est pas bête, c'est même plutôt une bonne idée, pour économiser de l'espace disque sur un serveur mutualisé spécialisé pour SPIP. Dans le version 1.7b4, ecrire/ fait environ 9 Mo, ecrire/aide/ et ecrire/lang/ font environ 8 Mo.

C'est aussi une bonne idée pour faciliter l'installation, puisqu'une automatisation serait prévu.

J'ai pu voir que cette idée trottait, en partie, dans la tête des concepteurs puisque il y dans la faq :

un article qui comment faire pour utiliser les squelettes depuis un autre répertoire en initialisant une variable contenant le chemin.

Je vous encourage vivement à prévoir ceci et je suis sûr que les hébergeurs voudront proposer ce service supplémentaire pour leurs clients. D'autant que les autres gestionnaires de contenu mettent à bas nos serveurs, nous préférons de loin l'utilisation de SPIP et notamment sous cette forme.

Je précise ce qui a déclenché les ?? de Nicolas, savoir

Pour y arriver, il faut donc arreter d'écrire dans les répertoires des
sources de Spip, afin
qu'aucun abonné n'impose aux autres ses squelettes, feuilles de style
et autres images.

et je mets en garde nadjar autour de ça.

Le problème est qu'une squelette peut contenir du code PHP,
lequel peut faire n'importe quoi, y compris alétérer les
sources de Spip, les squelettes personnels etc.
Actuellement c'est la meme personne
qui installe les sources de Spip et les squelettes qui
les utilisent, donc il ne peut nuire qu'à lui-meme
(mais ça veut déjà dire qu'il a intérêt à inspecter
soigneusement un squelette qu'il va chercher sur le Web
avant de l'installer).

Mais si on veut partager les memes sources pour plusieurs utilisateurs,
il FAUT que celles-ci soit inaccessibles en écriture.
Un moyen sûr, et qui est d'ailleurs imposé par les
administrateurs de sites sensibles, est tout simplement
d'interdire TOUT accès en écriture à des fichiers par les scripts,
toute mémorisation devant se faire à travers le serveur de BD.

L'argument que cela ralentirait le système ne me parait pas
recevable, je m'en suis expliqué dans le forum de l'article 309.

      Emmanuel

[ISO-8859-1] Déesse A. écrivait:

et je mets en garde nadjar autour de ça.

Le problème est qu'une squelette peut contenir du code PHP,
lequel peut faire n'importe quoi, y compris alétérer les
sources de Spip, les squelettes personnels etc.
Actuellement c'est la meme personne
qui installe les sources de Spip et les squelettes qui
les utilisent, donc il ne peut nuire qu'à lui-meme
(mais ça veut déjà dire qu'il a intérêt à inspecter
soigneusement un squelette qu'il va chercher sur le Web
avant de l'installer).

Mais si on veut partager les memes sources pour plusieurs utilisateurs,
il FAUT que celles-ci soit inaccessibles en écriture.
Un moyen sûr, et qui est d'ailleurs imposé par les
administrateurs de sites sensibles, est tout simplement
d'interdire TOUT accès en écriture à des fichiers par les scripts,
toute mémorisation devant se faire à travers le serveur de BD.

L'argument que cela ralentirait le système ne me parait pas
recevable, je m'en suis expliqué dans le forum de l'article 309.

      Emmanuel

Merci pour la mise en garde mais nous avions pris en compte cette possibilité. Pour la sécurisation nous allons de toute façon faire différents tests.
Il a bien sûr un certain nombre d'aspects que nous devront résoudre de notre coté. Je pourrais tenir au courant la liste de l'évolution du projet si cela intéresse du monde.

Ce dont nous avons besoin c'est que les chemins utilisent des variables localisées à un endroit et que cela soit maintenu dans toutes les versions futures de SPIP afin que nous puissions opérer les mises à jour sans problèmes. Il faut intégrer à cela la connexion à la base de données.

Si une telle implémentation est effective et que les hébergeurs français, au moins, l'utilisent, SPIP serait propulsé vers une notoriété d'une autre dimension.

Les concepteurs passeront le reste de leur jour à améliorer et écrire des bouquins et signer des autographes :wink:

Maher

Si une telle implémentation est effective et que les hébergeurs français,
au moins, l'utilisent, SPIP serait propulsé vers une notoriété d'une autre
dimension.

On se fiche un peu de la notoriété, mais sachez qu'on a déjà proposé
plusieurs fois que des hébergeurs travaillent avec nous sur des
spécifications/améliorations visant à faire ce que tu décris, mais aussi
bien d'autres choses (mises à jour automatiques, par exemple, mais pas
uniquement).

Lors de la "journée spip" du 15 novembre, une réunion a d'ailleurs été
consacrée à ce thème. Donc, sur le principe, oui. Dans la pratique, il faut
voir comment ça se gère, et notamment garantir la facilité de mise à jour
pour les sites existants (pas question, selon moi, de maintenir une version
spéciale pour hébergeurs).

Les concepteurs passeront le reste de leur jour à améliorer et écrire des
bouquins et signer des autographes :wink:

Euh, c'est *ta* vision des choses !...

-- Fil

Fil écrivait:

Si une telle implémentation est effective et que les hébergeurs français, au moins, l'utilisent, SPIP serait propulsé vers une notoriété d'une autre dimension.

On se fiche un peu de la notoriété, mais sachez qu'on a déjà proposé
plusieurs fois que des hébergeurs travaillent avec nous sur des
spécifications/améliorations visant à faire ce que tu décris, mais aussi
bien d'autres choses (mises à jour automatiques, par exemple, mais pas
uniquement).

Lors de la "journée spip" du 15 novembre, une réunion a d'ailleurs été
consacrée à ce thème. Donc, sur le principe, oui. Dans la pratique, il faut
voir comment ça se gère, et notamment garantir la facilité de mise à jour
pour les sites existants (pas question, selon moi, de maintenir une version
spéciale pour hébergeurs).

Ca fait peu de temps que je connais SPIP, c'est pourquoi je n'étais pas au courant d'un tel projet, ni même de cette réunion, malgrès mes recherches dans les archives.

Ce que je proposais c'était juste de prévoir une variable pour les chemins d'accès aux répertoires des données, des templates... et par défaut de prendre le répertoire local. Je n'ai pas pensé à une version particulière ou à rajouter inutilement une charge de travail dans le développement de SPIP.

Dans la mesure où la charge de travail que nous avons le permet, je suis persuadé que l'on peut voir avec vous d'autres aspects de l'utilisation de SPIP.

Bien sûr ! Qui peut le plus peut le moins, voilà tout.
Il faut d'ailleurs noter qu'un unique installateur
peut avoir un intérêt d'un Spip avec plusieurs utilisateurs
MySQL: ça peut être un moyen de gérer des équipes de
rédacteurs séparées (demande fréquente) en syndiquant
les sites de manière croisée.

      Emmanuel

Ca fait peu de temps que je connais SPIP, c'est pourquoi je n'étais pas au
courant d'un tel projet, ni même de cette réunion, malgrès mes recherches
dans les archives.

Ce que je proposais c'était juste de prévoir une variable pour les chemins
d'accès aux répertoires des données, des templates... et par défaut de
prendre le répertoire local. Je n'ai pas pensé à une version particulière ou
à rajouter inutilement une charge de travail dans le développement de SPIP.

Dans la mesure où la charge de travail que nous avons le permet, je suis
persuadé que l'on peut voir avec vous d'autres aspects de l'utilisation de
SPIP.

S'il s'agit simplement de gagner de l'espace disque, tu peux déjà
utiliser des liens symboliques pour les répertoires ecrire/lang,
ecrire/AIDE et ecrire/img_pack. Cela représente la majeure partie des
fichiers SPIP (en méga-octets).

Pour mutualiser tous les fichiers SPIP de façon propre il faut
probablement mettre en place des rewrite-rule qui règlent une variable
d'environnement (si on peut appeler ça "propre"). En fonction de cette
variable d'environnement on fait un chdir vers le répertoire usager, et
on utilise le $PATH_TRANSLATED s'il existe pour accéder aux répertoires
lang et AIDE.

a+

Antoine.

Ce serait ennuyeux parce que l'installation de SPIP dépendrait alors
du serveur Web utilisé. Il me parait plus simple de prévoir qu'un hébégeur
voulant donner à un de ces abonnées un accès à SPIP placerait dans le
répertoire (ou un sous-repértoire) de celui-ci un fichier qui serait
le inc-connect actuel avec qq ajouts. Après on récupérerait l'URL
d'appel pour connaitre le répertoire perso.

      Emmanuel