Installer Zpip
Zpip se charge et s’installe comme un plugin. Pour installer Zpip et jouer avec sans plus attendre, il suffit de suivre le guide d’installation pas à pas.
Une fois installé, vous pourrez vous faire plaisir en téléchargeant des thèmes déjà existants, et revenir lire la suite de cet article au moment de mettre un peu les mains dedans pour le personnaliser !
Le projet Zpip
Plus qu’un squelette, Zpip est un exemple d’un système de squelette qui met en application les idées exposées dans Modèle de squelette réutilisable. Il propose une organisation des squelettes visant à le rendre :
- habillable par des thèmes indépendants du squelette
- maintenable dans le temps, par une duplication minimale du code
- rapidement déployable, au prix d’un petit apprentissage initial sur son organisation
Zpip s’adresse aussi bien aux débutants qui veulent profiter d’une galerie de thèmes prêts à l’emploi, qu’aux webmestres avancés pour qui il propose un fonctionnement et des mécanismes productifs.
Toute l’organisation et le fonctionnement de Zpip peuvent être réutilisés pour construire de nouveaux squelettes qui bénéficieront des mêmes avantages.
Organisation des fichiers
Zpip redéfinit tous les squelettes par défaut de la dist de SPIP, à la racine de son dossier : 404.html, article.html, auteur.html, backend.html, breve.html, forum.html, login.html, mot.html, page.html, plan.html, recherche.html, rubrique.html, site.html, sommaire.html, et spip_pass.html.
À l’exception du flux RSS (backend.html), tous ces squelettes sont réécrits de façon minimale pour inclure structure.html qui produira toutes les pages. Vous pouvez donc oublier tous ces squelettes issus de la dist : vous n’aurez plus besoin de les manipuler, sauf cas exceptionnel.
Nous voici donc avec deux squelettes supplémentaires à la racine : structure.html et body.html.
Le premier, structure.html, pose la structure minimale de la page HTML, inclut les squelettes chargés de produire le head, puis le body.html qui définit le layout unique et sur lequel nous revenons ci-dessous plus en détail.
Zpip contient de plus six sous dossiers.
Deux sont génériques :
-
img/qui contient toutes les images de décoration -
inclure/qui contient les squelettes communs et partagés entre les différentes pages du site.
Les quatre autres dossiers déclinent des morceaux de la page html en fonction de la page du site sur laquelle on se trouve :
-
head/qui contient les squelettes de la section<head>personnalisée pour chaque page, lorsque c’est nécessaire, qui s’ajoute à un<head>commun situé dansinclure/ -
contenu/dans lesquels seront mis tous les squelettes produisant le contenu principal de chaque page -
extra/dans lesquels seront mis tous les squelettes produisant les informations extra contextuelles pour chaque page -
navigation/dans lesquels seront mis tous les squelettes produisant les informations de navigation propres à chaque page
Layout Unique
Zpip est donc organisé autour d’un layout unique décrit par body.html qui intègre 6 entités logiques de contenu et les structure à sa guise dans le HTML.
Les 6 entités sont nommées selon la convention ci-dessous, eu égard à leur contenu informationnel et sans préjuger de la dénomination et de la structure englobante définie par le thème :
- entête fournit la présentation de la page et d’identité du site
- barre-nav constitue la navigation principale du site ; peut être vide
- contenu contient l’information principale de la page, déclinée par type de page
- navigation fournit des éléments de navigation secondaire, déclinés par type de page
- extra fournit des éléments d’information connexes contextuels, déclinés par type de page
- pied fournit des éléments de repérages et de rappels secondaires
Le layout par défaut de Zpip est simple :
<div id="page">
<div id="entete">
<INCLURE{fond=inclure/entete,env}>
</div>
<div id="nav">
<INCLURE{fond=inclure/barre-nav,env}>
</div>
<div id="conteneur">
<div id="contenu">
<INCLURE{fond=contenu/#ENV{type},env}>
</div>
<div id="navigation">
<INCLURE{fond=navigation/#ENV{type},env}>
<INCLURE{fond=extra/#ENV{type},env}>
</div>
</div>
<div id="pied">
<INCLURE{fond=inclure/pied,env}>
</div>
</div>Nous voyons que ce layout ne gère qu’une unique colonne #navigation, laquelle intègre le contenu des blocs de navigation et extra.
Pages automatiques
Zpip intègre un mécanisme de génération automatique des pages complètes à partir d’un seul squelette de contenu.
Par exemple, il suffit d’écrire un squelette minimal contenu/page-inscription.html contenant seulement :
#FORMULAIRE_INSCRIPTIONpour que la page complète spip.php?page=inscription soit disponible.
Pour réaliser cela Zpip utilise les éléments communs inclure/entete.html, inclure/barre-nav.html et inclure/pied.html. Pour les éléments de navigation et d’extra, Zpip utilise par défaut les squelettes navigation/dist.html et extra/dist.html si aucun squelette navigation/page-inscription.html ou extra/page-inscription.html n’est défini.
Ce mécanisme de pages automatiques permet d’ajouter, aussi rapidement que facilement, des pages spécifiques, en cohérence immédiate avec le reste du site. De même, il permet à des plugins de fournir des pages dédiées, utilisables sur tous les sites quelle qu’en soit leur structure, laquelle sera automatiquement fournie par Zpip.
Par exemple, un plugin de newsletter peut facilement fournir un squelette contenu/page-abonnement.html (permettant à l’abonné de gérer son abonnement), qui pourra être utilisé tel quel par tous les sites reposant sur Zpip.
Menu de navigation principale
Zpip permet de gérer votre navigation principale directement dans l’espace privé à l’aide du plugin Menus. Il suffit de créer un menu avec l’identifiant barrenav pour qu’il soit automatiquement inséré à la place de la navigation principale, sans modifications de fichiers.
Compositions
Zpip est naturellement conçu pour fonctionner avec le plugin Compositions qui permet d’utiliser plusieurs types de composition par objet, et de décliner les cœurs de page en fonction des besoins.
Thèmes
Grâce à sa structure, Zpip est utilisable directement avec une galerie de thèmes interchangeables.
Pour faciliter l’écriture de nouveaux thèmes pour Zpip, un certain nombre de conventions ont été documentées qui permettent de définir un socle commun.
Les thèmes qui respectent ces conventions pourront être utilisés indifféremment avec Zpip ou tout autre squelette reposant sur la même structure et les mêmes conventions.
Discussions par date d’activité
168 discussions
Comment ,dans configuration, faire apparaître un champ pour écrire ce qui ira dans le slogan ?
#SLOGAN_SITE_SPIP est bien dans entete !
C’est la première fois que j’utilise zpip et j’aime cela.
Hé ! Merci
Répondre à ce message
Pourquoi sur page_article a-t-on
et sur page_auteur :
<p class="hyperlien">tout court ?Répondre à ce message
Chers compatriotes, merci beaucoup pour cet excellent squelette que je découvre avec plaisir, seulement une question me ronge à l’installation et c’est celle du menu horizontal :
Pourquoi laisser vide barre-nav.html ? Déjà j’ai passé des heures (oui, oui..) à trouver ce fichier mais en le trouvant vide et en essayant de comprendre quelle boucle aviez vous pu y inscrire pour que ce menu fonctionne si joliment, avec le thème wu-wei ou harvestField, par exemple, je me suis découragé un petit peu.
Pour les NULS comme moi ces vides nous font trébucher graaaave. Plein, même si c’est à modifier, pour nous en servir en tant accroche, cela nous aiderait grandement, nous autres les NULS.
Merci quand même et encore une fois pour votre excellent travail.
Il faut activer le plugin menu
Merci... hmmm.. Veux-tu dire qu’il faut installer en plus un plugin ? Lequel ?
ah ! j’ai trouvé, merci !
je suis délolée... je dormais :p
Répondre à ce message
Mathieu, Cédric,
Sincèrement, c’est un travail de titan que vous avez accompli. J’ai déja adapté/adopté certains de vos thèmes. Bravo, bravo.
En revanche, une suggestion : expliquez que Zpip est à installer dans les « plugs-in » et non... dans les squelettes. Son rangement ici peut prêter, je crois, à confusion chez les moins spipérimentés ,-)
Encore bravo
Répondre à ce message
Bonsoir,
J’essaye d’utiliser le plugin composition pour l’une de mes rubriques.
Je créé donc un répertoire compositions dans squelettes .
Puis je créé un fichier rubrique-speciale.xml : la composition est bien reconnue.
Ensuite j’ai testé :
Mais ca ne fonctionne pas semble t’il. Quelle erreur je fait, quel est le fonctionnement des compositions ?
Merci
Désolé, j’ai relu les sources ....... et la doc ....
Répondre à ce message
Bonjour,
Quel beau travail ! Mais il y a, sauf erreur ou omission de ma part, un problème de compatibilité avec le plugin accès_restreint, qui ne fonctionne plus avec ce squelette.
Bien cordialement
Répondre à ce message
Comment faire un squelette pour une rubrique particulière avec zpip ? Est ce possible ?
Bravo des deux mains pour zpip et autres thèmes !
Il est conseillé d’utiliser le plugin Composition, mais sinon il est toujours possible de faire un squelette
contenu/rubrique-xx.htmlBé non, en plaçant un fichier rubrique-3.html dans le répertoire squelettes/contenu/ le squelette n’est pas pris en compte :(
Problème résolu : avec le plugin, si /squelettes/contenu/rubrique.html n’existe pas alors /squelettes/contenu/rubrique-xx.html ne sera pas pris en compte.
Autrement dit, il faut le fichier /squelettes/contenu/rubrique.html pour que /squelettes/contenu/rubrique-xx.html soit pris en compte :)
Ah mais c’est le fonctionnement normal de SPIP ça. Un squelette truc-xx.html n’est pris en compte que si il est à côté du squelette truc.html.
Aucune spécificité à Zpip, donc !
Répondre à ce message
Concernant le/les squelettes zpip et les thèmes,
Je pense que la taille des images devrait pouvoir être configurable via le thème, je n’ai aucune idée du comment faire mais je peut tenter de trouver du temps pour trouver des pistes.
En effet la taille des images influence énormément le visuel de la page. Autant leur présence, c’est au squelette (et surtout au webmaster) de le décider, autant sur leur taille je pense plutôt que c’est au thème de le choisir. (je parle des LOGO_SPIP, la taille des imgXX devant incomber au webmaster ou aux rédacteurs dasn une certaines limite).
Concerant les thèmes, il est aussi très important de pouvoir faire des thèmes compatibles avec l’ensemble des squelette Z. Je pense que cela risque d’être très difficile mais que cela demande réflexion, non ?
A+ et merci
Tu peux gérer la taille des logo en css, il me semble.
Sachant que dans tous les cas, les contenus sont fournis par le site, et tu ne peux pas être sûr que les logos disponibles auront une taille par défaut suffisante.
En première alternative, on peut imaginer une déclaration dans le plugin.xml pour spécifier la taille de recadrage des logos, mais cela suppose de recourir par défaut aux librairies graphiques, ce qui ne m’enchante guère.
En seconde alternative, on peut décider que le thème peut fournir un modèle pour implémenter les logos d’article, ce qui lui permettrait d’y spécifier la taille.
en JS , oui, mais en CSS , je connais pas (qui fonctionne en CSS 2)
Dans le genre : optionnel :
Pas mal , et simple en plus, je trouve ça intéressant (avec certaines obligations)
Par contre , à ne pas englober dans un div, puisque dans ce cas on retrouve le même problème qu’a soulevé Valery concernant le div barre-nav vide.
Merci
Répondre à ce message
Pourrait on exclure le formulaire_recherche de #navigation et le mettre dans le layout (inclurerecherche).
Il semble que énormément de template place le champ de recherche en entète, en pied ou extra.
Je me pose aussi la question pour formulaire_inscription qu’il peut être utile de mettre sur toutes les pages sur certains site et donc de les intègrer aux thèmes plus qu’au squelette.
:)
+1 :-)
D’ailleurs ce n’est pas dans l’entete dans la dist ?
De toute manière il faut faire des choix dans ce genre de chose : un formulaire dans l’entête peut gêner aussi (cf. le menu lang dans le zspip actuel).
Bon en même temps zspip est un exemple de ce principe de développement : d’après ce que j’ai compris l’idée est de développer d’autres squelettes selon cette « norme » de telle sorte que la bibilothèque de thèmes en cours de constitution puisse être commune.
Concernant le formulaire d’inscription, c’est clairement non : l’utilité de le mettre ou non sur toutes les pages est une utilité fonctionnelle, et donc à ce titre n’a pas à être décidée par le thème, mais bien par le squelette.
Concernant le formulaire de recherche, c’est plus compliqué :
Après plusieurs essais et hésitations, j’ai pris le parti de poser comme convention que le formulaire de recherche serait toujours placé dans la navigation secondaire, par le squelette. En pratique, cela n’empêche pas de le faire apparaître visuellement dans l’en-tête en
position:absolute.En adaptant des thèmes, j’ai pu constater que prévoir dans l’en-tête (en sus de la navigation principale qui y est souvent aussi ) :
relevait déjà du challenge, et qu’il était souvent peu réaliste de placer aussi le formulaire de recherche dans cette zone. Dans les thèmes que j’ai adapté, il m’est donc arrivé de ne pas respecter le thème initial et d’utiliser la place prévue pour la recherche pour y placer le formulaire de changement de langue lorsqu’il est présent.
Donc, voila. Tout est affaire de compromis. On peut en rediscuter, mais je pense qu’il faut voir un peu à l’épreuve des faits ce que cela donne.
Encore une fois, un système prédéfini avec une API fixée ne permettra jamais de couvrir 100% des cas, sauf à complexifier outre mesure l’API.
Il faut donc voir si ajouter un inclure dans le layout pour pouvoir placer la recherche vaut la complexité que cela apporte.
Ok,
de toutes facon, ceci est gérable par un autre plugin surchargeant zpip ou par le squelette. (en rentrant à la maison, je me suis dit que ma question était ridicule). Par contre, je préfére proposer un #navigation .recherche et un #entete .recherche que l’absolute qui fonctionne plus ou moins bien, et dans ce cas propose rla barrenav en absolute et à la fin carrément (ce qui permet de garder l’intéret du layout gala).
Par contre , une dée pour les thèmes multi-css ? ou multi layout ?
Proposer juste les fichiers en plus (habillage-rouge.css, habillage-vert.css // layout-3col.html // layout-onlicontent.html)
Ou autant de thèmes que possible ?
Ce qui me semble manquer le plus est à vrai dire à ce stade un mécanisme pour gérer le layout de la page d’accueil. En effet dans une grande majorité des site (je n’ai pas compté, c’est ce que je perçois) il est différent des pages de contenu (c’est la limite de se baser sur des thèmes de blog pour travailler où ce n’est pas toujours le cas).
Il est facile naturellement de contourner le problème dans un z-squelette en ne traitant pas sommaire.html de la même manière que les autres mais dans un thème c’est problématique d’autant plus que la page d’accueil dispose parfois de styles graphiques que l’on ne trouve pas sur les autres pages.
Pour prendre un cas que je connais, The Morning After, je suis en train de travailler sur le thème pour habiller Zspip à l’aide du plugin SZG et les pages de contenu sont très très proches du squelette / thème WP d’origine. La page d’accueil elle, n’a rien à voir.
Naturellement Zspip ne prévoit pas de contenus très complexes en accueil : peut être faut-il attendre pour trancher d’avoir avancer dans le zspipage de squelettes plus complexes.
Je me répond à moi-même après quelques heures de test supplémentaires.
Pour un thème Zspip, un même body-layout peut avoir dans une certaine limite une présentation différente des pages de contenu.
On peut ainsi utiliser la class .page_sommaire sur le body pour donner à ses éléments de layout des comportements distincts. Une page d’accueil peut donc avoir trois colonnes, et une page de contenu une seule colonne : il suffit de définir de manière différente les div (par exemple navigation et extra).
Les styles d’un thème spécifiques à la page d’accueil sont plus difficiles à reproduire, on se retrouve vite à devoir utiliser des pseudo-elements et des combinateurs de frères adjacents ce qui ne donnera pas le rendu attendu dans les navigateurs old-school.
Une contrainte consistera, lors de la conception de squelettes Z-like sera de prévoir des styles spécifiques au squelettes (pour habiller par exemple des inclures propres au squelette) tout en permettant, si on souhaite rendre son thème compatible avec d’autres squelettes, d’obtenir chez eux un rendu satisfaisant sans ces styles spécifiques.
Ensuite l’idée des thèmes est d’être compatibles mais ils ne peuvent pas prévoir tous les cas de figure. Tous les thèmes ne sont pas nécessairement adaptés à tous les squelettes mais l’intérêt est qu’il est très simple de modifier un inclure pour personnaliser sur son site tel ou tel aspect.
C’est un point qu’on n’a pas encore abordé clairement d’avoir des variantes de thèmes.
Quelques idées à réfléchir :
<variante>fichier.css<variante>…Il faudra y réfléchir… :)
Oui, en ce qui me concerne j’utilise quasiment tout le temps le layout gala, (ou une variante enrichie à 4 colonnes), et cela me permet de traiter tout le site dans un seul layout, en gérant les variantes (home, pages spéciales etc ..) par du simple css qui cible la classe sur le body pour la page concernée.
Donc c’est vrai que je n’ai pas reflechi à des variantes de layout au sein d’un même thème.
Cela dit, les selecteur sur le body pourront être enrichis dans le futur. Typiquement j’ai sur mes projets un ensemble de classes du type
qui décrivent l’arborescence de l’objet et permettent de cibler en css une rubrique, une branche, un article etc ...
Mais je pense que cela fera l’objet d’un plugin, car cela a un coût en terme de performance, et ça ne me parait pas une bonne idée de le mettre par défaut dans Zpip.
Pour les variantes de thème, on a effectivement les 2 possibilités :
- un CFG dans le thème qui permette le configuration, et le theme qui gère les css en fonction de cela
- un thème par variante.
Dans un projet personnel, la première se défend. Pour distribuer, je préfère qu’on fasse un thème par variante, ce qui permet de le gérer et le visualiser dans le Zen Garden, même si c’est un tout petit peu plus lourd en maintenance car oblige à dupliquer une css en général.
Comme les thèmes sont des plugins, on peut envisager :
Le thème en thème > css et layout par défaut.
Le thème en plugin > cfg pour gérer la css et le layout.
Oui, mais lors d’une mise à jour du layout, par exemple, il faudra faire éventuellement 5 ou 6 svn-update. Perso j’ai peur d’oublier. (mais je suis tète en l’air).
@Maieul : si j’ai bien compris le principe : comme pour cette situation, on ne parle plus de “look”, donc, personnellement , j’aurais fait pareil.
Je découvre un peu le concept Zpip. La portabilité des thèmes est séduisante.
Mais cela signifie-t-il que l’on va formaliser, ET figer les emplacements de différents éléments comme le nombre de colonne, la zone de recherche, le formulaire d’abonnement, ... ?
Ce que j’attendrais de ... XPIP, c’est de pouvoir déplacer les modules d’un div à l’autre comme sait le faire Moodle : il suffit de se connecter pour qu’apparaisse des flèches de déplacement vers le bloc adjacent. Exemple :
http://www.elluminate.com/images/bridge_moodle_screenshot.jpg
Une zone annexe proposerait tous les blocs disponibles non encore placés sur la page.
Ça me paraît tout proche avec ce principe de Layout...
J’envisage/eais un peu ce type de fonctionnement, cependant il n’est pas difficile de travailler un peu sur le squelette pour le modifier à convenance.
Mettre une partie configuration de zpip rendrais le squelette quasiment inmodifiable avant une analyse poussée. Garder un squelette simple permet à chacn de le modifier suffisamment.
Tu confonds deux problématiques, que j’ai pourtant bien essayé de distinguer dans mes articles :
- le fonctionnel (quelle information est affichée, comment elle est récupéreé et construite ..)
- l’habillage (à quoi ça ressemble).
Le mécanisme des thèmes de Zpip répond au deuxième problème. Le premier n’est pas traité pour le moment.
Si Moodle fait ça, c’est bien, tant mieux. Ça a un coût, que je ne connais pas dans son cas, mais qui peut être de la rigidité cachée, et la complexité quand on sort du sentier tracé etc ...
Pour Spip, je réfléchis à quelque chose d’équivalent, mais ce n’est pas encore mur. Disons simplement que l’architecture de Zpip y est plus ou moins prédisposée.
Répondre à ce message
Concernant les squelettes compatibles zpip.
Ne pourait il pas être intéressant d’avoir une classe css sur le bodu avec le nom du squelette : pour zpip :
<body class="zpip page_#ENV{type,page}[ #ENV{type,page}_(#ENV{composition,''})]">Ce qui permettrait d’adapter un chouia le thème au différents squelettes.
C’est sans doute très bête ce que je dis, mais il m’arrive parefois de mettre le logo dans les listes en dessous du titre via une marge haute dans la CSS. La marge dépendant bien évidemment du contenu de article-resume.
Si un autre squelette compatible zpip pose le logo de l’artcile en dessous du titre, c’est tout cassé.
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 :
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.
Suivre les commentaires :
|
