Polyhiérarchie

Ce plugin permet de rattacher un article ou une rubrique à plusieurs rubriques parentes.

Hiérarchie unique ou multiple ? les deux !

Une unique rubrique, sinon c’est le bazar !
Par défaut, SPIP ne permet qu’une hiérarchie simple, qui consiste à associer chaque élément éditorial à un unique parent. Ceci résulte d’une volonté de contraindre le webmestre à structurer son site sainement.

En effet, le besoin de faire apparaître un contenu à deux endroits du site relève souvent d’une classification pas aboutie et d’une navigation mal pensée. Contraindre le webmestre à choisir une unique rubrique l’oblige donc à un minimum de réflexion sur l’arborescence du site, et évite la tentation des liens transverses multiples qui conduisent rapidement au capharnaüm.

Ainsi par défaut, SPIP ne permet de fabriquer que des sites bien rangés, avec une arborescence dont la hiérarchie stricte permet de ne pas se perdre.

Mais la polyhierarchie, c’est bien utile...
On parle de polyhierarchie [1] dès lors qu’un contenu est rattaché à plusieurs parents.

Il est parfois impossible de classer certaines données en arborescence, tel que le propose SPIP, sans perdre beaucoup en terme de compréhension ou de navigation. Pour illustrer un tel besoin, on peut lire les discussions sur la catégorisation hiérarchique dans Wikipedia qui en arrive à la conclusion que les liens hiérarchiques n’ont pas leur place dans une encyclopédie digne de ce nom, ou apprécier le cas, plus trivial, du classement de recettes de cuisine qui sont liées chacune à plusieurs ingrédients, à plusieurs type de plat, etc.

Dans ces cas-là, l’arborescence stricte imposée par SPIP est une limite gênante et les contournements habituellement utilisés (article virtuel, alias d’article, recopie de l’article) sont plus ou moins adaptés, plus ou moins pratiques et souvent lourds à l’usage.

Principe du plugin polyhierarchie

Le plugin permet de créer des liens hiérarchiques transversaux en rattachant articles et rubriques à plusieurs rubriques.

Dans la base de données, chaque article et rubrique conserve son unique parent principal, ce qui permet de désinstaller le plugin sans dommages pour le site.

Les liens secondaires vers les autres rubriques sont stockés dans une table annexe. Ils sont utilisables via des critères de boucle spécifiques.

On peut donc parler, pour chaque objet

  • d’une arborescence principale, qui permet d’accéder le plus directement au contenu. On appellera “liens directs” les liens qui constituent cette arborescence principale. Ce sont les liens en trait continus sur l’exemple ci-dessus.
  • d’une ou plusieurs arborescences complémentaires ou secondaires qui permettent d’accéder au contenu de façon indirecte. On parlera de liens indirects. Ce sont les liens en traits pointillés sur l’exemple ci-dessus.

Les termes « direct » et « indirect » seront utilisés dans les critères pour distinguer les deux types de liens pour les parents et les enfants.

En résumé, on peut retenir que les liens directs constituent l’arborescence principale de SPIP, qui est maintenue, même en l’absence du plugin. Les chemins secondaires constitués des liens indirects sont des navigations complémentaires ou transversales, qui ne seront utilisables que si le plugin est actif.

Utilisation dans l’espace privé

Dans l’espace privé, l’arborescence principale reste la référence. Mais les liens indirects permettent des navigations transversales utiles pour l’organisation du site.

Édition d’un article ou une rubrique
Lors de l’édition d’un article ou d’une rubrique, le sélecteur de rubrique par défaut est remplacé par un système de sélection multiples.

La première rubrique de la liste est celle de l’arborescence principale. Les suivantes constituent l’arborescence secondaire. Il est possible de changer l’ordre des rubriques par simple glisser-déplacer pour modifier la rubrique parente directe.

Le lien « ajouter » permet de faire apparaitre le navigateur de rubrique pour sélectionner une rubrique supplémentaire.

Il suffit de cliquer sur le « + » en regard d’une rubrique pour l’ajouter aux parents sélectionnés.

Le champ « Ajout rapide » permet d’indiquer un id_rubrique pour l’ajouter sans chercher dans l’arborescence. Il suffit d’entrer rubX (où X est l’id_rubrique) dans le champ et de cliquer sur Ajouter.

Chemins secondaires
Lorsqu’un article a plusieurs parents, le chemin affiché en haut est celui qui constitue l’arborescence principale. Les parents indirects sont également listés après la mention « Egalement dans les rubriques ».

Les liens permettent d’aller vers ces rubriques parents secondaires.

Contenus secondaires d’une rubrique
Dans une rubrique qui contient des enfants indirects, ceux-ci sont listés dans la marge latérale.

Comme précédemment, les liens permettent de naviguer vers ces contenus secondaires pour les modifier.

Utilisation dans les squelettes

L’utilisation de la polyhierarchie suppose que les squelettes soient conçus pour gérer les possibilités de navigation transversales. Pour cela, le plugin mets à disposition du webmestre plusieurs critères permettant de naviguer dans les arborescences multiples.

La boucle HIERARCHIE
La boucle HIERARCHIE n’est pas modifiée. Elle permet donc de dérouler le chemin principal d’une rubrique.

Le critère {branche}
Le critère {branche} est étendu. Il englobe par défaut les éléments liés indirectement aux rubriques de la branche, mais sans parcourir les rubriques enfants indirectes.

Dans une boucle RUBRIQUES, les rubriques rattachées indirectement à la branche directe seront donc inclues, mais pas parcourues (leurs enfants ne seront donc pas inclus)

<ul>
<BOUCLE_branche2(RUBRIQUES){branche #ID_RUBRIQUE}>
	<li>#ID_RUBRIQUE-#TITRE</li>
</BOUCLE_branche2>
</ul>
branche

Appliqué à la rubrique d' du schéma ci-dessus, le critère {branche} donnerait donc la liste b, g', f', h, e

Dans une boucle ARTICLES, les articles rattachés indirectement sont inclus, mais pas les articles enfants d’une rubrique rattachée indirectement.

Par ailleurs, l’écriture {branche #ID_RUBRIQUE} est acceptée.

Le critère {branche_complete}
Le critère {branche} est donc complété par un critère {branche_complete} qui inclut cette fois tous les contenus trouvés en parcourant toutes les branches principales et secondaires.

<ul>
<BOUCLE_branche_complete3(ARTICLES){branche_complete #ID_RUBRIQUE}>
	<li>#ID_ARTICLE-#TITRE</li>
</BOUCLE_branche_complete3>
</ul>
branche complete

Appliqué à la rubrique d' du schema ci-dessus, le critère {branche_complete} donnerait donc la liste b, g',a, c, f', h, e

L’écriture {branche_complete #ID_RUBRIQUE} est acceptée.

Le critère {branche_principale}
Symétriquement, le critère {branche_principale} permet de réduire la sélection aux éléments de l’arborescence principale uniquement. Ce critère permet donc de retrouver les enfants de la branche principale classique de SPIP.

branche principale

Appliqué à la rubrique d' du schéma ci-dessus, le critère {branche_principale} donnerait donc la liste g', f', h, e

Le critère {enfants}
Il permet de sélectionner les enfants d’une rubrique. Il peut s’utiliser sur une boucle RUBRIQUES, ARTICLES, ou tout autre boucle contenant un champ id_rubrique, même si la polyhierarchie ne s’y applique pas.

Il peut s’écrire {enfants} et prendra alors l’#ID_RUBRIQUE dans le contexte ou dans la boucle englobante, ou explicitement {enfants #ID_RUBRIQUE} ou encore {enfants #LISTE{12,23,36}} pour cibler plusieurs rubriques.

enfants

Appliqué à la rubrique d' du schéma ci-dessus, le critère {enfants} donnerait donc la liste b, g'

Le critère {enfants_directs}
Il fonctionne comme le critère {enfants}, mais permet de restreindre la sélection aux enfants directs.

enfants directs

Appliqué à la rubrique d' du schéma ci-dessus, le critère {enfants_directs} donnerait un seul résultat g'

Le critère {enfants_indirects}
Il fonctionne comme le critère {enfants}, mais permet de restreindre la sélection aux enfants indirects.

enfants indirects

Appliqué à la rubrique d' du schéma ci-dessus, le critère {enfants_indirects} donnerait un seul résultat b

Le critère {parents}
Il permet de sélectionner les parents d’une rubrique, d’un article, ou de tout autre contenu. Il ne peut s’utiliser que sur une boucle RUBRIQUES.

Il peut s’écrire {parents} et fait référence à l’élément de la boucle englobante, ou {parents #GET{id_rubrique}} et fait référence à la valeur passée, ou {parents #LISTE{12,23,36}} .

parents

Appliqué à la rubrique b du schéma ci-dessus, le critère {parents} donnerait donc la liste d, d'

Le critère {parents_directs}
Il fonctionne comme le critère {parents}, mais permet de restreindre la sélection aux parents directs (un seul dans la pratique !)

parents directs

Appliqué à la rubrique b du schéma ci-dessus, le critère {parents_directs} donnerait donc la liste d

Le critère {parents_indirects}
Il fonctionne comme le critère {parents}, mais permet de restreindre la sélection aux parents indirects.

parents indirects

Appliqué à la rubrique b du schéma ci-dessus, le critère {parents_indirects} donnerait donc la liste d'

Publication des rubriques

Par défaut, dans SPIP, une rubrique n’est visible dans l’espace public et dans les boucles que si elle contient des objets publiés.

Avec polyhiérarchie, à partir de la version 0.3.0 du plugin, si une rubrique ne contient aucun contenu direct, mais des articles ou rubriques indirects publiés, la rubrique sera alors publiée et visible dans l’espace public.

Pour résumer

Le plugin met a disposition tous les outils pour concevoir et développer avec SPIP des sites faisant appel à la polyhiérarchie.

Cela peut aller de simples cas où les articles sont ponctuellement présent dans une seconde rubrique, à des cas complexes faisant un usage avancé de la polyhierarchie.

Dans tous les cas, il convient de bien réfléchir préalablement à la classification des données du site, et de ne pas se précipiter dans une organisation approximative au prétexte que le plugin permet ensuite de faire des liens transversaux.

Le plugin met a disposition des outils et des possibilités, mais c’est au webmestre de veiller ensuite à l’usage qui en sera fait !

Et après ?

Cette première version du plugin a pour but d’évaluer le concept et les limites qu’il faudra lui poser éventuellement.

En fonction des usages il pourra être utile d’enrichir le plugin avec des possibilités de configuration (par exemple pour ne permettre la polyhierarchie que sur les articles), ou des contrôles de sécurité (par exemple ne pas mettre un contenu dans une rubrique et dans sa parente, ne pas créer de navigation circulaire ...).

Footnotes

[1La définition du terme est disponible dans la version allemande de Wikipedia (polyhierarchie), tandis que ce terme brille par son absence dans la version française de l’encyclopédie malgré un usage certain dans la langue française!

Ce plugin nécessite SPIP Bonux

Discussion

93 discussions

  • Cuisine-libre.org

    Toujours fan de ce plugin, j’essaye d’obtenir un tri, peut-être trivial, mais je n’ai pas trouvé comment faire : je souhaite ordonner une liste des enfants (directs et indirects), par exemple toutes les recettes contenant de la tomate, avec d’abord les enfants directs (recettes ayant la tomate comme ingrédient principal), puis les indirects ensuite (recettes contenant de la tomate secondairement). Une idée ?

    Reply to this message

  • 2

    Salut, je suis tristesse, je découvre que le critère enfants est tout bugué et génère une requête SQL tronquée qui fait que la boucle retourne des éléments non valides à la requête envoyée.

    Pour tester, une simple boucle comme celle-ci :

    <BOUCLE_dede(ARTICLES){enfants #LISTE{1}}>
    #ID_ARTICLE
    </BOUCLE_dede>

    En mode debug, on obtient la requête SQL suivante :

    SELECT articles.id_article, articles.lang, articles.titre
    FROM spip_articles AS `articles`
    WHERE (articles.statut = 'publie')
            AND 1=1
            AND ((articles.id_rubrique  IN (1)) OR (articles.id_article IN (SELECT * FROM(
    SELECT rl.id_objet
    FROM spip_rubriques_liens as rl
    WHERE (rl.id_parent  IN (1))) AS subquery)))

    Où l’on peut remarquer qu’il manque AND rl.objet='article' dans la subquery cf le code du critère https://git-mirror.spip.net/spip-contrib-extensions/polyhierarchie/-/blob/master/polyhier_fonctions.php#L68

    Ainsi, la boucle renvoie des articles qui n’ont rien à voir avec la requête, car la subquery va chercher les enfants de la rubrique passée en paramètre quel que soit leur type d’objet (article, rubrique, patate et autres).

    Si on regarde le code généré, toujours depuis le mode debug, on voit que AND rl.objet=\'$type\' est bien là cf :

    $command['where'] = 
                            array(
    quete_condition_statut('articles.statut','publie,prop,prepa/auteur','publie',''), 
    quete_condition_postdates('articles.date',''), array('OR',is_array($r=array('1'))?sql_in('articles.id_rubrique',$r):array('=', 'articles.id_rubrique', $r),array('IN', 'articles.id_article', '(SELECT * FROM('.sql_get_select('rl.id_objet','spip_rubriques_liens as rl',is_array($r=array('1'))?sql_in('rl.id_parent',$r):'rl.id_parent='.$r.' AND rl.objet=\'article\'').') AS subquery)')));

    Je soupçonne un problème avec une optimisation des jointures effectuée par le compilo, mais sans en être certain je n’ouvre pour l’instant pas de ticket sur le core...

    PS : testé en SPIP 4 git up et 3.2.11 stable.

    Reply to this message

  • 8

    Hello,

    Quelqu’un a-t’il une idée sur la façon de lister les rubriques parentes de plusieurs rubrique ?
    Un équivalent avec le critère enfants d’une condition de type id_rubrique IN a,b,...

    Cordialement,

    • Bon, je me répond à moi même : le critère n’existe pas voila comment je m’en suis sorti en :
      -  imbriquant 2 boucles pour la recherche des résultats
      -  utilisant une boucle POUR pour l’affichage de la liste d’article ?

      <BOUCLE_element(ARTICLES){id_rubrique IN a,b,....}>
          <BOUCLE_element2(ARTICLES){enfants}>
                #SET{element, #ARRAY{id_objet,#ID_ARTICLE,date,#DATE}}
                #SET_PUSH{elements,#GET{element}}
          </BOUCLE_element2>
      </BOUCLE_element>
       
      <BOUCLE_items(POUR){tableau #GET{elements}}{!par date}{pagination 10}>
          [(#INCLURE{item_article,id_article=#VALEUR|table_valeur{id_objet}})]
      </BOUCLES_items>

      Qui trouve mieux ?

    • Calomnie !

      Tu peux écrire les critères {enfants #LISTE{12,23,36}} pour avoir tous les enfants des rubriques 12, 23 et 36, et idem avec le critère parents : {parents #LISTE{12,23,36}}

    • Ho ! Mais c’est super ça !

      Je ne connaissait pas cette pratique. ça mériterait d’être mis dans la doc, non ?

    • Et voilà, je viens d’ajouter la précision dans le paragraphe du critère enfants.

    • merci b_b. J’ai juste corrigé la balise code qui était fermée dès l’ouverture.

    • Ha bien vu Maïeul, thx :)

    • À mon tour j’ai complété la doc de {parents}.

    • Merci vous 3 !

    Reply to this message

  • 2

    problème de publication avec v3.7.0
    J’avais fait la maj il y a quelques jours et aujourd’hui, il m’était impossible d’enregistrer un nouvel article. j’obtenais le message
    Il y a 1 erreur dans votre saisie, veuillez vérifier les informations.
    Après avoir supprimé la v3.7.0 et réinstallé la v3.6.13, tout refonctionne correctement.
    Je suis sur SPIP 3.2.8 [24473]

    Reply to this message

  • 3

    Bonjour,
    Je rencontre un problème fonctionnel à l’utilisation de ce plugin et “accès restreint”.
    J’ai deux rubriques : rubrique A et rubrique B au même niveau d’arborescence.
    Rubrique A est à accès restreint
    Rubrique B contient des articles de la rubrique A (principe de polyhierarchie)

    Lorsque l’utilisateur n’a pas les droits d’accès à la rubrique A, les articles dans la rubrique B ne sont pas affichés alors qu’associés à rubrique B.

    Avez vous déjà rencontrés le problème ? Y a t-il une solution ou un paramétrage ?
    Merci à vous.

    • up up svp
      MERCI

    • il vaudrait mieux demander dans les forums d’accès restreint,.

    • J’ai touvé un contournement, le mieux est d’avoir une rubrique vivier d’articles et de les polyhierarchisés dans les rubriques visibles en front. Ainsi vous avez, un vivier sans accès restreint et une arbo publique de rubriques et articles polyhierarchisés avec accès restreint. A dispo si vous avez des questions.
      ++

    Reply to this message

  • 1

    Bonjour,
    Auriez vous une idée pour permettre de définir un rang (ordre de tri) manuel pour les articles polyhiérarchisés d’une rubrique ?
    Merci à vous
    ++

    • Petit up, avez vous déjà réalisé ce genre de custom ou une combinaison de plugin ?
      Merci à vous
      ++

    Reply to this message

  • 1
    pagetronic

    Un grand merci à Cédric Morin pour ce formidable plugin qui devrait être intégré à SPIP par défaut.

    Merci!

    Je l’utilise partout depuis très longtemps et il est pour moi indispensable !

    • Cela méritait d’être dit ! Super PLUGIN !! Cela fait de spip une solution tellement souple et facile de déploiement. Merci

    Reply to this message

  • Bonjour,

    Encore moi !

    Sur le site actes-de-lecture.org je mets en ligne une revue pédagogique avec le squelette Éditorial (HTML5UP).

    J’ai une rubrique “Par numéro” et une autre, que j’aimerais faire “Par thème”.

    J’utilise le plugin “Polyhierarchie” mais je n’arrive pas à afficher les articles classés dans les thèmes. Quel fichier modifier ?

    Merci de votre aide.

    Robert

    Reply to this message

  • Bonjour,
    Il me semble qu’il y a un petit problème : dans l’espace privé lorsqu’on est au niveau d’une rubrique, les articles qui y sont attachés par le plugin Polyhiérarchie n’apparaissent pas. Ou plutôt chez moi, sous “Tous les articles publiés dans cette rubrique” c’est la totalité des articles qui sont affichés...
    Sous SPIP 3.2.5, plugin mis à jour.
    Merci

    Reply to this message

  • Bonjour,

    Rafale de messages d’erreurs en partie privée :

    Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/11/.../AFL_Athletes/plugins/auto/polyhier/v3.6.10/polyhier_pipeline.php on line 41

    Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/11/.../AFL_Athletes/plugins/auto/polyhier/v3.6.10/polyhier_pipeline.php on line 41

    Warning: Cannot modify header information - headers already sent by (output started at /homepages/11/.../AFL_Athletes/plugins/auto/polyhier/v3.6.10/polyhier_pipeline.php:41) in /homepages/11/.../AFL_Athletes/ecrire/inc/actions.php on line 147

    Que faire ? Que faire ?

    Merci

    Robert

    Reply to this message

Add a comment

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 / PostgreSQL
  • 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 apparait.

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.

Who are you?
[Log in]

To show your avatar with your message, register it first on gravatar.com (free et painless) and don’t forget to indicate your Email addresse here.

Enter your comment here

This form accepts SPIP shortcuts {{bold}} {italic} -*list [text->url] <quote> <code> and HTML code <q> <del> <ins>. To create paragraphs, just leave empty lines.

Add a document

Follow the comments: RSS 2.0 | Atom