Note de version
Depuis la version 2 du plugin Compositions, il est possible de définir des héritages par branche.
La fonctionnalité Article d’accueil a été extraite dans un plugin dédié.
Compositions nécessite le plugin Bonux.
Objectif
Ce plugin a pour but de fournir un mécanisme et une interface pour faire varier le type de composition de chaque objet en fonction des besoins.
Par exemple, vous pouvez avoir besoin de composer certains articles sous une forme d’article de journal, et certains autres comme des albums photos.
Ou vous pouvez vouloir composer certaines rubriques comme des blogs, et d’autres de façon plus classique...
Configuration
Le plugin ne nécessite pas CFG, mais si celui-ci est installé vous pourrez modifier certaines options de fonctionnement. Dans le cas contraire, les réglages par défaut seront appliqués.
Sous SPIP 3, le formulaire de configuration est directement accessible, sans CFG, via le menu Configuration > Compositions.
Utiliser les compositions sur les objets
Sous SPIP 3 uniquement, vous pouvez définir les objets pouvant recevoir des compositions.
Dossier des compositions
Ce réglage vous permet de choisir le sous-dossier qui contiendra les différentes compositions. Par défaut le nom de dossier compositions/ est utilisé, contenu/ si vous utilisez Zpip, content si vous utiliser Zcore. C’est-à-dire que les compositions seront recherchées dans squelettes/compositions/, puis dans les sous dossiers compositions/ des plugins, etc.
Sélection des squelettes
Par défaut, le squelette de la composition est sélectionné automatiquement par SPIP. Mais ce mécanisme est désactivable pour des besoins précis.
Masquer le formulaire
Vous pouvez masquer le formulaire de Compositions aux utilisateurs n’ayant pas les droits de modifier la composition d’un objet donné afin d’alléger l’interface.
Tout verrouiller
Compositions possède un mécanisme permettant à la personne qui gère le site avec le statut webmaster de verrouiller une composition et/ou les compositions d’une branche. En activant cette option, toutes les compositions seront verrouillées et uniquement la ou le webmaster pourra les modifier.
Définir des compositions
Une composition est constituée par une paire de fichiers : un squelette et un fichier XML qui l’accompagne et porte le même nom. Leur nom est composé du type de l’objet (article, rubrique ou autre) suivi du nom de la composition séparée par un tiret. Par exemple : article-edito.html et article-edito.xml ou encore rubrique-chronologique.html et rubrique-chronologique.xml.
Les compositions doivent être rangées dans un sous-répertoire de votre dossier squelettes, appelé compositions/ (le nom de ce sous-répertoire est configurable).
Il est possible de définir une composition par défaut pour chaque type d’objet, en la nommant simplement article, rubrique, etc. sans la suffixer.
Pour définir une composition de type portfolio d’un article on va par exemple :
- créer un squelette compositions/article-portfolio.html,
- créer à côté un fichier compositions/article-portfolio.xml.
Le squelette sera constitué classiquement de boucles et balises pour réaliser l’affichage de l’article selon le mode de composition qui vous convient. Le fichier XML pourra contenir la description de cette composition :
<composition>
<nom>Article Portfolio</nom>
<description>Composition adaptée aux galeries d'images</description>
<icon>images/article-portfolio.png</icon>
</composition>Lorsqu’aucune composition n’est définie pour un type d’objet donné, aucune interface n’apparait dans l’espace privé.
Mais lorsque vous avez défini au moins une composition, une interface apparaît et permet aux administrateurs de choisir sur chaque objet la composition qui lui convient parmi celles qui sont définies.
Définir des compositions héritées
Dans le fichier XML d’une composition de rubrique, vous pouvez définir une composition qui s’appliquera par défaut aux objets de la branche (articles, sous-rubriques, brèves...). Il vous suffit d’ajouter dans le XML de la composition une tag de la forme <branche type="objet" composition="nom_composition" />. Par exemple, vous pouvez faire une composition rubrique-agenda avec le XML suivant :
<composition>
<nom>Rubrique Agenda</nom>
<description>Composition pour les rubriques gérant un agenda</description>
<icon>images/objet-liste-contenus-dates.png</icon>
<branche type="article" composition="agenda" />
<branche type="rubrique" composition="agenda" />
</composition>Les articles de cette rubrique et de ses sous-rubriques hériteront alors de la composition article-agenda.html. Attention : il doit s’agir d’une composition valable et doit donc disposer d’une description dans un fichier article-agenda.xml.
La composition héritée par un objet n’est pas forcément homonyme de la composition de la rubrique. Vous pouvez donc avoir une composition rubrique-machin avec <branche type="article" composition="truc" />. Dans le cas présent, truc fait référence au suffixe de article-truc.html. Le tag <nom></nom> de article-truc.xml reste libre de recevoir le texte de votre choix.
Par ailleurs, il vous est toujours possible de modifier au cas par cas la composition d’un objet donné. Si l’objet hérite d’une composition, l’interface vous proposera donc de lui appliquer la composition héritée ou bien de lui appliquer une autre composition de votre choix.
La composition par défaut d’un objet n’ayant pas de nom (puisqu’il s’agit du squelette correspondant au nom de l’objet sans suffixe), on pourra l’indiquer dans le tag <branche /> à l’aide d’un tiret (composition="-").
Si les rubriques parentes d’un objet définissent plusieurs compositions héritées, c’est la composition définit par la rubrique la plus proche qui s’appliquera.
Prenons un exemple concret. Supposons un secteur A ayant trois sous-rubriques A1, A2 et A3. La composition appliquée au secteur A attribue aux articles de ce secteur la composition truc (<branche type="article" composition="truc" />). Par ailleurs, on a appliqué à la sous-rubrique A3 une composition attribuant aux articles de sa branche la composition par défaut (<branche type="article" composition="-" />). Les articles des rubriques A, A1 et A2 seront alors affichés avec le squelette article-truc.html alors que ce sera article.html qui sera utilisé pour les articles de la rubrique A3 [1].
Verrouiller les compositions
Par défaut, les individus ayant le droit de modifier le contenu d’un objet ont le droit de modifier sa composition. Cependant, si vous êtes webmaster, vous pouvez verrouiller une composition. Cette dernière ne sera alors plus modifiable que par un webmaster.
Si vous êtes dans une rubrique, vous pouvez verrouiller la composition de tous les objets de cette branche (sous-rubriques, articles, brèves, sites, etc.).
Enfin, dans la configuration de Compositions, vous pouvez également verrouiller toutes les compositions.
Interface
Lorsque des compositions ont été mises en place par le webmestre, un formulaire de sélection apparait automatiquement dans l’espace privé sur chaque objet de ce type.
L’interface peut différer selon vos réglages afin de n’afficher que les options s’appliquant à votre situation.
Utilisation avec les squelettes de type Z comme Zpip
Utilisé avec un squelette Z comme le squelette Zpip (version 1.7.10 minimum), le fonctionnement par défaut des compositions s’applique au cœur de page (le contenu). Le dossier par défaut pour mettre les compositions est alors contenu/ pour zpip et content/ pour zcore..
Une composition contenu/article-portfolio.html sera alors utilisée à la place de contenu/article.html, le reste de la page étant alors inchangé. Pour plus d’information sur la construction des pages dans le squelette Zpip, voir sa documentation.
N.B. : pour que la composition bloc/article-portfolio.html soit prise en compte, il doit obligatoirement y avoir un squelette bloc/article.html dans le même dossier.
ll n’y a donc aucun réglage à faire pour utiliser le plugin Compositions avec Zpip : il suffit de déclarer des compositions dans un dossier contenu/ (dans le dossier squelettes/ par exemple) pour pouvoir les utiliser pour faire varier la présentation du contenu des objets de SPIP.
Utilisation avec Zcore
Si vous créez vos propres jeux de squelettes avec Zcore, n’oubliez pas de passer la composition dans votre fichier objet.html de base. Exemple avec article.html.
<BOUCLE_principale_article (ARTICLES) {id_article}>
<INCLURE{fond=structure, env, id_rubrique=#ENV{id_rubrique,#ID_RUBRIQUE}, id_secteur=#ID_SECTEUR, type-page=article, composition=#COMPOSITION} />
</BOUCLE_principale_article>Utilisation avec le noiZetier
Si vous utilisez Compositions avec le plugin noiZetier, vous pouvez créer des compositions directement dans l’interface de SPIP. Une fois créées, il vous reste seulement à modifier les noisettes de votre composition pour disposer d’un affichage alternatif pour vos objets.
Pour plus d’informations, voir Les compositions du noiZetier.
Utilisation personnalisée dans les squelettes
En dehors des squelettes Z, le fonctionnement du plugin par défaut est de sélectionner automatiquement un squelette, dans son intégralité. Ce mode de fonctionnement oblige donc à définir le squelette en entier pour chaque composition.
Pour une utilisation différente du plugin dans le cadre d’un squelette personnel, et pour utiliser les compositions pour faire varier une partie de la page uniquement, le mécanisme automatique peut être désactivé.
Dans ce cas, la balise #COMPOSITION peut être utilisée dans les squelettes pour inclure la bonne variante de composition dans la partie de la page que le webmestre souhaite faire varier.
La balise #COMPOSITION tient compte des héritages éventuels s’appliquant à un objet. Il est donc impératif de s’appuyer sur cette dernière et non sur la valeur du champ composition des tables SQL pour connaître la composition s’appliquant à un objet. Elle doit être appelée au sein d’une boucle.
Le plugin laisse donc la liberté au webmestre d’utiliser le mécanisme de compositions en fonction de son besoin propre.
Si par exemple, vous souhaitez que le cœur des pages articles change en fonction de la composition choisie (mais les colonnes latérales, l’en-tête et le pied de page seront inchangés), vous remplacerez la partie concernée de article.html par <INCLURE{fond=#COMPOSITION|compositions_selectionner{article}}{env}>.
Cette inclusion doit se trouver dans une boucle article dans ce cas.
Des icones pour vos compositions
Le plugin intègre dans le sous dossier images/ plusieurs icones simples que vous pouvez utiliser et décliner pour identifier vos compositions. N’hésitez pas à proposer vos variantes pour enrichir le plugin !
| Image | Code à utiliser |
|---|---|
|
<icon>images/objet-simple.png</icon> |
|
<icon>images/objet-liste-contenus.png</icon> |
|
<icon>images/objet-liste-contenus-dates.png</icon> |
|
<icon>images/composition-cours.png</icon> |
|
<icon>images/composition-tableau.png</icon> |
|
<icon>images/composition-test.png</icon> |
Discussions par date d’activité
71 discussions
Salut
Dans la configuration du plugin :
lorsque « Dossier des compositions » a le même nom que le dossier dans lequel sont déposées les compoistions, les pages de l’espace privé utilisant les compositions ne s’affichent pas.
Le plugin fonctionne si le nom du dossier de configuration et le nom du dossier des compositions ne sont pas les mêmes.
Exemples :
mes compositions sont dans le dossier squelettes/contenu/
dans la config du plugin je mets : « Dossier des compositions » : contenu/
et bien ça bug la page ?exec=rubrique ou article.
par contre si mes compositions sont dans squelettes/contenu/
et que dans la config du plugin je mets : « Dossier des compositions » : compositions/
et vbien ça marche.
En fait ça plante l’espace privé mais pas le site public
en fait ça plante dans la lecture des fichiers xml des compositions
Je précise ça plante quand apparait le fichier html associé à la composition (fichier qui fonctionne sous spip2) et même avec une boucle simple
Serait-il possible que la mutualisation empêche le fonctionnement du plugin ?
Car sur une installation sans mutualisation le plugin fonctionne.
J ai trouvé... le plugin compositions nécessite spip_bonux... qui corrige l’erreur Call to undefined function _T_ou_typo()
Répondre à ce message
Bonjour,
Je pense que j’ai un petit problème de compréhension des composition hérités car chez moi sous un spip3 RC, cela ne fonctionne pas comme je le souhaiterai. Je m’explique :
Imaginons que j’ai un livre qui comprend :
une racine -> livre
des sous-rubriques -> chapitres
des sous-sous rubriques -> sous-parties de chapitre
et des articles : des pages.
j’avais prévu de faire des compositions héritée :
pour le secteur
pour les chapitres
pour sous-chapitres
ce qui en resulte maintenant :
- les pages de la composition livres sont bien en héritage
- les chapitres de la composition livres également
- les pages de chapitres sont en composition par defaut, donc pas d’héritage
- les sous-chapitres sont en composition par defaut, donc pas d’héritage
- les pages de sous-chapitres sont en héritage « pages » si on a attribué la composition « souschapitres »
Auriez vous une idée de ce qui se passe ? Me suis-je planté quelque part ?
Merci
Je ne suis pas certain d’avoir tout suivi.
Si je comprends bien il y a dans le répertoire les couples XML/HTML suivant :
C’est bien ça ?
Passez d’abord à la version stable de SPIP 3 et vérifiez que vous avez la dernière version 3.1.0 de Compositions. => Le problème persiste-il ?
Quels sont les autres plugins utilisés / activés ?
Déjà, on peut simplifier. Si tous les articles deviennent des pages, gardez
<branche type="article" composition="pages" />uniquement dans rubriques-livres.xml.A priori, c’est votre composition rubrique-chapitres qui pose problème.
Avez-vous vérifiez qu’il n’y a pas de faute de frappe ?
Que se passe-t-il si vous appliquez manuelle cette composition ? L’héritage se fait-il ?
Cordialement
Bonjour Joseph et merci pour la réponse rapide :)
Alors oui tout a fait, les couples de compositions sont bien ceux que tu as décrit. J’ai bien éssayé de mettre la composition uniquement dans livre (ce qui est logique si on parle de « branche ») mais cela ne fonctionnait pas. Seuls des articles de la rubrique livre obtiennent l’héritage.
Les autres plugin installé :
- API de vérification 0.1.14 - test
- Autorité 0.9.12 - test
- CFG 3.0.0 - stable
- Champs Extras 3.0.6 - test
- Champs Extras (Interface) 3.0.3 - test
- Compositions 3.1.0 - test
- Contacts & Organisations 2.1.0 - test
- Coordonnées 2.0.1 - test
- Éditer Liens Simples 1.0.0 - experimental
- Pays ISO 3166-1 2.1.1 - stable
- Saisies pour formulaires 1.25.2 - test
- SPIP Bonux 3.0.0-dev - dev
- YAML 1.5.0 - stable
Je ne savais pas que la V3 de spip etait passé en Release (youpi !! et bravo !) je vais donc passer de mon coté en Release et je reviens vers vous pour vous dire si le probleme persiste.
J’ai bien vérifié au moins 10 fois si y avait pas de faute de frappe, ce qui est le cas a priori.
Juste à tout hasard :
Bon je viens de réinstaller SPIP en 3.0.1
Composition etait déjà en 3.1.0
j’ai redéfini mes compositions héritée comme suit :
Livre
chapitres
sous-chapitres
résultat :
Dans Rubrique Livre : j’ai bien le choix entre les 3 modeles de composition et les « pages » de livre sont en compo héritée
Dans mes chapitres : Jai bien le choix entre les 3 modeles et la rubrique est automatiquement en compo héritée « chapitre », mais les articles ne sont pas en « page » hérité, je dois les forcer
Dans mes sous-chapitres, j’ai bien le choix également, mais la compo « souschapitre » n’est pas hérité, je dois la forcer, et les pages des sous-chapitres sont là non plus en « page » héritée...
_
Dans chapitre je vois une compo souschapitre sans s et ensuite tu parles d’une compo souschapitres avec un S.
Ben par rapport au premier post, j’ai refais les compositions suite à la réinstallation pour repartir propre :
rubrique-livre(.xml/.html) :
rubrique-chapitre(.xml/.html) :
rubrique-souschapitre(.xml/.html) :
article-pages(.xml/.html) :
J’ai raté un S ?
OK,
j’ai finalement trouvé le fautif (c’était un peu dur après les modifs du plugin réalisées pour l’héritage des mots clés).
Normalement, ça devrait être corrigé en version 3.1.1 (il faudra attendre la mise à jour du zip)
Joseph,
Alors 1 : Merci beaucoup pour ton aide précieuse
2 - finalement j’étais pas fou :)
3 - Pour ma culture G, une petite explication du problème ?
Merci encore
La correction http://zone.spip.org/trac/spip-zone...
Il y a deux mois, cy_altern a fait évoluer le code de calcul des héritages pour essayer de le généraliser à d’autres objets. Malheureusement il y avait deux petites erreurs :
Ok, j’ai regardé le diff pour reporté de mon coté les modifications sur compositions_fonctions.php.
Depuis en effet y a du bien mieux, l’attribution d’héritages des articles pages fonctionnent partout dans Livre/chapitre/sous-chapitre.
Concernant les rubriques chapitre, elles héritent bien de la composition « chapitre ».
Concernant les sous-chapitres dont la branche
<branche type="rubrique" composition="souschapitre" />est définie dans « chapitre », elle est ignorée. Elle apparait bien dans les choix possibles de compositions, mais l’héritage se fait en « chapitre ».Ceci dit je peux me débrouiller sans (car mes chapitres et sous-chapitres ont quasiment la meme structure), Mais je pense qu’il y a encore un petit souci.
Merci encore
Oui, il manquait encore l’activation correcte de l’héritage sur les rubriques (la correction était passée à l’as ??)
Normalement devrait être bon en 3.1.2
Répondre à ce message
Salut !
Avez-vous le plan pour développer le plugin pour SPIP 3 ?
Serge
La version du plugin pour SPIP 3 est déjà fonctionnelle et disponible, voir http://plugins.spip.net/compositions.html
Sauf erreur, la version pour Spip 3 nécessite Spip-Bonux, mais cela n’est pas précisé.
Répondre à ce message
Bonjour,
Je n’arrive pas à installer article_accueil. Je pose le répertoire sur le site, dans plugins, je ne le retrouve pas dans la liste des plugins.
(j’en ai installé d’autres sans problème, dont compositions_V2)
Je souhaite mettre en accueil certains articles de mes rubriques.
Comment dois-je procéder ?
Merci d’avance de vos réponses.
Philippe
Répondre à ce message
Bonjour,
J’ai beau chercher, je ne comprends pas d’ou vient mon problème.
Sur une install toute fraiche d’un SPIP 3-beta2, + dernieres versions des plugins composition (v3.0.1 test) et dépendances.
- Je créé mon xml article-toto.xml , mon squelette article-toto.html, les places dans mon dossier « compositions » dans l’extension « dist » de spip 3.
- j’arrive bien a voir les compos à sélectionner sur l’article dans le backoffice. je l’active.
mais à partir de la.... ben le squelette n’est pas chargé dans la partie publique et reste avec celui par defaut de l’extension « dist/article.html », comme si il surchargeait ma composition.
pourtant, l’enregistrement est bon car si j’affiche ma #COMPOSITION dans ce meme squelette par defaut, j’ai bien mon « toto » qui apparait.
Une idée quelqu’un ?
Juste au préalable :
Cordialement
PS : vous ne devriez pas mettre vos fichiers personnels dans une extension ou un plugin, mais utiliser le répertoire squelettes.
Cordialement
Bonjour et merci de votre aide :)
Oui il y a bien d’autres plugins activés, mais j’avais aussi effectué les tests sans ces plugins avec le même résultat.
Pour info donc :
- Agenda 3.5.1
- API de vérification 0.1.12 - test
- Champs Extras 3.0.5 - test
- Champs Extras (Interface) 3.0.2 - test
- Saisies pour formulaires 1.21.2 - test
- YAML 1.5.0 - stable
Souhaité également mais désactivé pour l’instant :
- mots techniques 1.0 .0-dev - test
- motus 1.0.0 - stable
Le cache est vidé et même désactivé (je bénis cette fonction :) )
Le dossier de composition est bien déclaré et même trouvé apparemment (supposition) puisque si je le renomme, le formulaire de composition dans les objet me cite la compo, mais ne me propose plus la sélection de la composition.
Pour le reste de la configuration, rien de particulier à signaler (a mon sens), cette installation est vraiment toute fraiche. Concernant le dossier des squelettes, j’ai aussi testé de le mettre dans « squelettes », « squelettes-dist », à la racine sans plus d’effet.
Ok je vais essayer de reproduire et je reviens
Devrait être réglé avec la dernière version 3.0.2 (à vérifier).
un Enorme merci :) !
c’etait en effet a priori cela, car tout fonctionne :)
Répondre à ce message
J’ai cette erreur avec SPIP 2.1.12 et compositions 2.1.6
Fatal error : Only variables can be passed by reference in /home/conc5987/public_html/plugins/compositions_v2/inc/compositions.php on line 47
Lorsque j’enlève article-nonlogo.xml, dans squelettes/compositions l’erreur disparait mais je ne peux utiliser composition.
Voici le contenu de article-nonlogo.xml
Bonjour,
Pouvez-vous vérifier l’encodage de votre fichier ? Peut-être est-ce lui qui pose problème à composition. Il faudrait, dans l’idéal, qu’il soit en UTF-8
Merci pour cette réponse rapide. En effet, je suis retourné dans Notepad++ à la page article-nonlogo.xml et j’ai choisi Encoder en UTF8-sansBOM (celui qui ne fonctionnait pas était en UTF-8).
Maintenant le tout fonctionne.
Merci
Répondre à ce message
Dans une composition héritée aux rubriques, je cherche à identifier la plus haute parente dotée de la compo, pour pouvoir la traiter légèrement différemment. Comment faire ?
Il faut utiliser le critère
{!composition}— et non{composition}— pour filtrer les rubriques dotées d’une composition. N’est-ce pas un bug ?Utilisé sur une boucle HIERARCHIE (comme ceci :
<BOUCLE_parente(HIERARCHIE){id_rubrique}{tout}{!composition}>) ça casse le critère{tout}, ce qui ne permet plus d’attraper la rubrique en cours.Mon premier réflexe serait de faire deux compositions : rubrique-parent et rubrique-enfant en précisant que les descendants de rubrique-parent héritent de rubrique-enfant.
Sinon, a priori, le critère
{!composition}sélectionne les rubriques n’ayant pas de composition définie explicitement. Je connais pas assez finement la boucle HIERARCHIE mais je suis pas sûr que ce soit sur cette boucle qu’il faille mettre ton critère car la rubrique avec la composition ne sera pas sélectionnée. Et si on met un critère{composition=truc}, alors, si truc en appliqué à une sous-rubrique du secteur, le secteur ne sera pas sélectionné et donc on n’aura pas les enfants...Quelque chose comme ça fonctionnerait-il ?
Non, il n’y a vraiment pas lieu de faire une nouvelle compo juste parce qu’il y a une balise différente :P surtout que ça ne facilite pas la mutualisation CSS :P
Ca ne marche pas. Je viens de re-essayer à l’instant : le critère
{!composition}qui ne fonctionne plus comme avant.Attention. Quand on écrit le critère
{composition}cela veut bien dire (comme pour tout critère id_article ou autre) « qui a la même composition que dans la boucle englobante ».Donc si dans la boucle englobante il n’y a pas de composition, cela reviendra à sélectionner tous les objets sans composition. Cela peut paraître contre-intuitif, mais c’est le fonctionnement normal de tous les critères de SPIP.
Le critère
{composition}regarde la valeur du champ SQL composition dans la base de données. Alors que la balise#COMPOSITIONtient compte, le cas échéant, de la composition héritée par un objet ce qui n’est pas le cas du critère.Ce qui change avec l’arrivée des héritages c’est que la composition d’un objet n’est pas systématiquement la valeur du champ composition dans la table SQL. Si ce champ est vide, cela signifie qu’on n’a pas défini explicitement une composition pour cet objet et on regarde alors s’il en hérite une.
Autrement dit,
{!composition}signifie n’a pas de composition définie explicitement (ce qui n’interdit pas que l’objet hérite d’une composition).{composition}, comme le rappel Cédric, signifie a une composition définie explicitement identique à la boucle englobante.{composition=truc}signifie les objets ayant la composition truc définie explicitement (mais ne sélectionnera pas un objet ayant la composition truc par héritage).Dans ton cas, la rubrique parente aura ta composition définie explicitement (son champ composition vaudra truc si c’est le nom de ta composition). Pour cette rubrique,
#CHAMP_SQL{composition}vaudra truc. Les rubriques enfants hériteront de la composition truc par héritage.#CHAMP_SQL{composition}sera donc égal à vide.Dans les deux cas,
#COMPOSITIONvaudra truc car cette balise tient compte de l’héritage. Donc, le plus simple pour savoir s’il s’agit de la rubrique parente (pour laquelle on a donc appliqué explicitement la composition) est de tester la valeur de#CHAMP_SQL{composition}.Toujours le même genre de problématique : comment affecter une composition identique à toute une branche, SAUF à la rubrique parente ?
J’ai affecté la composition « toto » à toute la branche 3 dont les nombreuses rubriques héritent. Ca marche. Mais comment affecter une composition différente à la rubrique parente de cette branche, la rubrique 3, laquelle devrait avoir la compo « toto-accueil » ??
Tu crées deux compositions : rubrique-toto et rubrique-totoaccueil (note, pas de tiret dans le nom d’une composition).
Tu définies l’héritage dans le XML de rubrique-totoaccueil :
<branche type="rubrique" composition="toto" />.Tu appliques la composition totoaccueil à la rubrique 3. Dès lors, cette rubrique aura la composition totoaccueil tandis que ses sous-rubriques auront la composition toto.
Amicalement
Yes ! Ca marche ! Merci beaucoup !
Par contre, c’est très embêtant, de ne pas pouvoir mettre de tirets :P
Heureusement que les underscore sont possibles !
Les compositions enfants (« toto ») ne doivent pas être utilisées seules (pas sans « toto_accueil »). Est-il possible d’empêcher leur affectation ?
Tu peux verrouiller les compositions. Seuls les webmasters pourront alors affecter une composition.
Je ne retrouve plus : comment déclare-t-on dans le fichier .xml que la compo est verrouillée ??
Autre souci, à la suite : le sélecteur CSS parent du body change avec la composition. Or j’ai besoin d’un sélecteur constant dans la branche, «
.toto», sur tous les objets, car l’habillage est homogène dans la branche, puis d’ajouter EN PLUS, lorsqu’il y a lieu, les sélecteurs des compos spécifiques de la branche : «.toto_accueil», etc.J’ai actuellement :
<body class="pas_surlignable[ (#ENV{type}|=={page}|non)[(#ENV{type})]][ secteur(#ID_SECTEUR)][ rubrique(#ID_RUBRIQUE)][ (#ENV{composition})]">et je ne sais pas très bien comment faire mieux.Peut-être serait-ce bien utile de pouvoir déclarer dans le fichier .xml quels sont les séleceurs CSS à utiliser pour chaque compo ?
Le verrouillage d’une composition se fait dans l’espace privé. Dans le formulaire CFG, tu peux décider de verrouiller toutes les compositions. Sinon, tu peux verrouiller les compositions d’une branche dans le formulaire composition de la rubrique parente. Enfin, il est aussi possible de verrouiller une composition au cas par cas sur un objet.
Rien ne t’empêche de modifier ton body pour ajouter
[(#COMPOSITION|=={totoaccueil}|?{' toto',''})]. Ça rajoutera la classe toto quand on est dans la compo totoaccueil.Une autre alternative, si les modifications sont minimes entre toto et totoaccueil, est de faire une seule composition toto. Tu testes ensuite dans le squelette la valeur de
#CHAMP_SQL{composition}. Cette dernière vaudra toto s’il s’agit de la rubrique mère de la branche, et elle sera vide pour toutes les sous-rubriques (c’est-à-dire en cas d’héritage).OK, merci.
Pour les sélecteurs, c’est exactement ce que j’aurais/j’ai fait, sans Compositions, à la mano. Mais y’a pas un moyen de récupérer plus systématiquement le sélecteur de la compo parente de la branche ? Car j’ai besoin de ça pour toutes les compositions du site...
Pour notre exemple, les différences entre « toto », « toto_accueil », toto_doc", etc., sont stylistiquement minimes mais leurs squelettes différent grandement.
Il va falloir compléter un peu l’API de compositions. Il y a eu d’autres demandes hier sur la zone concernant l’id_rubrique de la rubrique parente.
A vue de nez je vois pour le moment une balise #COMPOSITION_HERITAGE qui indiquerait, si la composition est héritée, l’id_rubrique de la rubrique parente et vaudrait rien sinon.
On pourrait ainsi tester si la composition est héritée avec
[(#COMPOSITION_HERITAGE|oui)]ET[(#COMPOSITION_HERITAGE|non)].Par ailleurs, on pourrait connaitre la composition de la rubrique parente avec
[(#VAL{'rubrique'}|compositions_determiner{#COMPOSITION_HERITAGE})]J’essaie de creuser ça ce soir.
Je suis bête. Il y aurait plus propre :
[(#COMPOSITION{rubrique,#COMPOSITION_HERITAGE})]Non, non il faut pas ajouter un truc compliqué comme ça en plus.
il faut simplement donner la main sur les classes fonction de la composition, via une balise ou un attribut class dans le xml des compositions, qui soit réinjecté sur le
<body>Je m’en occupe.
Bonjour
D’abord merci pour ce super plugin qui va beaucoup m’aider.
Je relance le sujet.
J’ai aussi besoin de la rubrique accueil différente des sous-rubriques.
Ça marche pour les sous-rubriques, mais pas pour les articles des sous-rubriques.
Dans mon fichier toto_accueil.xml :
branche type=« article » composition=« toto_accueil » /
branche type=« rubrique » composition=« toto » /
Dans mon fichier toto.xml :
branche type=« article » composition=« toto » /
branche type=« rubrique » composition=« toto » /
La composition des articles des sous-rubriques rubrique-toto.html reste article-toto_accueil.html
Merci
Les fichiers xml devraient être appelés comme les squelettes : article-toto_accueil.xml par exemple.
Existe-il une composition article-toto.xml / article-toto.html ?
Le fichier toto.xml devrait s’appeler rubrique-toto.xml
Cordialement
Oui, les fichiers dans le dossier « contenu » (je suis sous zspip) :
rubrique-toto_accueil.xml
rubrique-toto_accueil.html
article-toto_accueil.xml
article-toto_accueil.html
Les sous-rubriques :
rubrique-toto.xml
rubrique-toto.html
article-toto.xml
article-toto.html
J’ai vérifié, l’héritage marche pour la page sous-rubrique rubrique-toto.html, mais pas pour la page article-toto.html. La page reste article-toto_accueil.html.
C’est donc la ligne branche type=« article » composition=« toto » / dans le fichier rubrique-toto.xml qui n’est pas prise en compte...
Question bête mais quelle est la version de Compositions utilisée ?
Normalement, la question de ce problème d’héritage a été réglée dans la version 2.1.4 (http://zone.spip.org/trac/spip-zone...).
Alors ça doit être ça.
Ma version : 2.1.3
J’essaye dès que possible.
Merci beaucoup.
Toujours penser à mettre à jour un plugin à sa dernière version stable avant de poster ;-)
En toute amitié
Merci Joseph, le plugin fonctionne à merveille.
Répondre à ce message
Bonjour,
Le téléchargement du zip est cassé.
Pourriez vous le réparer ?
Merci d’avance :)
Le lien vers le ZIP est corrigé, et oui cette version est OK avec ZPIP :)
merci ;)
PS : j’ai essayé demandé sur les articles concernés...
oui mais comme je suis auteur sur tous les articles concernés, je vais pas aller répondre sur chaque :)
Répondre à ce message
J’ai un besoin récurrent de « redirection », que je ne sais pas du tout comment traiter avec ce plugin. Par exemple, j’ai une rubrique « Actus » dont
- la première page doit afficher une actu de chaque sous-rubrique
- puis, chaque sous-rubrique affiche les actus qu’elle contient, in extenso,
- chaque « actu » est un article SPIP, mais n’a pas de page propre.
Je crée donc les deux compos suivantes :
-
rubrique-actu.htmlavecrubrique-actu.xmlqui contient :-
rubrique-actu_chapter.htmlavecrubrique-actu_chapter.xmlqui contient :- et tout d’abord aucune compo d’article, puisqu’il ne faut pas afficher de page article dans cette branche. Mais...
Le problème : quand on appelle l’URL d’un article de cette branche (quand un rédacteur clique sur « voir en ligne », ou quand un internaute clique sur le lien diffusé via RSS) cela affiche une page article, qui ne devrait pas exister. Comment rediriger vers la page où celui-ci est affiché, c’est-à-dire vers la rubrique parente de l’article ?
J’ai essayé de faire une composition d’article, ici
article-actu.html, héritée dans la branche via<branche type="article" composition="actu" />, mais ce n’est pas satisfaisant :- avec Z, cela ne remplace que le coeur de page :(
- comment rediriger directement (toute la page) vers la rubrique mère de l’article ?
- comment fabriquer une telle compo, qui puisse servir de façon générique dans toutes les rubriques construite de même (blog, glossaire, etc.) où les articles sont affichés in extenso dans le skel de rubrique, et ne doivent pas exister en solo ?
Bonjour Romy,
Premièrement, Compositions ne gère les redirections d’objet. Ensuite, il y a quelque chose que je ne comprends pas. Pourquoi y a-t-il des URL sur ton site qui pointent vers ces articles alors que ces articles ne sont pas censés avoir de page propre ? Il me semble que c’est en amont qu’il y a une correction à faire.
Ensuite, si un petit malin veut quand même taper une URL d’article, tu peux éventuellement faire une composition
article-actu.htmlavec dans contenu un texte du genre : Vous allez être redirigé vers cette page... et tu personnalises le<head>de la page (un squelettehead/article-actu.htmldans lequel tu inclus une meta<meta http-equiv="refresh" content="0;URL=#URL_RUBRIQUE" />ce qui devrait normalement assurer une redirection.Amicalement
Excuse moi pour le premier élément de réponse (existence d’URL pointant vers les articles). Effectivement, il y a le cas des rédacteurs qui cliquent sur voir en ligne. Par contre, pour le flux RSS, ne serait-il pas plus propre qu’il pointe directement vers les rubriques ?
bonsoir à toutes et à tous.
pour ce qui est de retrouver la rubrique, depuis la prévisualisation de l’article, je passe par le code suivant qui surcharge /squelettes/article.html
il est fonctionnel chez moi, et j’utilise la même astuce pour la recherche a l’interieur de la boucle recherche article...
Donc la boucle hierarchie comprend le critère composition...
et BOUCLE_selon_compo si composition trouvé va sur une vue rubrique sinon article.
Merci du retour, je dois sortir et reprendrais tard ou demain à la fraiche.
re-bonsoir,
Le principe du code ci-dessus fonctionne seulement sous SPIP et pas sous Zpip. Donc ne marche pas dans le cas de Têtue. Pardon pour le bruit.
@anic : j’avais effectivement mis en place une redirection dans ce goût là, à la racine du dossier squelettes. C’est effectivement risqué de faire ça sous Z, mais surtout ça ne permet pas d’appliquer les bonnes redirections selon les branches !
- Certaines branches, comme précédemment exposé, doivent fonctionner sans squelette d’article
(branches ’actus’, ’glossaire’, ’documents’, ’trombinoscope’, etc.) ;
- d’autres, à l’inverse, doivent n’afficher que des pages, sans rubrique intermédiaire
(branches ’présentation’, ’à propos’, ’contacts’, etc.) ;
- et d’autres, plus classiquement éditoriales, les deux
(branches ’dossiers’, ’rubriques’, etc.).
Bref, un site, quoi :)
Comment faire cela ?
@Joseph : les URLs d’articles doivent continuer d’exister ! C’est l’adresse de la ressource !! Je voudrais seulement pouvoir les faire pointer vers la page où est l’article est effectivement consultable...
D’une part parce qu’elles sont nativement diffusées par SPIP via les flux (
backend.html,distrib.html, etc.). C’est une bonne chose et je ne voudrais pas en arriver à devoir les personnaliser aussi, via d’éventuellement « compositions de flux »...Et à plus forte raison parce que les rédacteurs peuvent changer de composition : un article qui avait hier une compo l’affichant en solo et le linkant dans l’arborescence — c’est-à-dire dont l’URL existe déjà au point d’être linkée depuis d’autres sites — peut changer de compo du jour au lendemain et se retrouver affiché via la compo
rubrique-actu.htmldécrite plus haut. Son URL ne doit être brisée pour autant, mais pointer vers la page où consulter l’article, ici highlighté parmi d’autres, non ?Comment construire la bonne navigation et garantir la pérennité des URLs avec Z + Compositions ?
Comme suggéré précédemment, il est possible de procéder à une redirection HTML.
Bien amicalement.
Je n’ai pas trouvé comment mettre en oeuvre cette redirection en synchro avec l’affectation des compos. Il y a certainement un truc, mais je n’ai pas percuté.
En attendant, j’ai débloqué la situation en faisant un squelette par type d’objet, dans le bloc Z
/content(article.html,rubrique.html, etc.) qui contient seulement :<h1><code>#SQUELETTE</code></h1>
<p class=« error »>Aucun gabarit <code>/content</code> pour construire cette page !</p>
Ce n’est évidemment pas satisfaisant, mais ça évite d’arriver nulle part et ça le mérite d’informer ;)
Tu peux affecter une compo
article-redirectaux articles concernés via le mécanisme des héritages.Il te faut également définir le fichier
content/article-redirect.xmlpour que cette compo d’article soit valide.Tu définies alors le fichier
content/article-redirect.htmlqui contiendra un texte du genre Vous allez être redirigé vers la bonne page.. Cela définit le contenu de l’article.Mais on peut également définir un second fichier
head/article-redirect.htmlqui lui va contenir un en-tête de page personnalisé. Du coup, dans cette en-tête de page, on peut inclure :On obtient ainsi une redirection HTML..
J’ai trouvé pourquoi la redirection ne fonctionnait pas : il faut déclarer «
head» comme étant un bloc Z !!Ca marche ! Et c’est mieux :)
Mais ça reste gênant car ça fait effectivement une redirection (en affichant la page intermédiaire pendant un court laps de temps, avant d’afficher la bonne page, ce qui est suffisant pour interloquer). Une inclusion serait préférable, qui permettrait de pointer directement sur la bonne page, de façon transparente pour l’internaute (comme cela se fait très bien hors Z et Compositions).
Sauf qu’avec une inclusion ça ne modifie pas l’URL dans le navigateur. Ce n’est donc pas une redirection.
Si tu tiens à une inclusion, il te faut personnaliser le fichier
article.htmlà la racine. Tu peux faire un test du genre[(#COMPOSITION|=={redirect}|oui) ..... ]et tu appelles alors le squelettestructureavectype=rubriqueet le bon id_rubrique qui va bien, sinon, tu lance l’appel standard.Répondre à ce message
Hello
Actuellement le critère composition ne fonctionne pas avec les composition héritées : par exemple :
- je défini une rubrique 1.1 (fille de la rubrique 1)
- via le noizetier je dis que les sous rubriques de la rubrique 1 héritent de la composition machin...
la boucle
ne renvoie pas la rubrique 1.1
Est-ce une évolution/correction envisageable, compliquée ?
Parce que techniquement, le champs composition dans la table SQL est vide.
Il faudrait du coup créer un nouveau critère qui calculerait les id des objets héritant de la compo en question et ajouterait un critère IN dans la requête SQL.
Ca demande un peu de boulot.
Pas grave ce n’est pas très important
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 :
|
