SPIP Blog

Du logiciel libre et de la tendresse

Accueil > Développement > Évolutions de la gestion des thèmes sous SPIP 3

Évolutions de la gestion des thèmes sous SPIP 3

mercredi 31 octobre 2012, par _Eric_, Joseph

La gestion des thèmes dans SPIP a connu de multiples évolutions. La situation actuelle n’est pas satisfaisante, avec deux logiques différentes qui coexistent (SVP et Zen-Garden). Nous tentons ici de poser les bases d’une discussion sur les évolutions possibles de la gestion des thèmes sous SPIP 3.

Historique

Au cours des dernières années, plusieurs approches de gestion des thèmes / habillages ont été proposées. On pourra se référer par exemple au plugin Habillages ou à Sktheme (tous deux développés pour SPIP 1.9.2).

Le projet Zpip développé à partir de 2009 pour SPIP 2.0 et supérieur a apporté entre autres :

  • un mécanisme de génération des pages HTML organisés en blocs (contenu, navigation, extra...) ;
  • une convention de nommage (ou nomenclature Z) des classes CSS utilisées par un squelette.

Plus précisément, dans le contexte Zpip 1, le squelette Zpip-dist fournit à la fois le moteur de génération des pages et un contenu HTML des blocs de page suivant cette nomenclature Z.

Est alors délégué à un thème Z de fixer le layout de la page, c’est-à-dire l’organisation des blocs dans la page (mais pas leur contenu) et de fournir un habillage CSS correspondant à la nomenclature Z.

Cette notion de nomenclature est importante car elle définit un formalisme permettant d’avoir plusieurs variations de squelettes et plusieurs habillages différents pouvant fonctionner ensemble.

Les thèmes Z se présentent sous la forme d’un plugin (voir Écrire un thème pour Zpip) avec cependant quelques éléments qui diffèrent par rapport aux autres plugins :

  • Historiquement, tous les thèmes avait le même préfixe theme afin d’assurer qu’un seul thème puisse être activé à la fois.
  • Un thème peut soit être installé dans le répertoire plugins/ et être activé classiquement, soit être installé dans un répertoire themes/ pour être activé via Zen-garden un gestionnaire de thèmes.
  • Un thème ne peut pas définir de dépendances ou user des pipelines car s’il est activé via Zen-Garden, ces dépendances et pipelines ne seront pas prises en compte. En effet, Zen-Garden n’active pas un thème (au sens de l’activation d’un plugin) mais ajoute simplement le répertoire du plugin dans la liste des chemins.

Zen-Garden a évolué pour pouvoir gérer également les thèmes d’autres squelettes. C’est le cas notamment des thèmes pour Sarka-SPIP. Zen-Garden filtre la liste des thèmes proposées à l’utilisateur en se basant sur la balise utilise du fichier plugin.xml des thèmes disponibles localement sur un site. Ainsi, si Zpip est actif sur le site, Zen-Garden n’affichera que les thèmes ayant <utilise id="Z" /> dans leur fichier plugin.xml.

En mai 2011, et suite à la réflexion menée sur le concept de paquets et de plugins, les thèmes disposent dorénavant de leur propre préfixe (un préfixe différent par thème). Cela permet de gérer correctement le numéro de version de chaque thème et leur gestion, notamment par SVP. Par ailleurs, les thèmes deviennent identifiés via une catégorie de plugins spécifique (la catégorie thèmes).

À partir de septembre 2011 (voir commit 51365), Zen-Garden prends en compte à la fois les thèmes installés dans le répertoire themes/ et ceux installés dans plugins/. De plus, Zen-Garden masque dorénavant les thèmes dans la liste des plugins (exec=admin_plugin) dans l’interface privée de SPIP (voir commit 51644).

Situation actuelle et limites

SPIP 3 embarque SVP, un nouveau système de gestion des plugins/paquets permettant notamment de télécharger facilement un paquet, de gérer les mises à jour et de prendre en compte les dépendances.

Site utilisant SVP sans Zen-Garden

Sur un site utilisant seulement SVP sans Zen-Garden, l’installation d’un thème doit se faire au même titre que les autres plugins. Autrement dit, le thème doit être installé dans le répertoire plugins/. Il revient cependant à l’utilisateur d’être vigilant à n’activer qu’un seul thème à la fois, SVP permettant actuellement d’activer plusieurs thèmes à la fois. De plus, c’est à l’utilisateur de s’assurer que le thème activé correspond bien au squelette qu’il utilise. Il n’y a pas d’information spécifique (excepté peut-être dans le descriptif du plugin) indiquant s’il s’agit d’un thème pour Zpip 1, Zpip 2 ou Sarka-SPIP (ou autre...).

Site utilisant SVP et Zen-Garden

Lors de l’utilisation conjointe de SVP et de Zen-Garden, l’utilisateur doit être vigilant à ne pas activé un seul thème dans SVP dans la mesure où Zen-Garden utilise un autre système pour spécifier le thème à utiliser. Zen-Garden ne procède à aucune vérification quant à l’activation éventuelle (au sens d’activation d’un plugin SPIP) d’un plugin de thème. Dès lors, si un thème est déjà activé dans SVP, il peut arriver que le choix effectué dans Zen-Garden reste sans effet si le thème activé dans SVP est prioritaire sur Zen-Garden.

À l’heure actuelle, sous SPIP 3, ni la gestion des thèmes via SVP ni celle via Zen-Garden n’est satisfaisante.

Réintégrer complètement les thèmes dans la logique plugins

L’adoption d’un préfixe unique pour chaque thème a été une première étape vers une gestion des thèmes comme des plugins à part entière. Cependant, les thèmes ont toujours certaines contraintes dérogatoires par rapport aux autres plugins, notamment le fait qu’ils ne peuvent utiliser les pipelines ou déclarer d’autres dépendances. Cela empêche par exemple un thème de pouvoir disposer d’un formulaire de configuration. Cela était voulu en 2009 (voir Écrire un thème pour Zpip). Il était cependant envisagé que : La notion de variante pourra être intégrée au Zen Garden dans le futur, pour en simplifier la gestion pour les développeurs et leur éviter de dupliquer une partie des images et des css. Cette notion de variante n’a pour l’heure jamais été formalisée ni implémentée.

L’absence de dépendance oblige un plugin de thème d’embarquer tous les éléments qu’il utilise, ce qui va à l’encontre de la logique actuelle visant à découper en plusieurs plugins chaque fonctionnalité. Or, un plugin de thèmes peut dès lors utiliser des librairies ou des outils distribués par d’autres plugins (par exemple Less CSS ou bootstrap). D’ailleurs, certains thèmes déclarent déjà des dépendances comme Arclite Brun.

Actuellement, on se retrouve avec deux fonctionnements différents :

  • une activation avec SVP va correctement vérifier les dépendances mais également les compatibilités ;
  • sous Zen Garden, les dépendances et compatibilité ne seront pas vérifiées et les fonctionnalités additionnelles ne seront pas prises en compte.

Implications pour Zen-Garden :

Une solution serait de faire évoluer Zen-Garden pour que ce dernier utilise l’API fournie par SVP afin d’activer proprement le thème utilisé. L’ensemble des dépendances seront ainsi correctement vérifiées et prise en compte. Par ailleurs, le réglage du thème actif sera maintenu même si Zen-Garden est par la suite désactivé.

Unicité du thème

Il importe qu’un seul thème soit actif à la fois. Ce que gère Zen-Garden mais pas SVP.

Implications pour SVP :

SVP pourrait évoluer pour n’activer qu’un seul thème à la fois, en se basant sur l’attribut categorie de paquet.xml.

Autrement dit, l’activation d’un thème doit provoquer la désactivation de l’autre thème déjà actif. De même, si l’activation simultanée de deux thèmes (ou plus) est demandée, un message d’avertissement doit être donné à l’utilisateur (car la situation est indéterminée). Enfin, lors du téléchargement simultané de plusieurs thèmes avec SVP, le téléchargement ne doit pas être suivie d’une activation puisqu’on ne peut savoir quel est le bon thème à activer.

Répertoire Thèmes

Une des conséquences d’une gestion des thèmes au même titre que les autres plugins est la disparation du répertoire themes/, tous les thèmes devant être alors installés dans plugins/.

Implications pour Zen-Garden :

Ne prendre en compte que le répertoire plugins/

Filtrage des thèmes

Une des problématiques de la gestion des thèmes est de gérer la « compatibilité » entre thème et squelette. En effet, cette compatibilité est dépendante de la nomenclature HTML/CSS ou convention de nommage des classes qui doit être commune entre le thème et le squelette.

Pour le moment, il n’y a pas de déclaration formelle de cette nomenclature. SVP ne procède à aucune vérification ni filtrage. Zen-Garden pour sa part filtre les thèmes disponibles pour n’afficher que les thèmes « compatibles » avec le squelette actif sur le site.

Actuellement, ce filtrage se fait de la manière suivante dans Zen-garden :

Zen-Garden gère donc nativement les thèmes Z. Pour les autres squelettes, ces derniers doivent déclarer dans un fichier d’options la constante _ZENGARDEN_FILTRE_THEMES qui doit correspondre au préfixe du squelette.

Une première limite est que la vérification est effectuée uniquement sur la balise utilise de plugin/xml/paquet.xml et ne prends pas en compte la balise necessite, ce qui ajoute une contrainte de rédaction aux plugins. Par exemple, le thème Brownie pour Zpip 2 n’est pas correctement filtré car il utilise un nécessite.

Par ailleurs, cela exclu la possibilité que deux squelettes différents (ayant donc deux préfixes différents) puissent utiliser une même nomenclature.

Par exemple, dans le cadre des évolutions du projet Z (qui sont en cours de développement et donc susceptible d’évoluer), Zpip v1 se retrouver scinder en deux, avec d’un côté Zcore qui implémente le moteur de génération des pages et Zpip-dist 2 de l’autre qui est un squelette Z utilisant Zcore et suivant une nomenclature donnée. Il est possible de réaliser un squelette proposant un autre contenu que Zpip-dist mais respectant la même nomenclature et donc pouvant utiliser les mêmes thèmes. La question est alors de savoir comment indiquer que ce squelette suit cette nomenclature donnée ?

Il me semble que trois approches peuvent être discutées.

1. Surcharger le squelette de base

Ce second squelette qui utiliserait la nomenclature de Zpip, doit nécessiter le squelette Zpip-dist et dès lors surcharger Zpip-dist pour effectuer ces propres modifications.

Cette approche a cependant plusieurs inconvénients, en particulier celui d’avoir à effectuer le cas échéant un « reset » du squelette surcharger. Par exemple, si ce second squelette n’utilise pas les brèves, il lui faudra surcharger les squelettes de brèves fournis par défaut. De même, cela impose d’avoir à suivre les mises à jour du squelette surchargé, en particulier quand ce dernier ajoute de nouveaux éléments [1].

2. Procurer le squelette de base

Une autre astuce consisterait à utiliser la balise procure dans le second squelette. Ce dernier déclarerait ainsi qu’il « procure Zpip » et définirait la constante _ZENGARDEN_FILTRE_THEMES comme étant égale à "Zpip".

3. Une déclaration formelle de la nomenclature utilisée dans paquet.xml

Les deux approches précédentes reposent sur l’utilisation des balises utilise, necessite ou procure de paquet.xml mais ne sont pas tout a fait sémantiquement exactes.

Il serait dès lors plus rigoureux d’étendre la DTD de paquet.xml en y ajoutant un attribut dédié, nomenclature ou convention ou type_theme (à discuter). Cet attribut permettrait de spécifier la nomenclature HTML/CSS utilisée par un thème ou par un squelette. Par exemple, les thèmes pour Zpip v1 pourraient indiquer nomenclature="zpip1", tandis que ceux pour Zpip v2 indiqueraient nomenclature="zpip2" et ceux pour Sarka-SPIP nomenclature="sarkaspip".

Cet attribut ne concernerait que les plugins de la catégorie themes et ceux de la catégorie squelettes.

La « compatibilité » (à défaut d’un meilleur terme dans l’immédiat) entre un squelette et un thème serait dès lors établie à partir de cette déclaration.

Par ailleurs, cette information pourrait également être utilisée sur http://plugins.spip.net pour afficher les squelettes compatibles avec un thème et les thèmes compatibles avec un squelette.

Éléments de discussion

Il importe de faire un choix quant à la meilleure façon de déclarer la nomenclature HTML/CSS utilisée par un squelette et par un thème. Les plugins SVP et Zen-garden (ainsi que http://plugins.spip.net) devant ensuite être mis à jour en conséquence.

Question de vocabulaires

Doit-on parler de thèmes « compatibles » avec un squelette, c’est-à-dire partageant une même nomenclature ou bien est-il préférable, pour éviter toute confusion, d’avoir recours à un autre terme. Si un autre terme est à privilégier, on pourrait alors parler de thème « conciliable » avec un squelette donné, ou à l’opposé de thème « inconciliable » si ce dernier utilise une autre nomenclature.

Quelle que soit la solution retenue, il importe de faire évoluer SVP afin de rendre compte de la compatibilité/conciliabilité entre un thème et un squelette.

Implications pour SVP :

Au même titre que les versions obsolètes ou incompatibles d’un paquet sont présentées en grisé, si un plugin de la catégorie squelette est actif et qu’il précise une nomenclature HTML/CSS, les plugins de thèmes ne suivant pas la même nomenclature HTML/CSS devraient être affichés en grisés avec un message indiquant qu’il ne sont pas compatibles/conciliables avec le squelette XXX actuellement actif sur le site. On doit pouvoir garder la possibilité de les supprimer et/ou de les mettre à jour.

De même, les résultats d’une recherche (dans le cadre de l’installation d’un plugin) doivent également présenter les thèmes incompatibles/inconciliables avec un message explicite.

Par ailleurs, l’option La version la plus récente doit tenir compte de cette compatibilité/conciliabilité et bien afficher pour les thèmes la version la plus récente du thème compatible/conciliable avec le squelette actif sur le site.

Calcul du chemin

Un thème a besoin d’être prioritaire vis-à-vis du squelette pour pouvoir, par exemple, surcharger une CSS par défaut qui serait fournie par le squelette.

Cette priorité est actuellement établie du fait de la balise utilise dans le paquet.xml du thème. Cependant, si la déclaration de la nomenclature devient possible dans paquet.xml et que dès lors deux squelettes différents (avec donc deux préfixes différents) peuvent partager une même nomenclature, il n’est pas forcément pertinent d’avoir à ajouter un utilise par squelette différent dans le paquet.xml de chaque thème.

Une solution simple consisterait à considérer que, par défaut et sauf mention contraire, un plugin de la catégorie ’theme’ est prioritaire sur un plugin de la catégorie ’squelette’.

Implications pour SPIP-core (ou SVP ?) :

Lors du calcul du chemin, et avant prise en compte des modifications induites par les necessite et les utilise, considérer que les plugins de la catégorie ’theme’ sont prioritaires sur ceux de la catégorie ’squelette’.

Thèmes de l’espace privé

J’ai identifié deux plugins classés dans la catégorie ’theme’ mais portant sur une personnalisation de l’espace privé :

Ces plugins intervenant dans l’espace privé ne sont pas concernés par la règle d’unicité du thème actif. Ces deux plugins pourraient tout à fait être classés dans la catégorie Configuration, maintenance, au même titre que les plugins Personnaliser l’espace privé et Thèmes pour l’interface privée.

Implications pour paquet.xml :

La catégorie “theme” devrait être précisée et réservée uniquement aux plugins de thèmes pour l’espace public à utiliser en conjonction avec un squelette.


Aujourd’hui, deux logiques différentes s’appliquent aux thèmes. D’un côté, SVP gère les thèmes comme des plugins à part entière mais ne prends pas en compte leur spécificité (unicité du thème actif et compatibilité/conciliabilité avec un squelette donné). De l’autre, Zen-Garden prends en compte cette spécificité mais gère les thèmes de manière dérogatoire, les thèmes n’étant pas activés au même titre que les autres plugins.

En terme d’évolution, il serait souhaitable que SVP et son API évoluent pour prendre en compte la spécificité des thèmes. Ces derniers doivent pouvoir être entièrement gérables uniquement via SVP.

Zen Garden, quant à lui, permet d’offrir une interface plus user-friendly pour gérer les thèmes, mais devraient reposer sur l’API de SVP pour leur activation. L’interface de Zen Garden pourrait également évoluer pour lister les thèmes compatibles disponibles au téléchargement et les installer en un clic. Enfin, les fonctionnalités telles que la prévisualisation d’un thème et le switcher de thème restent du ressort de Zen Garden.


[1Par exemple, si Zpip-dist fourni dans une mise à jour un squelette extra2/plan.html ce qui n’était pas le cas avant, le squelette surchargeant devra prendre en compte ce nouvel élément à surcharger.

Messages

  • Bonsoir,

    Tout d’abord merci de fournir ainsi un résumé complet sur le fonctionnement actuel des thèmes !

    J’ai par contre une remarque -pour lancer le débat- question préalable : il me semble un peu genant de vouloir « faire rentrer » les thèmes dans les plugins, au motif (si j’ai bien compris) que :
    - on utilise l’outil SVP une seule fois
    - il est le seul a gérer les dépendances !

    Mais au contraire des plugins, qui peuvent co-exister (en principe toujours ;-) et peuvent se « necessiter » ou s’« utiliser », les thèmes -par definition- sont tous mutuellement exclusifs (sauf quand on va introduire, sur le meme modèle ou un modèle analogue, des thèmes pour l’espace privé : j’ai déja reçu des demandes....

    Question : comment gèrera-t-on les dépendances et conflits entre thèmes privé et public ?

    D’où, il ne me parait pas pérenne de vouloir ré-intégrer les thèmes dans les plugins.
    Il me semblerait au contraire préférable de garder la distinction entre thèmes (privé versus public, qui plus est) et plugins traditionnels (et pas seulement pour que les newbies puissent s’y retrouver plus facilement, mais cela compte aussi ;-).

    Cette réaction est encore renforcée à la lecture des derniers paragraphes, qui pose comme postulat -pourquoi ?- que les thèmes privés n’auraient pas a etre concernés par la règle d’unicité ??
    Aujourd’hui peut-etre, mais il me semble que ce serait s’interdire la modification à terme de l’espace privé, comme on l’a pensé avec les bandeaux....

    Mais la nuit me portera conseil.....
    @+
    YannX

  • Bonjour,

    Tout d’abord, merci pour ce long article expliquant en détail le mécanisme des thèmes.

    Par la suite, je rejoins un peu YannX. Pourquoi mettre absolument les « thèmes » dans le répertoire « plugins » ?
    Si on regarde un peu du côté de Wordpress (oui oui), ils ont un répertoire « plugins » et un autre pour « themes » (entres autres). Et je pense que cette mécanique est très bien. Avec Spip actuellement, nous avons « plugins », « plugins-dist », « squelettes », « squelettes-dist » et « thèmes », sans oublier « prive ». Je trouve que cette mécanique, depuis la v2, est comprise par tout le monde (80% ou plus). L’utilisation d’un répertoire « thèmes » en découle pour ma part car « sémantique ».

    L’idéal, serait que Zen-Garden, pour simplifier l’idée, utilise les API de SVP pour vérifier les dépendances du thème. Un exemple : on peut créer un thème pour Z mais préférer l’utilisation du plugin « Comments 2 » que les forums par « défaut ».

    Pour les termes « conciliable » ou « inconciliable », je trouve que ces termes ne sont pas parlant, ils sont abscons… (chanson du développeur, quand tu nous tiens).

    Si j’ai bien compris, ces termes seraient à utiliser en plus du terme « nomenclature », c’est ça ?
    Si oui, alors, ce n’est pas au thème de dire qu’il est compatible avec tel ou tel squelette. Mais plutôt au squelette de dire qu’il est de telle ou telle nomenclature.
    On peut tout à fait créer un jeu de squelette basé sur la nomenclature « zpip-2 ».
    Il m’est déjà arrivé de créer des squelettes basés sur « Z » (comme beaucoup).

    Il faudrait que vous éclaircissiez votre pensée sur l’utilisation des termes « conciliable » et « nomenclature ». Est-ce qu’ils seraient utilisés tous les 2 ? Ou est-ce qu’on doit choisir l’un ou l’autre pour implémentation dans la nouvelle dtd ?

    Amicalement,
    Ybbet

  • Petite précision concernant les thèmes de l’interface privée : ces derniers relèvent d’une toute autre logique. C’est un ensemble d’éléments livrés dans un répertoire prive/themes/nom_du_theme. Plusieurs thèmes peuvent être physiquement présents. Le changement de thème se fait par une option dans un fichier d’options ou, à terme peut-être, via le formulaire Mes préférences. Quoiqu’il en soit, il s’agit d’une toute autre logique. La présente discussion porte sur les thèmes de l’espace public qui s’utilisent en conjonction avec un squelette.

    Concernant la proposition d’une déclaration formelle d’une nomenclature via un paramètre dédié dans paquet.xml, ce paramètre serait utilisé à la fois par un plugin de squelette (pour dire moi squelette j’utilise la nomenclature XYZ dans mes pages) et par un plugin de thèmes (pour dire, moi thème je fourni une stylisation CSS qui respecte la nomenclature XYZ).

    La terminologie conciliable/compatible (ou meilleur terme à trouver) vise donc simplement à dire si un plugin de squelettes S et un plugin thème T partagent ou non la même nomenclature.

  • YannX, Ybbet,

    Je crois qu’il y a toujours à la base une incompréhension sur le terme « plugin ». Le plugin c’est avant tout un mécanisme de distribution dont l’élément pivot est sa description XML. Autorité, Zpip ou Brownie sont respectivement une fonctionnalité, un squelette et un thème distribués en plugin.

    A partir de là, les thèmes étant distribués en plugin, je pense qu’il faut utiliser l’API des plugins portée en SPIP 3 par SVP pour installer les thèmes et pas avoir une méthode dérogatoire pour le faire.

    Ensuite, ça fait un certain temps que l’on discute de supprimer les différents dossiers incluant des plugins et de gérer les différences de comportement via l’interface d’admin. Je ne suis pas sur comme vous que plugins/ plugin-dist/, themes/ voire squelettes/ soient si parlants pour tous les webmestres ! D’ailleurs aujourd’hui avec SVP on distingue les plugins verrouillés et non verrouillés et rien ne présume de leur emplacement exact. Donc supprimer themes/ est pour moi une première étape de simplification au contraire.

    Voilà pourquoi je préconiserais que Zen Garden soit une interface de gestion des thèmes « au sens graphique » qui s’appuie sur SVP pour la partie installation.

  • Bonjour,

    Sans relancer la « polémique » (dév.-users), je relève le « critère d’unicité » pour les thèmes, en rajoutant a la documentation,
    - dans le carnet- http://contrib.spip.net/Doc-SPIP3-theme-prive.

    A suivre

  • YannX,

    Je comprends pas ton intervention. De quelle soit-disant polémique parles-tu ? Qu’as-tu rajouté à la documentation dont tu parles ?

  • Hello.

    Je pense qu’il est important d’être d’accord sur ce qu’on entend par « thème » : pour moi, c’est un « habillage graphique » (donc des « CSStyles » essentiellement). De la définition commune qu’on adoptera vont découler un certain nombre de contraintes, mais orienter aussi les réflexions quant à la gestion des thèmes. Ainsi, avec ma définition sommaire : Un thème se base sur une « structure ou charpente » (basiquement parlant, les CSS définissent des valeurs de propriétés pour des balises globalement ou spécifiquement) et donc s’appuie sur un « squelette » en plugin ou pas... De plus un thème peut être distribué (comme un plugin) ou pas (et de ce fait ne sont pas obligés d’être en plugin à mon avis).
    Par ailleurs, quand je regarde chez les concurrents, je suis renforcé dans l’idée que Zen-Garden doit garder les répertoires /themes/ et /squelettes/themes/.
    Chez D* il y a un répertoire dédié .../themes/.
    Chez J* il y a un répertoire dédié /templates/ (distinct de /plugins/).
    Chez W* il y a un répertoire /wp-contents/themes/ (distinct de /wp-contents/plugins/).
    Ainsi de suite, et ce distingo ne semble pas être remis en cause par les retours d’expériences. En fait, du point de vue SPIP, je comprends la simplicité mais je dis juste : « attention à ne pas compliquer la vie du webmestre ni la courbe d’apprentissage »

    Zen-Garden est dans la lignée de Habillage et Sktheme/Squelette switcher en allant plus loin... Trop souvent on associe Zen-Garder avec Z-core / Z-dist (même ici, à première vue, c’est hélas l’impression que j’ai)  :-S Or si on est d’accord qu’il va plus loin en s’appuyant sur SVP pour la diffusion (des thèmes par plugin), je pense que le jardin peut être plus zen s’il s’agit aussi d’une interface (i.e. API) entre les thèmes en eux-mêmes et la structure associée (ou plus précisément la convention de nommage utilisée) : ainsi, on peut avoir des thèmes Z ou Sarka ou Eva ou ACS etc. En fait, en y réfléchissant (j’avais commencé à répondre hors-ligne puis j’ai dû m’absenter ce qui a fait mûrir ma réponse entre-temps) cela se fait toujours via SVP : en vérifiant les pré-requis via necessite (et non utilise) on ne téléchargera (ou verra même) pas les thèmes dont le/la squelette/nomenclature n’est pas présente (ou installée) ! Et quand rien n’est spécifié, c’est que c’est un thème directement applicable à « squelettes-dist » ! (il n’y a pas que don Diego qui soit habillé)
    L’usage du necessite me parait plus indiqué dans la logique actuelle de plugins même si certains objecterons qu’un thème bah... C’est oublier la notion de nomenclature qui peut être un peu plus poussée en terme de personnalisation ciblée : on pourrait très bien avoir des thèmes pour Comments par exemple :o)
    Les thèmes étant quelque chose de spécifique, SVP devrait à mon avis les traiter de façon prticulière en ne les activant pas ...mais uniquement quand Zen-Garden est présent... Bien que je n’aime pas trop les exceptions / dérogations, cela gagnerait en simplicité pour les utilisateurs (mais complexifie un peu le code sous-jacent) De la même façon, en présence d’un gestionnaire de thèmes (ici Zen-Garden uniquement pour l’instant ?), SVP devrait désactiver la recherche et installation de thèmes (donc cela se fait à travers ZG..? à l’instar de ce qui se fait sous GNU/Linux où les thèmes ne sont pas géré par les gestionnaires de paquets systèmes) ou ne proposer que ceux dont les dépendances sont satisfaites (mauvaise solution car allant totalemnet à l’encontre du fonctionnement normal vu qu’il impose d’installer les dépendances nécessaires)

    Mes deux sous.

  • Belle synthèse de la problématique.

    Cependant à l’utilisation, je remarque qu’on à tendance à intégrer les frameworks css aux thèmes, ce qui pour moi est un non-sens.

    Le framework css devrait être un plugin, le thème utilisant le framework.

    Actuellement ce n’est pas le cas : si on regarde blueprint pour Z1, le thème intègre le framewok et oblige donc a surcharger par un second thème le premier, ou a modifier le plugin existant à chaque projet : ce qui rend l’utilisation d’un framework moins intéressante. Dans ce cas on se retrouve avec un skel Zdist, un thème css framework + un thème surcharge.

    J’utilise donc une autre approche (qui n’est peut être pas la bonne ou la meilleur), mais je crée un plugin pour le framework css qui peut donc être appelé soit par un thème Z soit par un squelette sur mesure dédié a un projet. Ceci me permet de faire évoluer, ou de traiter certaines compatibilités navigateur pour tous les projets partageant le plugin framework css, ou de rajouter des classes utiles à tous.

    Dans cette logique, il y a donc trois entités et non deux :
    - Squelette : Z ou autre
    - le framework css Pluginisé et pourquoi pas paramétrable
    - le thème : réduit a sa simple expression de surcharge/utilisation css

    En fait actuellement j’ai l’impression que ça fait comme si on embarquait la même classe PHP dans tous les plugins : ce qui ferait hurler tous les developpeurs php de la zone ;-).

    Autre problématique déjà abordée dans les précédents post qui concerne les thèmes et la partie graphique du site :
    Les noisettes et modèles deviennent un grand classique de tous les plugins spip, cependant ils doivent êtres « thémés » eux aussi : il devient donc alors difficile de faire du générique. La logique Spipienne actuelle voulant que les plugins n’embarque pas de stylisation : elle doit être déléguée au Thème, ce qui implique de prévoir dans chaque thème tous les modèles et noisettes qu’il pourra ou va utiliser, mais sans savoir avec quel squelette.

    Dans ma logique (toujours peut être pas la meilleur ...), j’utilise un autre type de plugin que j’appellerais « composants graphiques » et qui me sert de lien entre les squelettes, les noisettes/modèles, le thème : une sorte de collection de micro-thèmes et qui n’active les css et personnalisations que si le plugin est activé. En exemple : la stylisation d’un minical est un composant graphique qui peut être partagé entre tous les squelettes utilisant le minical, seul le sprite change et est appelé dans le thème par une surcharge.

    Voila en gros mes réflexions sur le sujet pour le site publique, et sa partie graphique.

    Pour l’espace privé, ayant bidouillé (je n’oserais pas employer le mot développer ^^) le plugin mes_preferences pour mon utilisation : j’ai tenté de répondre a une problématique simple :

    - le thème privé est une GLOBALE ce qui entends que on l’impose à tous le monde du coup.

    Tout simplement Mes Préférences permet à l’utilisateur de choisir son interface en allant dans son panel de préférences.

    On peut donc choisir outre les thèmes par exemple un troisième mode qui s’adapte à la largeur max de l’écran, mais j’avais pas mal d’autres idées d’options a rajouter, comme une option taille de police (utile pour les rédacteurs aux yeux fatigués ;-) ), des modes a fort contraste (surtout des préférences d’accessibilité) ... Dans le concept j’aurais bien vu aussi des plugins insérer des préférences utilisateurs indépendamment des metas de configuration : par exemples les boutons ou le type de barre d’administration, le type de barre typo que le rédacteur utilise suivant ses préférences ... bref des options qui méritent d’êtres laissées à chacun plutôt que globalement comme c’est fait actuellement.

    Bref je manque pas d’idées sur le sujet : mais plutôt de temps et de compétences (les deux étant intiment liés car les compétences s’acquiert avec le temps ^^).

    A++
    Arnaud B. (Mist. GraphX)

  • Oh, excellentes remarques de gilcot et Mist. GraphX, merci !

    Oui, attention à d’abord bien définir ce qu’est un « thème » — oui, comme par ailleurs, c’est juste un « habillage graphique », donc CSS/JS/IMG, oui, ça se range dans /squelettes/theme, etc. — et bien distinguer d’un « thème Z » qui est quelque chose de spécial, propre à SPIP, et qui suit une logique de templating — c’est-à-dire de génération des squelettes et leur HTML — qui reste particulière au sein de SPIP.

    Pour rester accessible, la création des thèmes (CSS/JS/IMG) peut et doit être dissociée de Z, et même de SPIP. C’était d’ailleurs un de mes axes de travail, ces dernières années, dans SPIP. Commencer par réfléchir, déterminer la base, le « par défaut » — quelle structure HTML standard ? quelle nomenclature ? quel cadre de travail (framework) ? etc. — avant d’organiser l’industrialisation (distribution de thèmes, scaffolding, etc.)…

  • Hello, je suis tout nouveau dans SPIP et j’avoue qu’au début je me perdais largement entre les squelettes, ZenGarden et le rendu CSS.
    Pour simplifier et pour mieux organiser mon travail, j’ai fait un plugins incluant tout mon spécifique « site » dedans à savoir :
    - Les squelettes
    - Les images
    - Les css public
    - Les css privés

    Je trouve qu’au final les squelettes et le rendu visuel sont assez liés (sauf si on veut faire un plugin générique). A partir de là ça ne m’a pas choqué d’avoir un plugin ayant tout ces composants...
    Je sais pas du tout si c’est la bonne solution mais au moins c’est plus simple à gérer de mon point de vue...

  • Bonjour,

    Je développe moi même mes squelettes et j’avoue n’avoir jamais vraiment tenté d’utiliser les thèmes ou autre.
    D’autant que je ne sais pas pourquoi, mais cela donne une impression complexe.
    Pour simplifier les choses, il serait à mon avis utile de préciser à droite à gauche pour les débutants. Que dans spip le Sqquelette revient à l’habillage du site. Quant aux thèmes il devrait plutôt être classé dans spip-contrib et plugin-spip comme une sous-rubrique des squelettes.

    Cela rendrait les choses déjà plus claires, car là on nage un peu si on est débutant.

    Installez simplement un thème, vous n’obtiendrez rien ; tandis qu’installez simplement un squelette vous aurez déjà un résultat.
    Lorsqu’on cherche comment donner une jolie apparence à son site, et qu’on est débutant SPIP, on vas immédiatement être attirer par le mot thème, et pas par squelette.
    Ce qui est dommage.

  • D’accord avec Casp. Il n’y a pas deux conceptions il n’y en a qu’une seule. A la base de tout il y a le squelette (Ce qu’il faut afficher et le style demandé). Le thème c’est de prendre un squelette réutilisable avec des alternatives graphiques différentes. J’espère que les différents systèmes de thèmes vont converger pour qu’une logique de thèmes soit documentée de manière à ce que l’utilisateur saisisse le fonctionnement des squelettes et des thèmes.

  • Quelques points de précision.

    Dans SPIP, on peut avoir son propre squelette incluant à la fois le HTML, les CSS, les habillages graphiques, etc., le tout rangé dans le répertoire squelettes qui est le répertoire des personnalisations propres à un site. Ce type de squelette n’est pas concerné par le présent article.

    Il y a ensuite les squelettes qui sont distribués sous formes de plugins, afin de pouvoir être facilement téléchargés et installés sur un site.

    Certains plugins de squelettes contiennent tous leurs éléments de variations graphiques, éventuellement configurables. Voir par exemple les squelettes SoyezCréateurs ou Multiflex. Ces derniers ne sont pas concernés par la présente discussion dans la mesure où ils n’ont pas recours à des plugins de thèmes, embarquant tous les éléments de variations graphiques qui les concernent au sein du plugin de squelette.

    Enfin, il y a un troisième cas de figure qui sont les squelettes distribués sous formes de plugin (un plugin de squelette donc) et qui proposent des variations graphiques sous forme de plugins additionnels, c’est-à-dire des plugins de thèmes. C’est précisément ce cas de figure qui est discuté ici. On peut cité en exemple le squelette Zpip ou encore Sarka Spip.

    Ce type de situation n’est donc pas, comme on a pu le lire dans certains commentaires, spécifiques à Zpip même si Zpip a peut être formalisé un peu plus cette distinction entre plugin de squelettes complété par un plugin de thème.

    En réponse à Gilcot, un plugin de thème repose bien sur un plugin de squelettes, puisqu’il est nécessaire de disposer d’un même nommage des classes CSS entre le squelette et le thème. C’est ce qui est évoqué dans cette article sous la notion de nomenclature CSS/HTML. Une des problématiques est justement de formaliser cette notion de nomenclature et de pouvoir la déclarer spécifiquement.

    A Romy, cela permettrait également de généraliser plus facilement le système, le squelette de la dist pouvant dès lors déclarer aussi sa propre nomenclature et des thèmes pour le squelette dist pouvant alors être développé et distribué.

    L’ensemble de la discussion est ici générique concernant le cas de figure d’un plugin de thème s’articulant avec un plugin de squelettes et non spécifique aux thèmes Z. Certes les thèmes Z ont quelques spécifiques additionnelles, notamment car ils fournissent un squelette body.html (et simplement ce squelette), mais cela ne modifie en rien les éléments discutés ici. Et, en raison des spécificités propres à chaque squelette, les plugin de thèmes de chaque squelette peuvent avoir des conventions différentes à suivre. Ce qui est discuté ici c’est la question de la distribution des thèmes, de leur activation dans SPIP et des interfaces permettant de les gérer.

    Bien cordialement à tous

  • J’avoue que, j’ai beau relire, je ne comprends pas grand chose à ce que tu dis, Joseph… à part que c’est sacrément compliqué :(

    D’expérience, la distribution de thèmes n’est pas si complexe (et n’a pas de raison de l’être). Je ne vois pas pourquoi ça devrait être différent dans SPIP.

    D’après ce que je comprends le principal problème est le nom du répertoire « squelettes » qui induit en erreur, parce qu’il contient toutes les personnalistations, qui se font souvent sous forme de squelettes HTML mais aussi (et parfois seulement) de feuilles CSS, de fonctions PHP, de scripts JS, etc. et s’appliquent tant au site public qu’à l’espace privé ! Bref : toutes les personnalisations d’un site. Il devrait plutôt s’appeler « perso », comme je l’ai déjà abondamment suggéré.

    Le second problème semble être la confusion entre thèmes et plugins. Leur distribution devrait être séparée, effectivement.

    SPIP a fait le choix, fondamental, de ne pas imposer de structure et laisser chacun libre… d’adopter la nomenclature, le framework ou le thème de son choix. Certains plugins/squelettes, comme ceux que tu cites, Zpip ou Sarka, apportent leurs propres thèmes, etc. et parfois la mécanique d’affectation de thèmes, pour ceux qui ont ce besoin là. Par contre, SPIP est un système de publication, pas un gestionnaire de thèmes.

  • Merci à SPIP de laisser une très grande souplesse aux utilisateurs. Le but de la présente discussion ne vise nullement à dire que tous les squelettes et thèmes doivent suivre une même voie. On doit pouvoir toujours personnaliser à souhait son site via son répertoire squelettes (je suis d’accord avec toi que perso serait plus adapté). De même, il est toujours possible de livrer un squelette avec ses thèmes associés au sein d’un unique plugin.

    Le but de la réflexion ici porte bien sur le cas particulier des squelettes distribués sous forme de plugin (un plugin étant simplement un moyen de distribution sans présumer de la fonction) et qui distribuent des thèmes qui leur sont propres également sous forme de plugins (ce qui correspond actuellement effectivement à Zpip et Sarka-Spip). Il s’agit bien, pour ce dernier cas uniquement, de gérer une mécanique d’affectation et de gestion qui soit adéquate et compréhensible par l’utilisateur final.

  • je n’arrive pas à faire afficher les icônes (comme celles ci-dessus) de raccourci (bold, italic, etc...) pour modifier un texte et faire sa mise en page.
    Ces icônes apparaissent lorsque je travaille sur un autre ordinateur.
    Est-ce que cela vient de l’ordinateur ? Est-ce un bug de SPIP ?
    Merci

  • En retombant sur ce billet, je me rends compte que je n’ai pas pensé y lier cet article sur l’organisation des thèmes CSS, toujours d’actualité, surtout à l’approche de la sortie de SPIP 3.1, dont la dist est plus particulièrement thémable.

Un message, un commentaire ?

Qui êtes-vous ?
Se connecter
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.