Écrire un thème pour Zpip

Le squelette Zpip inaugure une convention et un formalisme visant à promouvoir et faciliter l’échange de code et des habillages entre squelettes.

On décrit ici l’organisation macroscopique à respecter pour écrire un thème compatible avec le squelette Zpip (et les autres qui respectent le même formalisme).

Un thème n’est pas un squelette

Il est important de comprendre avant toute chose qu’un thème doit se limiter à la décoration visuelle, à l’habillage graphique.

Un thème ne peut pas et ne doit pas se mêler de quel type d’information est affiché, de comment les informations sont sélectionnées etc ... Autrement dit :

  • un thème ne doit pas surcharger des éléments du squelette autre que ceux explicitement définis dans cette documentation.
  • un thème ne doit pas fournir de contenu autre que celui spécifié ci-dessous.

Écrire un thème qui ne suivrait pas cette règle le limiterait à fonctionner avec un squelette donné, ou dans un cas donné, alors que le but est ici de proposer une méthode qui permette d’écrire des thèmes interchangeables avec plusieurs squelettes.

Organisation des fichiers

Le thème est constitué d’un répertoire. Tous les fichiers y sont au premier niveau, sauf les images de décoration qui seront dans un sous dossier img/

Les feuilles de style

Le thème doit comprendre une feuille de style habillage.css qui sera incluse dans les pages par le squelette et sera appelée pour le media screen.

Le thème peut comprendre une feuille de style impression.css qui sera incluse dans les pages par le squelette et sera appelée pour le media print.

Si le thème nécessite l’ajout de composants dynamiques dans le head , il peut fournir au choix :

  • inc-theme-head.html qui sera incluse au même niveau que habillage.css, et reçoit les variables d’environnement (bien indiqué pour une CSS dynamique)
  • inc-insert-head.html qui sera ajoutée à la fin de la balise #INSERT_HEAD, mais ne reçoit pas les variables d’environnement. Cette inclusion est plutôt indiquée pour les scripts qui utilisent jQuery ou un composant javascript fourni par un plugin.

Quand c’est nécessaire, le thème peut aussi redéfinir la feuille de style dédiée aux formulaires spip_formulaires.css.

Les images de décoration

Toutes les images de décoration référencées par la css seront rangées dans un sous dossier img/ du thème.

Le thème peut contenir une image au premier niveau utilisée pour représenter le thème dans l’interface de sélection. Elle sera dans un format 200x150 pixels ou plus grand et proportionnel.

Layout

Le thème doit fournir un layout, ou structure HTML de la page. Il comprend toute la structure du HTML qui sera insérée dans le <body>...</body> à l’exclusion de la balise <body> elle même.

Ce layout doit inclure les 6 blocs fonctionnels génériques au moyen des lignes suivantes :

  • <INCLURE{fond=inclure/entete,env}> pour le bloc fonctionnel qui constitue l’en-tête visuelle du site.
  • <INCLURE{fond=inclure/barre-nav,env}> pour la navigation principale du site
  • <INCLURE{fond=contenu/#ENV{type},env}> pour le bloc principal de contenu, qui dépend du type d’objet affiché, donc.
  • <INCLURE{fond=navigation/#ENV{type},env}> pour le bloc de navigation « secondaire » de la page
  • <INCLURE{fond=extra/#ENV{type},env}> pour le bloc d’informations complémentaires de la page
  • <INCLURE{fond=inclure/pied,env}> pour le pied de la page.

Ce layout peut inclure un 7e bloc qu’il fournira lui même, nommé inc-theme-copyleft.html sous la forme <INCLURE{fond=inc-theme-copyleft,env}>. Ce bloc permet d’afficher les éventuelles informations de droits d’auteur et de crédits, y compris éventuellement un lien vers le site de l’auteur. Ce bloc ne doit pas être utilisé pour embarquer d’autres informations.

Ce layout sera renseigné dans le fichier body.html.
Ce fichier ne doit contenir que des éléments de structure de la page, et ne doit intégrer aucun contenu, sauf à entrainer une incompatibilité avec des squelettes.

plugin.xml

Le thème doit inclure un fichier de description plugin.xml. Ce fichier de description permet de renseigner les informations visibles dans le sélecteur de thème de l’espace privé.

Il permet aussi d’installer directement le thème dans le dossier plugins/ et de l’activer depuis le gestionnaire de plugins dans le cas où le webmestre ne veut pas mettre de galerie de thèmes à disposition des administrateurs.

Le fichier plugin.xml doit comporter au minimum les informations ci-dessous :

<plugin>
	<nom>Nom du thème</nom>
	<auteur>auteur, crédits</auteur>
	<licence>type de licence, lien vers la licence</licence>
	<version>1.0</version>
 	<description>description plus longue du thème</description>
 	<icon>vignette.jpg</icon>
 	<etat>stable</etat>
 	<prefix>theme</prefix>
	<utilise id="Z" version="[1.2.0;]" />
</plugin>

La balise <prefix> contiendra toujours la valeur « theme » qui permet de distinguer les thèmes, et d’empêcher l’activation de deux thèmes à la fois.

Variantes de thèmes

Lorsqu’un thème visuel comporte plusieurs variantes possibles, il est vivement conseillé de créer un thème indépendant pour chaque variante importante.

L’utilisation de panneau de configuration pour personnaliser les thèmes est tout à fait déconseillée car peu compréhensible par les débutants. L’expérience de l’utilisateur doit être privilégiée par rapport à la facilité pour le développeur.

Pratiquement, il est conseillé de faire un dossier thème portant le nom de la famille de thème, qui comportera un sous dossier pour chaque thème activable. Chacun de ces thèmes sera indépendant et comportera son fichier de déclaration plugin.xml.

Les variantes mineures pourront faire l’objet d’un fichier texte dans le thème qui explique quoi changer pour personaliser un peu le thème.

[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.]

PHP et autres mécanismes de plugin

L’utilisation de scripts php dans un thème est fortement déconseillée. Pour des raisons de sécurité, et pour permettre le téléchargement et l’installation automatisée de thèmes, il n’est pas permis de joindre de script PHP, ni de code PHP inline dans l’un des squelettes fournis par le thème.

Pour les mêmes raisons, les mécanismes génériques des plugins éventuellement spécifiés dans plugin.xml (tels que l’utilisation des pipelines) resteront inactifs lorsque un thème sera sélectionné par le gestionnaire de thèmes.

Discussion

21 discussions

  • Metalrod11

    Salut,

    Le squelette Magusine propose de nombreux thèmes sont certains sont très intéressants comme WomenLife (1&2). J’ai essayé de voir pour les adapter mais c’est pour l’instant au-dessus de mes compétences. ça intéresse quelqu’un ?

    A +

    P.S. Déclinaison de ce thème pour exemple : http://urbaorbilyon.free.fr/

    Répondre à ce message

  • Salut, cet article est noyé dans les thèmes . Ca serait pitetre intéressant de créer une rubique de type documentation pour les thèmes. non ?

    Sinon :
    Je suis en train de travailler sur un zquelette, je pense qu’il y aurais potentiellement quelques besoins en plus :

    1. des listes dans les meta-publi : notamment : nombre de commentaires , nombres d’images, nombre de documents. Voir pour les liste de rubriques avec résumé (bah oui , on peut) : nombres d’articles, nombre de brèves ...
    2. une liste de tags avant ou après meta-publi : il me semble que quelqu’un en parle ailleurs.
    3. une classe raccourcis ou skip-link (de toute façon Maïeul va en avoir besoin)

    Autre chose, comme j’utilise des liste avec des résumé pour des événements , des rubriques etc .... pas mal de thèmes font le distingo .liste .articles et .liste .rubrique par exemple . Alors que quand on a une liste d’article sans résumé : on aimerais qu’ils soit présenté comme les autres listes. Inversement quand on a une liste de site avec résumé, on aimarais qu’ils soient présentés comme une liste d’articles.

    Est ce que ca veut dire qu’il faut ajouter une classe supplémentaire sur les li ? (le hentry ne me semble pas correspondre à une présentation d’un site)

    Bonne soirée :)

    Répondre à ce message

  • Le thème peut comprendre une feuille de style print.css

    J’ai l’impression que c’est devenu impression.css ... me trompe-je ?

    Répondre à ce message

  • Il est où ce plugin bandeau ou slogan ?
    Impossible de le trouver...
    Merci par avance et Bonne Année !!!

    Répondre à ce message

  • 4

    J’ai adapté le thème dotclear welsh 2.0 qui existe en version 2 colonnes et 3 colonnes je me suis posé la question des variantes d’un squelette (de la même manière j’ai sous la main une version noir et blanc du même thème.

    La solution du thème d’origine est de demander aux utilisateurs de modifier une ligne de code. J’ai tendance à penser que le but d’une interface de type zen-garden est précisément de faire en sorte que l’utilisateur n’ait pas à toucher la moindre de ligne de code pour faire ses choix. J’ai donc créé eux thèmes Zpip, même s’il n’y a qu’une dizaine de lîgnes de css qui change.

    Est-il possible pour éviter de dupliquer l’ensemble du thème de prévoir par exemple l’utilisation de CFG ? Naturellement le problème est que les options seraient dans un autre emplacement de l’interface.

    • Je plussois , peut être juste la possibilité de sélectionner différents
      -  inc-theme-head.html
      -  inc-insert-head.html

      arclite à différents coloris et snowblind à 2 versions (une en 1024 et une en 800). Alors, bien sur je peut ajouter cette option au mode plugin, mais le seul changement sont des inc-theme-head différents.

      A propos, inc-insert-head.html vient après habillage.css, je pense qu’il serait mieux de le passer après habillage.css. Ce qui permettrait de remplacer les options par défaut de l’habillage. :)

    • C’est le genre de fonctionnement qui a le don de compliquer la vie de l’utilisateur pour simplifier celle du développeur.
      Donc perso je vote contre, et je pense que le mieux est de faire un thème par variante. Par contre, pour le rangement sur la zone, tu peux faire un dossier général (vide) au nom du thème, avec un sous dossier pour chaque variante.

      Plus tard on prévoira peut-être un système de variantes bien intégré et tout ça, mais ça n’est vraiment pas la priorité. La preuve en est la solution rustique proposée dans le thème original qui montre que bien qu’ayant mis les systèmes de thème en oeuvre depuis longtemps, les autres outils de publication ne gèrent pas forcèment la notion de variante.

    • après ou après ?

    • Heu ... après ?
      (edit)Il est avant actuellement .. (edit)

      [(#REM) Feuille de style CSS pour l'affichage du site a l'ecran ]
      [<link rel="stylesheet" href="(#CHEMIN{habillage.css}|direction_css)" type="text/css" media="projection, screen, tv" />]
      
      [(#REM) Feuille de style CSS pour l'impression ]
      [<link rel="stylesheet" href="(#CHEMIN{impression.css}|direction_css)" type="text/css" media="print" />]
      
      [(#CHEMIN{inc-theme-head.html}|oui)
      #INCLURE{fond=inc-theme-head,env}
      ]

      Sur arclite, j’ai mis les variations de couleurs via l’installation en plugin. J’aurais pu faire la couleur brune dans habillage et surcharger via inc-theme-head . Ce qui permettrais d’installer arclite sur la dist actuelle avec quelques défauts. Actuellement, si zpip n’est pas installé/activé , habillage-couleur.css n’est pas chargé. Donc pas de couleurs.

      Maintenant, j’aurais pu choisir une méthode différentes pour les changement de couleur. Mais cela me semble logique de pouvoir surcharger habillage.css via des habillage-options.css dans inc-theme-head.

      Je peut commiter si c’est daccord.

    Répondre à ce message

  • Lors de l’adaptation de zpip aux thèmes de type wordpress, j’ai pu reamrquer quelues trucs que l’on peut conseiller lors de la conception de squelette pour faciliter la mise en place d’autres squelette compatible zpip.

    -  Le formulaire de l’entête peut se généraliser au formulaire_recherche en plus du formulaire de langue. Il est sans doute possible de le généraliser à d’autres formulaires mais plus difficilement (login_public). Voir à d’autres élément sur l’emplacement (rss ?)
    -  Il manque un contenu autre qu’un menu ou une liste dans extra et navigation. Par exemple , le squelette pourrait choisir d’afficher le descriptif du site dans extra plutôt que dans contenu ou bien le texte de la dernière brève ou ... Un div class=« special » (special : traduction de featured) par exemple (J’étais sur l’adaptation de http://www.mollio.org/typeF.html en squelette avant la sortie de zpip, plutôt adapté à un thème).

    Répondre à ce message

  • 1

    une ch’tite coquille dans l’article, le répertoire où mettre les « images » est images et non pas « img ».

    A+
    Cyril

    Répondre à ce message

  • La liste des thèmes en cours d’adaptation sont visible sur le carnet.

    N’hésitez pas à remplir la liste , avec les thèmes que vous souhaitez voir adapter ou que vous pensez adapter ;)

    Répondre à ce message

  • Vu que ça reprend le principe du plugin.xml, est-il possible de définir un fichier de filtres theme_fonctions.php ? Je n’ai pas réussi.

    Répondre à ce message

  • 7

    Bonjour,

    On dit de mettre <INCLURE{fond=inclure/barre-nav,env}>, mais barre-nav est vide dans zpip...
    Ça ne serait pas plutôt barre-nav-secteurs ?

    • Pour remplir barre-nav, il faut ajouter le plugin menus.

    • Ok, oui, en effet, c’est stipulé dans la doc Le Squelette Zpip...

      Mais par contre, ce n’est pas stipulé qu’il faut le plugin « slogan » qui se trouve sur la zone. #SLOGAN_SITE_SPIP est natif (?) en 2.1 mais pas en 2.0.10...

    • Si « Pour remplir barre-nav, il faut ajouter le plugin menus », ça prouve que tetue a raison quand elle dit que la nomenclature n’est pas bonne.

    • Oui, la navigation principale dans Zpip est vide. Libre à chacun de la définir dans son dossier squelettes/ ou avec le plugin menu. A voir si il faut faire évoluer cela par défaut.

    • #SLOGAN_SITE_SPIP est aussi fourni par le plugin http://zone.spip.org/trac/spip-zone/browser/_plugins_/bandeau qui préfigure la navigation de la 2.1 et l’identité du site qui va avec. Je n’ai pas souhaité doublonner en le mettant dans Zpip, mais il m’a semblé logique de le prévoir sans attendre la dispo de la 2.1

    • non non, tu as bien fait ! Mais j’ai été déconcerté hier soir. Je m’arachais les cheveux pour comprendre pourquoi mon dscriptif site spip ne s’affichait pas au bon endroit... Jusqu’à c que je décide de regarder les fichiers de zpip...

      Dans ce cas là, il faudrait le signaler dans la doc. Je n’ai pas vu d’ mention pour cela jusqu’à maintenant

    • J’adhère plutôt au principe qui laisse un choix au concepteur du site tout en lui mâchant le travail, ce qui ets un peu le but de ce squelette mais peut-on éviter dans Zspip d’avoir : <div id="nav">  </div> quand le plugin est désactivé et que barre-nav est vide ?

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

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

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom