En date de : Ven 19.6.09, damazone <damazone72-spip@yahoo.fr> a écrit :
Pour moi, il y a aussi un débat de fond sousjacent. En
effet, pour faciliter l'utilisation des squelettes, on
les transforme en plugin pour pouvoir les installer
facilement par l'outil de configuration de spip.
La notion de plugin et de squelette est pour moi de moins
en moins claire si ne n'est qu'il y a une contrainte
technique qui fait que l'un (squelette du dossier
squelettes) prime sur l'autre (plugin) mais c'est
encore un autre débat.
Un squelette en plugin permet une installation "simplifiée" par l'admin d'un site vu qu'il n'a pas à utiliser FTP pour uploader les fichiers dans le dossier /squelettes mais simplement à l'activer dans son interface de gestion des plugins après l'avoir téléchargé via l'outil d'installation automatique des plugins
Une fois activé un autre avantage du squelette en plugin est qu'il est possible de le "personnaliser" (comprendre bidouiller son code pour le modifier un peu ou beaucoup...) en faisant simplement une copie des fichiers à modifier depuis le répertoire du plugin vers le répertoire /squelettes: on bénéficie donc de la possibilité de "surcharge" du squelette exactement comme avec la dist (miam!)
Dans le cadre d'une mutualisation SPIP cela permet d'avoir un répertoire /plugins centralisé dans lequel sont installés un ensemble de squelettes-plugins parmi lesquels l'admin d'un site mutu peut choisir celui qu'il veut utiliser pour son site *et* qu'il puisse ensuite faire ses propres personnalisations dans le /squelettes de son instance de mutu => un plugin / n déclinaisons.
Dans ce cadre là, le squelette en plugin est donc plus pratique que le squelette "classique" (a tel point que j'ai pluginisé le squelette "chez nous" pour qu'il soit disponible comme les sarka, egt ou autres tma pour les utilisateurs de ma mutu...)
En revanche, pour aller un peu plus loin, 2 points restent complexes / lourds:
- de nombreux squelettes-plugins ne sont pas compatibles entre eux (normal: ils fournissent des fichiers ayant même nom puisque faisant la même chose par ex article.html, sommaire.html...) mais rien n'empêche un admin de valider *plusieurs* squelettes-plugins en simultané (bonjour le b***!)... là on touche un peu la limite du fait d'utiliser le mécanisme des plugins pour gérer le squelette...(ok, c'est mineur comme problème: l'admin n'a qu'a être attentif!)
- une fois que l'on a choisit un squelette en plugin et que l'on a commencé à le personnaliser via une surcharge de ses fichiers dans /squelettes, le changement de squelette par simple "coche/décoche" dans l'interface d'admin des plugins ne devient plus vraiment possible.
En effet, si je surcharge le fichier article.html du squelette X et que je décide d'essayer le squelette Y, pour la page article l'affichage sera toujours celui du squelette X puisque le fichier est dans /squelettes donc prioritaire...
Du coup, un contournement possible est de faire
- un dossier /squelettes/X dans lequel sont placés les fichiers de surcharge du squelette-plugin X
- un dossier /squelettes/Y avec les fichiers de surcharge du squelette Y
- lorsque l'on veut passer de X à Y, en plus d'activer Y / désactiver X dans l'interface de gestion des plugins, il faut modifier le mes_options.php du site:
$GLOBALS['dossier_squelettes'] .= ':squelettes/X';
sera remplacé par
$GLOBALS['dossier_squelettes'] .= ':squelettes/Y';
ce qui permet de switcher entre les 2 squelettes *avec* leurs personnalisations 
...mais nécessite une intervention manuelle sur le fichier mes_options.php 
(du coup l'admin du site doit avoir le droit d'écriture et savoir ce qu'il faut modifier comme fichier pour gérer le changement de squelette...)
Pour éviter cette manipulation du mes_options, la soluce suivante est possible (et c'est celle que j'utilise pour les squelettes-plugins dans ma mutu): dans chaque plugin-squelette ajouter/modifier le fichier d'options (celui appelé dans plugin.xml par <options>X_options.php</options>) pour qu'il contienne la définition du sous-dossier de /squelettes correspondant:
$GLOBALS['dossier_squelettes'] .= ':squelettes/X';
ou
$GLOBALS['dossier_squelettes'] .= ':squelettes/Y';
Du coup, lorsque le squel X est actif, le dossier /squelettes/X est pris dans le find_in_path alors que lorsque c'est le squlettte Y qui est actif, c'est /squelette/Y qui est scanné
...et pour ceux qui ont une mutu, vu que le chemin de dossier de squelettes de la mutu d'un site n'est pas /squelettes mais un truc du style sites/X/squelettes, on peut faire qq chose comme:
$chem_squel = 'squelettes';
if ($Tsquel = explode(":",$GLOBALS['dossier_squelettes'])) $chem_squel = $Tsquel[0];
$GLOBALS['dossier_squelettes'] .= ':'.$chem_squel.'/X';
Vu que ce système reste quand même un peu bidouilleux et nécessite de modifier tous les squelettes-plugins pour leur ajouter cette option, la question est:
"dis m'sieur le core-dev, tu aurais pas une piste pour automatiser la surcharge des squelettes-plugins plus facilement?"
à bientôt