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>
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>
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.
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.
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.
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.
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}} .
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 !)
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.
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 ...).
Discussions par date d’activité
97 discussions
Hello
J’ai un souci avec ce plugin et les doublons. Voici le contexte :
J’ai une première boucle ARTICLES qui exclut les articles avec certains mot clés et avec le critère
{doublons}J’ai ensuite une deuxième boucle ARTICLES avec les critères
{enfants}et{doublons}Jusque-là tout va bien, ça m’affiche bien les articles rattachés indirectement.
Mais si je mets une troisième boucle ARTICLES avec les critères
{enfants}et{doublons}, là je n’ai plus les articles rattachés indirectement. Si j’enlève le critère{doublons}des 2 dernières boucles, les articles rattachés indirectement s’affichent.Répondre à ce message
Bonjour,
Sur un Spip 4.1.5 en php 8.1.6, j’obtiens l’erreur suivante
table_objet_sql(): Argument #1 ($type) must be of type string, null given, called in /plugins/polyhier/v4.0.0/polyhier_fonctions.php on line 127lors de l’utilisation du critère
{parents}dans une boucle RUBRIQUES.Répondre à ce message
Salut,
je suis grand fan de ce plugin que j’utilise pour des pages multilingues alliant « chaînes de langue » et traductions dans diverses langues.
Bref, pour un passage en 4.1 de SPIP, je me demandais si un portage était prévu.
Sinon, je réfléchis à comment avoir un effet similaire autrement (mais je ne trouve pas ;) )
Au milieu de tous ces beaux plugins, je passe parfois à côté de certaines choses...) (J’ai essayer avec duplicator, mais il faudrait dupliquer à chaque fois la dernière version et remplacer dans les autres rubriques, ça passe pas)
Si quelqu’un·e a une approche autre, je suis preneur.
Comme d’hab, merci pour tous ces plugins et le boulot sur SPIP en général...
Humm, après un nouveau tour sur les plugins, une nouvelle idée que je partage si ça peut servir.
Dans mon cas (pages multilingues alliant « chaînes de langue » et traductions dans diverses langues), je recherche à ce que ça s’affiche partout et donc le met dans toutes les rubriques de langues.
Mais je pourrais aussi le mettre dans aucune rubriques de langues avec le plugin « Pages uniques ».
Ainsi, je fais un lien vers cette page à travers le plugin « menu » et j’ai la même page, avec les chaînes de langues qui changent pour chaque rubrique de langue.
Certes, ça ne marche que pour cette configuration.
J’ai aussi pensé à texte qui s’afficherait selon un mot clé (via une boucle dans un article) avec un contenu qui serait unique dans la description du mot-clé. Si ça peut servir...
Répondre à ce message
Bonjour, je n’arrive pas à utiliser ce plugin. j’obtiens des :
Erreur SQL 1146
Table ’test.spip_rubriques_liens’ doesn’t exist
une idée de comment résoudre ce problème ?
Répondre à ce message
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 ?
Répondre à ce message
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 :
En mode debug, on obtient la requête SQL suivante :
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#L68Ainsi, 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 :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.
En effet il y avait un bug dans le code généré par le critère, uniquement quand on utilisait un tableau en argument du critère
{enfants}C’est corrigé par https://git.spip.net/spip-contrib-extensions/polyhierarchie/commit/4c6a62cfda8f735efe7d73ebe7904e4a7bb25a46
\o/ topito, merci mignon !
Répondre à ce message
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 ?
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 !
Répondre à ce message
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]
C’est corrigé avec la version 3.7.1, désolé du bug
Pas de souci.
Merci pour la réactivité et bonne année :)
Répondre à ce message
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.
++
Répondre à ce message
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
++
Répondre à ce message
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
Répondre à ce 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
Répondre à ce 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
Répondre à ce 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
Répondre à ce message
Bonjour,
j’utilise ce plugin depuis un moment déjà, il est super
Mais est-il possible de trier l’ordre d’affichage des rubriques dans le choix de celles-ci par titre et non par ID, j’ai cherché dans le plugin mais je n’ai pas vu où le tri est mis.
Je m’explique, dans l’exemple que vous avez sur la page au niveau de racine du site, il y a :
Vie du site
boisson
Céréales
j’aimerais avoir un truc du style
boisson
céréales
vie du site
Quelle version de SPIP et du plugin ? Car chez moi c’est deja par ordre alphabétique (sauf si les rubriques sont numérotés, dans ce cas cela suit l’ordre de la numéoration)
Bonjour,
merci de la réponse, (j’avais déjà posté mais il n’apparaît pas sans doute à cause de la coupure de courant même s’il me semble que j’ai enregistré avant)
le plugin est la 2.3.9 donc normalement la dernière
spip est en 3.0.21, il faut que je récupère mes modifs avant de le mettre à jour au cas où certains plugins dont je me sers ne soient plus compatible.
je crois que c’est quelque chose qui avait été modifié dans la 3.1.
Plutot que de passer en 3.2, si cela est problématique en terme de plugin, tu peux installer
Sélecteur de rubriques avec tri alphabétique.
Mais bon, la 3.0 est une branche finissante, donc ce serait effectivement pas mal de migrer à un moment vers la 3.2.
tu peux pour cela utiliser le þplugin de vérification de compatibilité des plugins.
Et dans tous les cas, sauvegarde etc.
Un énorme merci,
effectivement, je suis entrain de regarder mes plugins pour tout mettre à jour. Certains sont primordiaux pour moi.
Mais en attendant, je vais utiliser le plugin sélecteur.
Répondre à ce message
Bonjour,
une fois la liste des articles de la rubrique affichée est-il possible de faire un tri sur cette liste en selon les différentes rubriques secondaires de l’article ?
Voici ce que j’ai mis pour le moment :
Répondre à ce message
Bonjour,
sous SPIP 3.2.1 avec Polyhiérarchie 3.6.9, cache vidé, j’ai un problème d’affichage des logos des articles disponibles...
Répondre à ce message
Bonjour,
j’ai créé un site il y a 3 ans sur SPIP 3.0 que je dois basculer sur SPIP 3.2 pour des raisons de changement de serveur (et compatibilité avec PHP 7)
J’ai réussi à reprendre toutes les fonctionnalités du site à travers les différents plugins.
Pour PolyHiérarchie j’ai téléchargé la version 2.3.8 et j’ai un soucis avec la boucle suivante :
qui me sort une liste partielle de mes articles alors que sur la version 2.0.8 ça fonctionnait très bien.
Après qq essais, il semble que ce soit branche_complete #ID_RUBRIQUE qui pose problème (comportement différent) mais à confirmer (je n’ai pas creusé le code PHP)
Du coup, j’ai voulu remettre la version 2.0.8 mais je ne la retrouve pas.
Est-ce que ce changement de comportement vous parle ? Ou à défaut, qqn peut-il me dire comment je peux réinstaller l’ancienne version du plugin ?
Merci de vos conseils.
Cordialement,
Répondre à ce message
Bonjour,
Reprenant un site SPIP mais n’y connaissant pas grand chose, j’ai installé le plugin « polyhierarchie » pour pouvoir appliquer un article à plusieurs rubriques. L’objectif est d’avoir les dernières infos de ma rubrique « news » visible dans d’autres rubriques. Voir le site : www.agi-son.org
Mes infos :
Version SPIP : 2.1.16
Version plugin Ployhierarchie : 1.0.1
Version plugin SPIPBOnux : 2.3.0
RAS concernant l’installation, l’ajout de rubrique à un article mais l’article en question n’apparait pas dans la nouvelle rubrique sélectionnée...
Je n’ai pas touché au squelette....
D’avance merci pour votre aide !
Il faut toucher aux squelettes :)
C’est-à-dire : il faut donner, dans les squelettes, les instructions pour produire l’affichage souhaité. Sinon, cela ne change rien au site (et heureusement).
Bonjour,
Je suis dans le même cas que Com et que Raphaailes (message de janvier 2011 resté lui aussi sans réponse) et peut-être quelques autres : nous avons installé Bonux et Polyhiérarchie, tout fonctionne bien en espace privé mais rien ne change en espace public.
C’est bien gentil de nous indiquer qu’il faut « toucher aux squelettes » mais comme nous ne savons pas le faire, sur quel fichier le faire, quoi modifier dans le fichier, cela ne nous fait pas avancer d’un centimètre.
Est-ce contraire aux valeurs de SPIP que les « sachants » expliquent aux béotiens qui débarquent, acceptent de les prendre un peu plus par la main ?
S’ils veulent rester entre eux et n’accepter que les nouveaux ayant de fortes prédispositions à l’informatique, qu’ils continuent et restent entre eux mais s’ils veulent partager et répandre SPIP il faudrait qu’ils soient un peu plus indulgents et généreux dans les explications, dans l’attitude et en acceptant de « s’abaisser » au niveau de leurs interlocuteurs pour pouvoir les tirer ensuite vers le haut.
Si l’on demande à un débutant cycliste de commencer par une randonnée de 200km avec trois cols on est å peu près certain de le voir tourner les talons avant même de commencer ou au bout de 30km. Si on commence au contraire par 30km, il sera partant pour en faire 40 à la sortie suivante.
Je me sens dans cette position.
Cordialement,
Cassius
Bonjour Cassius,
Il y a des explications plus haut dans le paragraphe « Utilisation dans les squelettes »
Il serait bon aussi que vous appreniez(si ne n’est déjà fait) , préalablement, les mécanismes élémentaires de la boucle RUBRIQUES de SPIP et les utiliser.
Et tester ensuite les différents critères indiqués plus haut. Vous devriez pouvoir vous en sortir...
Bon courage !
Bonjour,
Non mais est-ce si dur que ça de prendre un moment pour expliquer à un nouveau l’explication qu’il a besoin CLAIREMENT ?
Vous dites tous qu’il faut aller voir les documentations, tels paragraphe, etc. Mais pensez-vous qu’on serait là a nous amuser a poser des questions inutilement sans avoir chercher dans les DOCUMENTATIONS et les FORUMS si on avait trouvé les réponses a nos question ?
Sans déconné les gars, nous les débutants, nous n’avons pas la science infuse. Et si vous voulez que SPIP soit plus connue, il faudrait que la communauté soit plus présent (pour répondre aux questions sur les forums et dans les commentaires de site comme ça non pas 10 000 ans plus tard mais le plus tôt possible), plus généreuse des les explications comme l’a dit Cassius. Si non tout le monde se barrera.
Cordialement.
Jhessy
À mon avis, vous pouvez
vousRépondre à ce message
Bonjour,
je relance une question : comment faire apparaître un article dans plusieurs rubriques.
J’ai compris qu’il fallait ajouter le critère branche_complete #ID_RUBRIQUE dans la boucle article du squelette.
Gros problème pour moi : je ne sais pas comment faire.
J’ai ouvert la page article.html dans le dossier squelettes-dist
J’ai copié le code et collé dans word.
J’ai rajouté [(ID_RUBRIQUE)branche_complete] tout en haut de la page (mais je ne sais pas du tout si c’est là ou si c’est la bonne formule à taper.
BREF, vous l’aurez compris, je n’y connais rien du tout mais j’ai vraiment fait des efforts.
Pouvez-vous m’aider s’il vous plaît
Merci
PS : Voici le code sur la page :
[(#ID_RUBRIQUE)branche_complete]
[(#REM) Cf. : http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ ] [] []
[(#REM) Contenu principal : contenu de l’article ]
<:accueil_site :>>[(#TITRE|couper80)][ > (#TITRE|couper80)]
[
(#SURTITRE)
]
[(#LOGO_ARTICLE_RUBRIQUE|image_reduire40,*) ]#TITRE
[
(#SOUSTITRE)
]
(#DATE(#DATE[, <:par_auteur :> (#LESAUTEURS)]
[(#REM) Inclure le modele des liens de traductions ] #MODELEarticle_traductions
[
(#CHAPO|image_reduire500,*)
] [
(#TEXTE|image_reduire500,*)
] [
<:voir_en_ligne :> : [(#NOM_SITE|sinon[(#URL_SITE|couper80)])]
] [
(#PS|image_reduire500,*)
] [(#REM) Gestion du portfolio et des documents ] [(#INCLUREfond=inclure/documents,id_article, env)] [(#REM) Petition : La petition ayant une PAGINATION il faut absolument env et pourquoi pas ajax ](#PETITION [
(#NOTES)
] [(#REM) Forum de l’article ] [
Un message, un commentaire ?
(#FORMULAIRE_FORUM)]
#FORMULAIRE_RECHERCHE [(#REM) Articles dans la meme rubrique ]
<:meme_rubrique :>
• #TITRE
[(#REM) Menu de navigation mots-cles ] #MODELEarticle_mots
Pourquoi personne n’a répondu à sa question ?
Je suis dans le même cas que lui.
J’imagine que pour les utilisateurs de SPIP aguerri, ils pourraient résoudre ce problème en moins de 2 ; mais non, personne ne fait l’effort de le répondre (ce qui aurait pu m’aider et d’autres débutants comme mois).
C’est ce qui m’énerve un peut dans cette communauté ; impossible d’avoir des réponse à ses question. Et quand bien même il y a une, la réponse est hyper mâché, pas complète, ou mal expliquée.
malheureusement ca va pas marcher avec mois, malgré il est trés utile.
Votre niveau d’incompréhension est trop élevé pour qu’on puisse vous répondre sans avoir à vous expliquer tout le SPIP.
Le critère se mets sur une boucle, pas sur une balise.
Répondre à ce message
Bonjour,
visiblement on ne peut pas utilise le critère parents dans une boucle condition
Comme ça ça le fait aussi bien :)
Répondre à ce message
Bonjour, je voudrais savoir si vous avez détecté un problème de conflit entre deux versions du plugin Polyhierarchie. J’ai installé la version 2.3.8 sur mon site mais quand je vérifie la presence du plugin sur l’espace privé, le système m’informe que la version 3.6.9 est aussi installé, comme le montre la copie d’écran ci jointe. Comment faire pour effacer toute trace de la version 3.6.9 du site ?
Il doit être encore présent dans le répertoire /plugins/auto
Répondre à ce message
Il y a eu micmac dans les mises à jour : je mets toujours à jour très régulièrement mes plugins + spip ; néanmoins, je viens de constater un bug sur la polyhierarchie et en creusant, j’ai vu que j’étais en V2.3.8 au lieu d’être en V3.6.*.
Bilan : j’ai du supprimer manuellement le répertoire 2.3.8 puis télécharger V3.6.9, puis activer et là mon bug est réglé
ça fait un bail que ce genre de micmac ne m’est pas arrivé alors que j’utilise SPIP depuis 2009 sur ce site et 2007 sur d’autres sites.
Répondre à ce message
Bonjour et merci pour ce plugins trés pratique.
Depuis la mise à jour du plugins V2.2.0 vers la version 2.2.2, j’ai des fenêtres rouges qui s’ouvrent avec une message d’erreur SQL de ce genre :
Erreur SQL 1241
Operand should contain 1 column(s)
SELECT mots.id_mot FROM spip_mots AS
motsINNER JOIN spip_mots_liens AS L1 ON ( L1.id_mot = mots.id_mot ) WHERE (L1.objet = ’rubrique’) AND (((L1.id_objet IN (181))) OR (L1.id_mot,id_objet,objet IN (SELECT * FROM( SELECT rl.id_objet FROM spip_rubriques_liens as rl WHERE ((rl.id_parent IN (181))) AND rl.objet=’mots_lien’) AS subquery))) AND NOT((mots.type = ’squelette_habillage’)) GROUP BY mots.id_motJ’ai réussi à revenir à la version 2.2.0 et je n’ai plus ces messages.
Une idée du problème ?
Merci pour votre réponse.
Même problème avec Polyhierarchy version 3.6.5 (SPIP 3.1.6, Sarka-SPIP 3.4.7), j’ai une erreur SQL 1241
Revenu à la version 2.3.4 du plugin : même erreur SQL 1241...
Merci de vos lumières...
Répondre à ce message
Bonjour tout le monde !
J’essaie de créer un moteur de recherche avec Polyhierarchie, mais, bon, euh, c’est chaud, quoi !
J’ai 2 rubriques, très liées l’une à l’autre en polyhierarchie.
Une première liste déroulante présente les titres des sous-rubriques de la rub1. Si je clique sur un des titres (sous-rub1), je souhaiterai n’avoir comme résultat dans ma liste déroulante n°2 que les résultats des sous-rub2 liées à la sous-rub1 appelée.
Vous me comprenez ? Vous auriez des pistes à me proposer ???
Merci !
Répondre à ce message
Bonjour
super le plugin !
Tout s’affiche bien dans le site public, mais...
Mais dans la partie privé, les « enfants indirects » ne sont pas listés dans la marge latérale... ???
Je publie l’article30 dans la rubrique 10. Ensuite je l’attache aussi à la rubrique 20.
Pas de problème, je vois bien les deux rattachements dans le chemin de l’article.
Puis je le vois bien dans la liste des articles de la rubrique 10
Mais je ne le vois nulle part, ni au centre, ni dans le panneau latéral, dans la rubrique 20.
Où est le pépin ? Comment faire ?
Merci beaucoup
Répondre à ce message
Bonjour, j’ai un soucis alors que j’utilise ce plugin depuis longtemps, très longtemps même …
Si je mets une rubrique dans une autre branche avec ce plugin, tout est nickel. Si je mets une rubrique dans deux autres branches (donc trois en tout en comptant la principale, et bien tchao, plus moyen d’afficher la page publique. Pourtant, j’ai respecté la présentation dans les squelettes. Avez-vous déjà essayé de mettre plus d’une branche polyhierarchie pour une rubrique ?
Cdt.
Répondre à ce message
Bonjour,
Avec les dernières version du plugins on peut pas mettre à jour les articles, problème déjà rencontrer ?
aucun probleme pour ma part de mise à jour avec polyhierarchie.
si je le désactive je peux tout faire mais si je le relance et valide un article il enregistre pas et reste sur la page.
est-ce que cela se pose sur spip brut + seulement polyhiéarchie ? parce que comme je dis « chez moi ca marche ».
Répondre à ce message
Suite à une montée de version (de SPIP 2.1.26 vers SPIP 3.0.17, avec polyhier 2.0.9), certaines de mes boucles polyhier ne s’affichent plus, sauf quand je retire l’un des critères polyhier (mais ça n’affiche pas ce que je souhaite, évidemment). Par exemple :
<BOUCLE_dossier(RUBRIQUES){enfants}{branche 20}{logo}{par num titre}>ne fonctionne que si je retire le critère{branche 20}, tandis qu’ailleurs dans le site<BOUCLE_dossier(RUBRIQUES){branche 20}{logo}{id_mot}{par hasard}{0,1}>fonctionne correctement.Je n’arrive pas à comprendre comment réparer… Y’a-t-il des bugs identifiés sur ces critères ?
J’ai fini par comprendre : les données correspondantes ont été perdues lors de la mise à jour, c’est pourquoi les contenus polyrattachés ne s’affichaient plus, tout bêtement :)
Répondre à ce message
Salut,.
est-ce que le tri dans l’ordre d’association d’une rubrique à un objet est une chose prévue ou pas ?
je veux dire prévue à terme...
Répondre à ce message
Bonjour,
demande particulière...
Comment serait possible « simplement » de ne pas utiliser le picker de polyhierarchie en partie publique grâce au formulaire éditer_article que j’ai surchargé dans squelettes/formulaires.
Tout en continuant de l’utiliser en partie privée ceci sans dommage collatéral.
Faut-il obligatoirement faire un CVT ?...
Merci pour vos pistes.
Cordialement.
Répondre à ce message
Bonjour à tous,
je fait une médiathèque dont certains articles doivent aller dans plusieurs catégories.
Or, le plugin polyhierarchie qui me conviendrait parfairement n’ouvre pas les sous-rubrique. Quelqu’un sait-il pourquoi ?
Si un article est placé à sa place,
Je peux mettre le polyhierarchisé :
1) Dans les rubriques racines
2) A l’aide du module de rapidité (rubXX) mais il faut connaitre le numéro de la rubrique.
N’étant pas le seul à gérer la médiathèque, il faurait que je puisse ouvir les sous-rubriques donc merci à la personne ou les personnes qui pourraient m’aider.
Désolé de re-commenter par dessus mais apparemment j’ai bien les sous-rubriques dans la poly-hierarchie des rubriques.
cela ne fonctionne donc pas pour les articles mais non les rubriques
Répondre à ce message
Bonjour,
il semble qu’il y ait un bug qui soit apparu avec l’introduction du Plugin « traduction rubriques autrement ».
En pièce jointe l’impression d’écran.
Bravo en passant pour cet excellent plugin qui rend de bien bons services !
Je précise que ça ne semble pas impacter sur les fonctionnalités...
Ce devait être un problème de cache (sur le serveur tmp/cache que j’ai tout à fait vidé) car je ne constate plus le problème...
Répondre à ce message
J’ai installé le plugin. RAS
J’arrive à attribuer deux rubriques pour un seul article.
Sauf que l’article n’apparaît que dans sa rubrique d’origine.
Une idée ?
Pas de message d’erreur, tout semble bien se dérouler. SPIP 3.0.16 et plugin en version 2.0.8
Répondre à ce message
Bonjour,
Je suis sur une SPIP 2.1 et polyhierarchie 1.0.0. (Je ne peux pas faire d’update en SPIP 3 pour le moment mais là n’est pas le sujet)
J’ai cette arborescence :
Un des adminsitrateurs/rédacteurs a modifié le parent de rub1530 pour être rub362. L’édition et l’enregistrement se font sans soucis (justement). La problème vient après quand on veut consulter la rub1530 ou la rub362 car on a une boucle sans fin entre ces 2 rubriques.
Il semble que polyhierarchie ne fait pas de vérification de id_rubrique et id_parent entre les rubriques. En tout cas dans la version 1.0 du plugin. Il semble que même la v2 du plugin ne le fait pas.
cf. http://zone.spip.org/trac/spip-zone/browser/_plugins_/polyhierarchie/branches/v1.0/formulaires/editer_polyhierarchie.php et http://zone.spip.org/trac/spip-zone/browser/_plugins_/polyhierarchie/trunk/formulaires/editer_polyhierarchie.php
Est-ce que vous avez rencontré aussi ce bug/comportement ?
Répondre à ce message
Bonjour,
Merci pour le plugin, solution qui parait simple
pour la mise en place de « multirubricage ».
J’ai fait un premier essai dans une boucle nav latérale.
Y a un détail qui me pose probleme : lorsque je clique sur un article indirect,
je me retrouve dans la rubrique d’origine.
Pour rendre plus clair mon propos :
j’ai 2 rubs avec
Eté : Parapente, Canoé et Rando
Hiver : Ski, Raquettes et Rando
Rando étant dans Hiver un article indirect,
ainsi si je me trouve dans Hiver,
lorsque je clique sur Rando,
je me retrouve dans la rubrique Eté !
C’est, je trouve, un problème !
Y a-t-il une solution simple ?
Merci pour votre aide.
Bonjour,
je m’inscris dans le fil de cette question. Mon site tourne avec SPIP 3.0.13 et Polyhierarchie 2.0.7.
J’ai une rubrique qui n’accueille que des articles indirects. Lorsque je clique sur le lien d’un de ces articles, il m’envoie vers l’article dans son parent direct alors que je voudrais rester dans son parent indirect.
Par ailleurs, question 2, comment peut-on EXPOSER dans un menu tous les parents (direct et indirects) d’un articles ?
Merci pour votre aide.
Répondre à ce message
Bonjour,
Je rencontre une erreur SQL 1054 lorsque le plugin polyhierarchie est activé. Je n’avais pas cette erreur dans spip 2.12.
Cette erreur apparait sous tous les navigateurs lorsque je suis logué !
Le message d’erreur parle du fichier squelette : plugins/auto/sarkaspip_32/noisettes/rubrique/inc_rubrique_navigation.html, au niveau de la boucle _mots_branche.
<BOUCLE_mots_branche(MOTS){branche}{type!=squelette_habillage}{doublons}>Voici mes paramètres :
- version de SPIP : 3.0.10
- version du plugin testé et des éventuels plugins nécessités : PolyHiérarchie
2.0.4, SPIP Bonux 3.0.5
- version de PHP : 5.2.5
- version de MySQL / SQLite / PostgreSQL : MySQL 5.0.45
J’ai réessayé de changer le code type ! en mots.type, enlever doublons, changer branche en id_rubriques. Rien ne lève l’erreur. Merci par avance pour l’aide.
Bonjour,
Je reviens vers vous car je n’ai toujours pas de solution pour ce bug.
le message d’erreur apparait :
- quand je me logue et que je clique sur une rubrique qui a au moins une sous-rubrique (si aucune sous-rubrique, pas de bug)
- sous tous les navigateurs
le message d’erreur disparait :
- quand je fais F5 ou une actualisation de la page
- quand je désactive polyhierarchie (j’ai testé un à un tous mes plugins pour le trouver !)
Je veux bien un conseil pour m’aider à sortir de cette impasse. Merci
Bonne nouvelle, ce bug vient tout juste d’être corrigé par la version 2.0.7
Merci. Merci beaucoup.
Répondre à ce message
Il y a un bug assez gênant (version du plugin : 2.0.4).
J’ai une rubrique qui est à la racine du site d’une part et en sous-rubrique d’une autre, d’autre part, par le miracle de la polyhiérarchie.
Cette rubrique étant à la racine, contient des brèves.
Si je modifie la rubrique dans l’espace privé à l’aide du classique formulaire « Modifier cette rubrique », le champ « dans les rubriques » ne propose plus que la sous-rubrique et oublie la racine du site.
Si par malheur je valide à ce stade, pouf, je me retrouve avec ma rubrique qui reste en sous-rubrique, mais qui a perdu son statut de secteur à la racine. Je peux rectifier ensuite, sauf qu’entretemps il y a eu un effet collatéral très gênant : toutes mes brèves changent de secteur... et je n’ai plus qu’à les rapatrier une par une.
Je pense qu’il ne s’agit que d’un bug dans le formulaire de l’espace privé « modifier cette rubrique ». Je serais infiniment reconnaissant si un correctif pouvait être amené ;-)
Le bug est identifié. Malheureusement la correction n’est pas du ressort du plugin mais du core : http://core.spip.org/projects/spip/repository/revisions/20891 sera donc dans la prochaine release mineure de SPIP.
Répondre à ce message
Sous Spip 3.0.11, j’utilise le plugin polyhierarchie pour que des articles apparaissent dans plusieurs rubriques.
J’aimerais que :
- les pages rubriques qui ne contiennent aucun article affichent à leur place toutes les sous-rubriques de la rubrique mère.
- les pas sous-rubriques affichent les articles qu’elles contiennent y compris ceux qui appartiennent à plusieurs rubriques.
Mon problème est que je n’arrive pas configuer une boucle que les critères ci-dessus soient pris en compte.
En effet, si je modifie ainsi la boucle article du squelette rubrique :
les articles appartenant à plusieurs rubriques s’affichent bien dans toutes les rubriques, mais mes rubriques qui n’ont pas d’articles n’affichent plus les sous-rubriques.
A la place de l’affichage des sous-rubriques, elles affichent tous les articles.
Que faut-il que j’écrive dans ma boucle pour que :
- les rubriques qui n’ont pas d’articles affichent à la place les sous-rubriques ;
et que dans le même temps :
- les sous-rubriques affichent les articles qu’elles contiennent y compris ceux qui appartiennent à plusieurs rubriques.
Merci par avance pour vous aide,
Bien cordialement,
Thierry
Répondre à ce message
Bonjour,
Sous Spip 3.0.11, après avoir mis à jour le plugin, je rencontre ce message sur toutes les pages des articles dans l’espace privé (rien sur l’espace public) :
Warning : array_key_exists() [function.array-key-exists] : The second argument should be either an array or an object in /home/www/client/toto/www/plugins/auto/polyhierarchie_v2/polyhier_pipeline.php on line 61
Quelle est la cause et comment y rémedier ?
Merci pour votre aide,
Bien cordialement,
Thierry
En effet, il y a eu une correction maladroite qui a provoqué cela. Je viens de corriger, il suffit de mettre à jour le plugin pour que cela soit résolu !
Bonsoir,
Merci beaucoup pour le correctif, c’est parfait, plus aucun souci.
Répondre à ce message
Hop,
J’ai eu à tester des polyhiérarchies sur les articles. L’objectif était d’afficher une certaine hiérarchie (ou un certain titre de rubrique parente) en fonction de la rubrique principale de l’article. Si le titre de la rubrique principale est d’un certain nom, et qu’il existe une rubrique secondaire à cet article, alors c’est le titre du secondaire qui est affiché (sinon le titre principal). Oui, c’est un peu bizarre, mais c’est comme ça visiblement. J’ai testé sur un squelette différentes choses pour arriver à mes fins, et c’est ce que je livre là : il y a plein d’exemples que des gens pourrons repiquer :)
Il y a des hiérarchies pour Zpip-dist et pour Spipr-dist. Voilou. Et merci pour ce plugin :)
Répondre à ce message
Pour garder une trace d’IRC.
Je suis tombé sur un problème avec polyhiérarchie, un peu particulier. Cela concerne (au moins) les critères
{parents ID}.Le problème surgit lorsqu’on veut afficher les différentes rubriques d’un objet (un article en l’occurrence), mais que la boucle ayant le critère
{parents ID}n’est pas directement dans la boucle de l’objet, et particulièrement si elle descend d’une rubrique.Le critère teste actuellement
Cela fonctionne donc uniquement si la boucle parente est du même type que l’identifiant ID que l’on passe au critère. Du coup, dans certains cas ça va pas :
Exemple
Cet exemple fonctionne si on enlève la boucle « _rub_principale ».
C’était juste pour le signaler :)
Répondre à ce message
Bonjour,
Super plugin que j’utilise très souvent.
Question : Est-il possible d’avoir les critères « branche_directe » et « branche_indirecte » ?
Merci
Robert
Bah ils y sont ?!
http://zone.spip.org/trac/spip-zone/browser/_plugins_/polyhierarchie/branches/v2.0/polyhier_fonctions.php#L160
Répondre à ce message
« Mysql utilise bien la clé primaire sur la table spip_rubriques_liens, mais pour la partie spip_rubriques, c’est un scan complet de la table à chaque fois. Ca n’a l’air de rien, mais quand c’est fait plusieurs fois par seconde sur un gros site, ça impacte pas mal » peut-on lire en 2009 sur une liste de discussion spip.net au sujet de ce plugin (http://comments.gmane.org/gmane.comp.web.spip.zone/14165).
Je rencontre ce même problème « d’optimisation des requêtes mysql » avec donc des « slow logs » nombreux sur les boucles faisant appel à la polyhiérarchie. Avec le version 2.0.4 du plugin et spip 3.0.5.
Cédric, le problème mis en avant par Simon en 2009 (http://permalink.gmane.org/gmane.comp.web.spip.zone/14585) n’aura donc pas été résolu ?
Quelqu’un aurait-il trouvé une solution pour utiliser la polyhérarchie sur un gros site sans faire exploser son serveur ?
C’est un point faible connu du plugin, en effet. J’avais en projet une amélioration à base de Closure Table mais pas eu le temps (ni encore le besoin) d’explorer cette solution (qui demande certainement des adaptations pour fonctionner en polyhierarche).
J’ai un site en production avec ce plugin qui a beaucoup de trafic, sans problème critique de performance, mais je pense que c’est lié aussi à la volumétrie de la base qui est assez raisonable dans mon cas.
Répondre à ce message
Bonjour,
Tout d’abord, toutes mes félicitations pour cet excellent plugin.
J’aimerais savoir s’il est possible d’appliquer la polyhiérarchie à un site référencé afin qu’un même site référencé puisse être associé à plusieurs rubriques (afin de ne pas créer x fois le même site référencé lorsque l’on souhaite qu’il apparaisse dans plusieurs rubriques).
Si le plugin actuel ne le permet pas, est-ce qu’une évolution en ce sens du plugin est prévue prochainement ?
Bonjour,
N’ayant pas eu de réponses à mon précédent message, je me permets de vous solliciter à nouveau pour savoir si certains d’entre vous ont réussi à appliquer, grâce à cet excellent plugin, la polyhiérarchie sur les sites référencés ?
Merci d’avance pour vos retours.
Répondre à ce message
Deux bugs curieux, avec la version pour SPIP 3 du jour :
produit
Fatal error: Call to undefined function BOUCLE_autre_secteurhtml_a66e316f9ceba89ce9f3de8f8be91225() in /Users/maieul/Sites/SPIP/ecrire/public/composer.php(76)de même que
(je voulais selectionné les rubriques situés à la racine et qui étaients parentes de la rubrique courante)
autant pour moi, il semblerait que cela soit du tout betement au fait qu’il faille mettre cela dans une boucle rubrique engloblante (pas capable de prendre le #ID_RUBRIQUE dans l’environnement)
Répondre à ce message
Fantastique plugin !
J’essaie une chose. Et bien sûr n’y arrive pas.
Je veux afficher l’indication pour un article de son parent direct, puis de son parent indirect.
J’ai essayé la successions de boucles suivantes :
Mais seule la rubrique directe s’affiche.
Une idée ?
Merci
supprime le
{id_rubrique}…Répondre à ce message
Est-ce qu’il est possible de classer dans le selecteur les titres par ordre alphabétique ?
Répondre à ce message
Et les brèves ?
Bonjour
Une idée et une réalisation vraiment très utile.
Y aurait-il un obstacle à appliquer ce principe aux « brèves », ( qui permettent, par exemple, d’appliquer une annonce sans surcharger les menus ) ?
Sinon, peut-on espérer voir cette fonctionalité dans une prochaine version ?
Encore bravo, et surtout merci.
( cf dans cette page , la liste des articles constitue l’essentiel, et en dessous, la liste des brèves, que j’aimerais pouvoir reproduire ainsi très simplement dans les autres pages des rubriques. )
Répondre à ce message
Bonjour
J’utilise menu babibel. Comment faire pour que la polyhérarcie soit afficher dans le menu déroulant ?
Répondre à ce message
Bonjour,
Est-ce que une version du plugin pour spip3 est prévue, ou en cours de réalisation ?
Ce plugin m’est très utile et j’aimerai pouvoir passer à la nouvelle version de spip.
Oui, ce plugin sera-t-il rendu compatible avec la version 3 de spip ??
Je viens de mettre l’article à jour avec la version du plugin pour SPIP 3.0
Répondre à ce message
Merci de cet excellent plugin qui à mon sens devrait appartenir au Core de Spip.
Testé (2.0.3 - test )sur Spip 3.0 beta 2 .
Tout se passe bien pour l’instant.
Encore chapeau aux développeurs
Répondre à ce message
Bonjour,
J’ai quelques problèmes avec le plugin Polyhierarchie.
Lorsque je place un article également dans une autre rubrique que l’initiale, je rencontre le message d’erreur (en PJ) lorsque - via l’admin - je veux gérer cette autre rubrique.
Il doit y avoir un bug quelque part... mais où ??
Merci de votre aide.
Répondre à ce message
Le fichier de téléchargement ne semble pas valide, et je ne vois pas le plugin lorsque je tente de l’installer depuis plugins.spip.net. Est-il toujours valide ?
J’ai corrigé le lien de téléchargement, et le plugin est bien sur plugins.spip.net : http://plugins.spip.net/polyhier.html
Oui, je viens de me rendre compte que j’essayais de faire fonctionner la V2 du plugin avec la V2 de SPIP.
Répondre à ce message
Je suis en train de travailler sur un nouveau site en partant directement de spip 3.0 (même si on n’en connaît pas la date sortie officielle, je trouve stupide de ne pas profiter de suite de cette super version), mais le plugin polyhierarchie ne peut pas fonctionner sans le plugin Bonux. J’ai lu que Spip 3 intégrait nativement beaucoup de fonctionnalités de Bonux.
Bref, avez vous prévu une maj du plugin polyhierarchiepour SPIP 3.0 ?
D’avance merci
Répondre à ce message
Bonjour,
Je trouve ce plug-in très intéressant, mais je suis confrontée comme d’autres utilisateurs à un problème de taille : tout fonctionne sauf l’affichage des articles indirects dans les catégories...
Plus précisément, dans l’admin j’ai bien la possibilité de choisir plusieurs rubriques de rattachement pour chaque article. De plus, mes rubriques s’affichent sur le site, même si elles ne contiennent que des articles indirects et aucun article direct. Sur ces 2 points c’est donc bon.
Mais les rubriques n’affichent alors que les articles directs, et jamais les articles indirects. Enfin, quand je clique sur un article rattaché à 2 catégories, le fil d’ariane ne laisse apparaître que la catégorie principale, sans mentionner le rattachement aux catégories secondaires.
J’ai bien vu la réponse de « webtice » du 21 février :
mais alors j’ai du mal m’y prendre, me tromper d’endroit ou de fichier car ça ne m’a pas aidée résoudre le problème...
Plus globalement, faut-il toucher aux squelettes après avoir installé le plugin ?
Je suis sur SPIP 2.1.10 et j’utilise Polyhiérarchie 0.3.1 et Bonux 2.2.22.
Si quelqu’un a une solution je suis preneuse :-D
Oui, les squelettes par défaut de SPIP ne sont pas adaptés à la polyhierarchie, et il est nécessaire de modifier les squelettes pour prendre en compte les impacts que tu mentionne.
Hello !
Merci pour la réponse ! Plus concrètement, pour un débutant SPIP, quelles sont les modifications à faire ? J’ai imaginé qu’il s’agissait du fichier rubrique.html, et je me suis bien entendu intéressée à la boucle BOUCLE_articles(ARTICLES). J’ai bien fait quelques tests mais sans succès car je n’ai au fond aucune idée de la manière de la modifier afin de prendre en compte le mutli-catégorie. Je remercie d’avance tous ceux qui auront la bienveillance d’éclairer ma lanterne :-)
Merci à tous
Répondre à ce message
Déjà : bravo et merci pour ce plugin !
Perso, je trouve qu’il « révolutionne » SPIP ! (je n’ai jamais été convaincu par une navigation via les mots clés...)
Je me suis inscrit à SPIP Contrib spécialement pour vous remercier !
C’est tout mais c’est pas mal !
Marc
Merci beaucoup de ce retour. Il est probable que la prochaine version pour SPIP 3 aura en plus l’avantage d’accélérer les boucles avec le critère
{branche}Répondre à ce message
Bonjour,
J’ai installé le plugin Polyhiérarchie il a quelques jours, je l’utilisais sans problème et puis d’un seul coup il a cessé de fonctionner et m’affiche une erreur Javascript dès que je sélectionne plus d’une rubrique :
Erreur : uncaught exception : Syntax error, unrecognized expression : value=rubrique
Elle s’affiche quand je clique sur le bouton + pour sélectionner une deuxième rubrique.
J’ai désinstallé le plugin et supprimer ses fichiers, puis je l’ai réinstallé. Toujours la même erreur.
Quelqu’un a déjà eu cette erreur ? Ou pourrait m’aider ?
Je vous remercie.
Répondre à ce message
bonjour,
j’ai le même problème que raphaailes, problème qui a été soulevé à maintes reprises mais personne n’a répondu à l’heure actuelle. Dommage !
Pour résumer, l’arborescence est bonne dans l’espace privé, mais dans l’espace public l’article n’est visible que de la rubrique de référence.
« 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 ». Ceci est vrai, mais l’article indirect n’est pas visible, la rubrique est vide.
Pour test : http://webtice.ac-guyane.fr/slm5/spip.php?rubrique68 avec ’Galerie’ comme rubrique de référence.
Merci d’avance !
C’est réglé, il suffisait de mettre le critère branche_complete #ID_RUBRIQUE dans la boucle ARTICLE du squelette ...
ok c’est nickel, merci pour le travail !
Répondre à ce message
Bonjour, je souhaite utiliser le plugin polyhierarchie mais lorsque je l’installe sur mon site en ligne j’obtiens des messsages d’erreurs dans l’espace privé de type :
erreur mySQL 1064 - erreur dans le squellette ../plugins/polyhierarchie/prive/contenu/rubrique-enfants-indirects.html dans la bopucle _polyhier_rub et _polyhier_art
Quelqu’un a-t-il une idée d’un pourquoi du comment ?
Merci.
Répondre à ce message
Bonjour à tous,
J’ai installé ce plugin, qui semble absolument génial. Mais problème ...
Une fois plusieurs rubriques appliquées à un même article dans l’espace privé, tout semble fonctionner dans l’espace privé, mais strictement rien ne se passe dans l’espace public. Mon article reste uniquement dans la première rubrique spécifiée. Si j’intervertis la rubrique n°1 mon article change de place c’est tout, mais n’apparait pas dans les 2.
N’étant pas programmateur confirmé, je me demande si installer le plugin suffit ou si je dois inclure des morceaux de code quelquepart...
Merci de votre aide
le site en question : http://lascalaphe.free.fr/
Répondre à ce message
Tout d’abord bonjour et félicitations à Cédric pour ce plugin qui me rend bien service :)
J’ai une question : dans la vue ?exec=articles_tous, les articles « dupliqués via Polyhiérarchie » (ceux qu’on a référencé dans N rubriques) n’apparaissent qu’une fois, dans leur rubrique d’origine.
Est-ce volontaire ? (pour des raisons techniques peut être)
Répondre à ce message
Bonjour, J’ai installé le plugin en local et il fonctionne parfaitement ; lorsque je transfert le site en ligne j’obtiens les 3 erreurs suivante
Erreur SQL 1146
Table ’reseaum.spip_rubriques_liens’ doesn’t exist SELECT id_parent FROM
reseaum.spip_rubriques_liens WHERE (id_objet=21) AND objet=’rubrique’SELECT id_parent FROM spip_rubriques_liens WHERE (id_objet=21) AND objet=’rubrique’
Erreur SQL 1146
Table ’reseaum.spip_rubriques_liens’ doesn’t exist SELECT rubriques.titre, rubriques.id_rubrique, rubriques.lang FROM
reseaum.spip_rubriques ASrubriquesWHERE (rubriques.id_rubrique IN ( SELECT rl.id_objet FROMreseaum.spip_rubriques_liens as rl WHERE rl.id_parent=21 AND objet=’rubrique’)) ORDER BY rubriques.titreSELECT rubriques.titre, rubriques.id_rubrique, rubriques.lang FROM spip_rubriques AS
rubriquesWHERE (rubriques.id_rubrique IN ( SELECT rl.id_objet FROMspipcont.spip_rubriques_liens as rl WHERE rl.id_parent=21 AND objet=’rubrique’)) ORDER BY rubriques.titreErreur SQL 1146
Table ’reseaum.spip_rubriques_liens’ doesn’t exist SELECT articles.date, articles.id_article, articles.statut, articles.id_rubrique, articles.titre, articles.lang FROM
reseaum.spip_articles ASarticlesWHERE (articles.id_article IN ( SELECT rl.id_objet FROMreseaum.spip_rubriques_liens as rl WHERE rl.id_parent=21 AND objet=’article’)) ORDER BY articles.date DESCSELECT articles.date, articles.id_article, articles.statut, articles.id_rubrique, articles.titre, articles.lang FROM spip_articles AS
articlesWHERE (articles.id_article IN ( SELECT rl.id_objet FROMspipcont.spip_rubriques_liens as rl WHERE rl.id_parent=21 AND objet=’article’)) ORDER BY articles.date DESCJ’avoue etre bien démunie...
merci pour votre aide !
Bonjour,
je pense que le plugin est mal installé sur ton serveur. Cela peut venir du fait que tu l’avais installé en local, et que tu as transféré un dump en ligne alors que le plugin n’etait pas encore installé. Pour réparer cela, désinstalle le plugin (il faut cliquer sur le lien « désinstaller » qui apparait au survol et non juste décocher la checkbox), puis réactive le afin qu’il se ré-installe proprement.
Tu pourras ensuite ré-importer ton dump du site local.
merci Cedric ! il s’agissait bien de celà !
J’en profite pour t’adresser toute ma reconnaissance pour toutes tes contribtions sans lesquelles je n’avancerai pas !
Cordialement
Jo
Répondre à ce message
Bonjour,
Je viens d’installer le plugins. Je vois les liens dans l’espace privé mais pas dans l’espace public.
J’ai vidé le cache sans succès.
N’étant pas programmateur ni administrateur confirmé, je me demande si je dois inclure les morceaux de code citer dans l’article dans un fichier particulier.
Merci de votre aide
Répondre à ce message
Comment faire la mise à jour du plugin ?
Pour faire la mise à jour de ce plugin, faut-il écraser le dossier avec la nouvelle version, comme on le fait pour la mise à jour de SPIP ?
Car la désinstallation + réinstallation d’une nouvelle version du plugin ne marche pas très fort. En effet, la désinstallation efface toutes les informations polyhiérarchiques. Donc, après réinstallation de la nouvelle version, on a tout perdu...
Répondre à ce message
Bonjour,
j’ai utilisé avec succès ce plug in, du moins tant qu’un article est publié dans une rubrique : si je crée une rubrique qui ne contient que des articles issus de « polyhierarchisation » la rubrique est invisible par id_parent=12 (par exemple).
Si j’ai une rubrique qui contient elle même plusieurs rubriques contenant des articles polyhierarchisés comment faire pour les lister ???
Merci de votre aide,
Alex
Les rubriques ne contenant que des enfants indirects n’etaient pas publiées.
C’est maintenant pris en compte avec la version 0.3.0 du plugin !
Pour corriger une rubrique non publiée à tort, il suffit d’aller sur un article indirect, et de le dépublier/republier, ou de l’enlever de la rubrique et de l’y remettre.
Génial ! Parfait même :-), merci !
Répondre à ce message
Bonjour,
Ce plugin est génial. Par contre, un « bug » sur une install tout en utf-8 :
Si le nom de la rubrique contient un apostrophe à la word ’ on ne peut pas l’ajouter. L’apostrophe dans le code, est transformée en ’ sans antislash et ça coupe la chaine du titre sur le jQuery(this).item_pick
Si l’apostrophe est un apostrophe ’, ça fonctionne, y a un antislash qui se met dans la chaine devant lui.
C’est corrigé avec la version 1.9.6 de SPIP-Bonux
Répondre à ce message
Exactement ce qu’il me faut !
Je pense utiliser ce plugin dans le cadre d’une association sportive (échecs, mais bon).
Je vais créer des rubriques par saison (compétitions 2009/2010, vie du club 2009/2010, ...) et une rubrique secondaire (Compétition, Vie du club, ...) qui pointera sur la rubrique équivalente de la saison courante (à changer chaque année).
Ca m’évitera de déplacer chaque année des tonnes d’articles en perdant le rubriquage.
le plugin « Menus » ne fonctionne pas sur les rubriques secondaires (il semble que remplacer id_parent=#getid_rubrique par enfants #ID_RUBRIQUE soit suffisant).
Répondre à ce message
Bonjour,
Je souhaiterais utilisé ce plugin mais etant débutante dans spip, je ne sais pas ou placer la boucle...
J’ai SPIP 2.07 et j’utilise le squelette de simple magazine.
Voici le code de la rubrique où apparait les articles :
qui, si j’ai bien compris appelle ce code contenu dans inc-rub
Pouvez vous m’indiquer où placer la boucle ??
Merci d’avance
Répondre à ce message
J’ajoute que ça le marche pas.
Grâce à la Polyhiérarchie, j’ai placé la sous rubrique « Sacs Bretelles liasses » créé dans la rubrique « Sacs et sachets plastiques » dans la rubrique « Test »
Comme vous pouvez le voir sur les captures d’écran nada dans « test »
Le code de mon menu dépliant :
Quelqu’un à une idée ?????
As tu re-calculé ton squelette ou vidé le cache de SPIP après l’installation du plugin ? Car le critère branche est redéfini, mais il faut que SPIP reconstruise le squelette avec ce nouveau critère pour que cela prenne effet.
Pour l’instant je teste la navigation que sur la page sommaire.
Le vidage du cache n’y change rien.
Qu’entends-tu par recalculé le squelette ?
De plus, en essayant de mettre en place le plugin j’obtiens :
Warning : strstr() expects parameter 1 to be string, array given in C :\Program Files\EasyPHP-5.3.2\www\regieemballge\ecrire\inc\texte.php408 on line
Au dessus de la zone de gestion de la Polyhiérarchie.
?????????????
Re calculer = cliquer sur le bouton « Calcul » puis a nouveau lorsqu’il porte le label « Recalcul »
Pour le warning, c’est un problème de compatibilité SPIP avec PHP 5.3.2. Une release 2.0.11 doit sortir très bientôt, mais sinon tu peux mettre à jour ton site avec http://files.spip.org/spip/dev/SPIP-branche-2.0.zip
Le bouton « Recalculer la page » ?
J’ai fait mais marche pas
Ça marche toujours pas je doit être un gros mauvais...
J’ai créé 3 rubriques et trois sous-rubriques.
Les rubriques 1 et 2 sont accessibles par la navigation gauche et la rubrique 3 par la navigation droite.
Je veux pouvoir accéder à la sous-rubrique 2, qui appartient à la rubrique 2, dans la rubrique 3 par la Polyhiérarchie pour ne pas la recréer.
Quel est le process à suivre pour y parvenir.
Puis-je transmettre mon site à quelqu’un pour qu’il me dise ou je me plante ?
Répondre à ce message
En essayant de mettre en place le plugin j’obtiens :
Warning : strstr() expects parameter 1 to be string, array given in C :\Program Files\EasyPHP-5.3.2\www\regieemballge\ecrire\inc\texte.php408 on line
Au dessus de la zone de gestion de la Polyhiérarchie.
????????
Au secours
Répondre à ce message
Bonjour,
Pour les rubriques ayant un très grand nombre d’articles utilisés en polyhierarchie, ne serait-il pas plus ergonomique d’injecter le pavé des « articles liés » en colonne centrale sous le pavé intitulé « Tous les articles publiés dans cette rubrique ».
Le pavé pourrait s’intituler « Tous les articles liés à cette rubrique » et reprendre le même format, notamment pour la pagination si le nombre d’articles liés est supérieur à 10.
Voila, ce n’est qu’une proposition. En tout cas merci pour ce plugin indispensable !
Répondre à ce message
Bonjour,
J’essaie d’utiliser ce plugin qui m’a l’air fort sympathique, mais j’ai un problème.
Dans l’espace privé, je vois bien les articles que j’ai liés, dans la colonne de gauche, à une rubrique. Par contre, lorsque je visite mon site, je ne vois pas les articles liés dans la rubrique... Est ce que quelqu’un a eu ce problème ?
Merci d’avance.
Répondre à ce message
Bravo pour ce plugin.
Le concept est très pratique et j’espère pouvoir bientôt l’utiliser.
Par contre, je ne suis pas très doué et je n’ai pas trouvé où il fallait que j’insère les morceaux de codes pour la « branche complète ».
J’utilise le squelette escalv2 disponible sur la zone.
Quelqu’un pourra-t-il me sauver ?
Merci par avance
fdauphin
Répondre à ce message
Excellent plugin. Bravo !!
Répondre à ce message
Bonjour,
(Je reposte ici ma question/proposition après une absence de réponse sur la liste spip-zone, si les devs m’entendent...)
Je suis aujourd’hui confronté à un problème de perfs et j’aimerais éliminer le facteur polyhierarchie pour avoir des mesures fiables afin d’optimiser au mieux mon serveur.
Je rappelle que le plugin génère actuellement des requêtes SQL que mysql n’arrive pas à optimiser => ça impacte (un peu) sur les perfs du serveur et ça noie mon slow_queries.log.
Les requêtes sont du style :
Je suis prêt à tenter de faire les modifs nécessaires moi-même si elles ne sont pas trop compliquées (je en maîtrise pas encore bien le côté API php de spip), mais j’aimerais savoir quelle piste suivre avant de faire quoi que ce soit.
Je pense que le problème vient de la clause « id_parent =xx OR id_rubrique IN (x,y,z) ».
Il me semble avoir remarqué que Mysql a le plus grand mal à optimiser les clauses OR portant sur des attributs différents : il n’arrive pas à déterminer quel index utiliser.
Je vois deux solutions potentielles :
- soit répliquer les liens dans la table spip_rubriques_liens, mais je comprends les réticences exprimées plus tôt : la détermination du caractère direct / indirect du lien deviendrait alors plus compliquée (attribut supplémentaire dans la table ?), et ça forcerait à beaucoup de tests de consistance pour ne pas diverger pour une raison ou une autre => pas mal de modifications sur le plugin.
- soit scinder la requête et en produire tout simplement deux, plus simples et totalement optimisées, dont on agrègerait les résultats ensuite. Ca a aussi forcément un impact sur les perfs, mais je ne sais pas à quel point.
Je pense que ça serait quand-même mieux que des requêtes systématiques sur la totalité de la table (surtout qu’avec les jointures, la combinatoire grimpe facilement, j’ai régulièrement des parcours de 100 000+ lignes à cause de ce bug).
Y-a-t-il d’autres solutions ?
A bientôt
Simon
Répondre à ce message
Génial ça marche merci beaucoup !
Répondre à ce message
Ce plugin est exactement ce dont je rêvais depuis longtemps.
Malheureusement je n’y arrive pas au niveau de mon squelettes.
La boucle ne va pas me charger les articles associés via le plugin dans la rubrique courante.
C’est normal :
{id_rubrique}n’est pas modifié par le plugin. Il faut que tu utilise les nouveaux critères mis à disposition.Répondre à ce message
Bravo et merci pour ce plugin !
Je l’utilise sur un de mes site avec bonheur, il m’évite pas mal de circonvolutions avec les mots-clés (que je m’étais habitué à faire mais qui rendent les sites très durs à maintenir).
J’ai une question : comment peut on faire pour exclure une branche ?
Par exemple, je voudrais afficher tous les articles du site sauf la branche qui part de la rubrique 17 (qui peut contenir des enfants directs et indirects).
J’ai bien sûr essayé :
Mais sans succès... Idem avec
{!enfants 17}...Est-ce possible ?
Répondre à ce message
Bonjour,
j’utilise aussi ce plugin vraiment fabuleux, maintenant je voudrai savoir si on pouvais dupliquer l’article quand on l’ajoute dans une autre rubrique ?
est ce que cela est possible ?
merci d’avance
Répondre à ce message
Bonjour,
Je pose cette question ici car elle exprime un besoin diamétralement opposé à celui résolu par le plugin Polyhiérarchie, ce qui l’y lie par opposition en « quelques sortes ».
En natif, SPIP ne permet pas de dupliquer n fois une partie de l’arborescence des rubriques.
Bien que contraire à la philosophie rationnelle mise en œuvre par SPIP, cette fonctionnalité se révèle pourtant utile pour certains de nos utilisateurs qui en ont besoin pour une branche arborescente comprenant de 100 à 150 rubriques (voire plus), ce qui représente un gain considérable de travail.
Une telle fonction devrait probablement être réalisée sous la forme d’un plugin.
Quelqu’un a-t-il ce projet en cours ?
Meilleurs messages
François Daniel Giezendanner
si je me souviens bien il y a qq part un plugin genre création de contenu qui fait cela
il est là sur la zone
sa description :
Permet de cloner en xx exemplaires une rubriques « source » avec ses articles vers une rubrique « cible »
Répondre à ce message
Bonjour ! C’est vraiment le plugin qui me sauve ! Seulement je mettrais de la polyhiérarchie un peu partout...
J’aimerais appliquer la polyhiérarchie aux brèves ? Par où dois-je commencer ?
Merci
Répondre à ce message
Bonjour,
Y-a-t-il des modifications de fichier possibles afin de pouvoir utiliser le plugin Page Unique avec Polyhiérarchie ?
(Lors d’une création de Page Unique, Polyhiérarchie oblige à sélectionner une rubrique)
Cordialement
ah surement, mais comme je n’utilise pas du tout ce plugin, je ne sais pas où et comment gérer le problème.
Mais les pages unique c’est un peu la polyhierarchie généralisée :), il faudrait assurer la compatibilité !
Merci Cedric, je vais essayer de voir avec RastaPopoulos pour la compatibilité.
@+
un peu à l’arrache, dans polyhier_pipeline.php, j’ai shunté les process charger, verifier,traiter...
il y a sûrement une solution plus propre, en passant par les formulaires privés...
Merci beaucoup Minimalteck. J’essaye ça ce soir après le boulot.
@+
Vous pouvez aussi mettre à jour Polyhiérarchie, j’ai intégré une vérification pour ne pas l’appliquer lorsque l’id_parent principal est incohérent (inférieur à zéro).
Répondre à ce message
merci, c’est terrible, grâce à polyhiérarchie, on peut maintenant :
- lier un ensemble à un autre autre (mot-clef de mot clef)
- intégrer ces ensembles dans une ou plusieurs hiérarchie (mot-clef hierarchique) du type pays > région > ville ou plus complexe
Comme le suggère Fil, une compatibilité mots-polyhierarchie serait utile (peut être plus que rubriques-polyhierarchie), pour passer facilement de l’un à l’autre, et éviter d’écrire toutes les boucles en double..
Avec polyhierarchie est ce qu’il y a encore un utilité aux mots-clef ? Est ce que polyhierarchie de devrait pas devenir le moteur de « mot clef » par défaut ? les rubriques secondaires sont à mon avis plus proches de mots-clef(ensembles) que de rubriques..
Répondre à ce message
Super projet.
Quand j’aurai un moment je testerais bien une conversion mots<->polyrubriques et vice-versa. Ca permettrait de migrer facilement un site d’une gestion de mots vers une gestion de taxonomie, avec l’assurance de pouvoir faire marche arrière si ça plaît pas.
Si en plus on pouvait recoder à la volée la boucle (MOTS) pour qu’elle affiche les polyrubriques ce serait le début de la fin des mots.
A mon sens il manque dans la doc une présentation de la structure des données dans la base (la « rubrique principale » est-elle ou non présente dans la table spip_rubriques_liens ?).
A noter : sous SPIP 2.1 le plugin affiche des bouts de squelette sérialisés. Pas compris d’où ça sort
Répondre à ce message
prive_spip.log me ressort :
Erreur - ’polyhier_autoriser’ non definie ! une idée d’ou ça peut venir ?
oui une petite particularité du pipeline autoriser utilisé simplement pour charger le fichier des autorisations. Ca n’a aucun caractère de gravité, mais je vais voir pour corriger.
Répondre à ce message
Bonjour. Je suis sous spip 208. Je n’arrive pas à activer le plugin Polyhiérarchie sur mon spip, il me demande d’installer le plugin SPIP_BONUX en version [1.8 ;] minimum hors j’ai SPIP_BONUX 2.0 d’installé. Est-ce que c’est normal ? Merci pour toute aide !! Cordialement, Vanessa
pardon je viens de trouver mon erreur ....
Répondre à ce message
Dès que j’utilise un des filtres énoncés sur mes boucles, j’ai une erreur de requête SQL.
Je ne comprend pas d’où cela peut venir.
J’ai testé toutes les possibilités sur des boucles articles ou rubriques et les erreurs persistent.
Quelqu’un aurait une piste ?
C’est sur un spip 2.0.8 avec spip bonux 1.8
Pour que je puisse t’aider, il faut que tu donnes le message d’erreur, et le code d la boucle concernée. Si tu peux aussi m’indiquer la version de ton PHP et de ton mysql ce serait bien.
Et bien, la réponse arrive avec ta proposition d’aide.
C’est ma version de mysql qui pose problème pour les requêtes !
Je sais ce qu’il me reste à faire maintenant . Merci bien pour ta réactivité.
Quelle version de mysql utilises-tu, pour que je complète la doc ?
Répondre à ce message
Rubrique -> ranger ; Mots-clés -> décrire / trouver
Ah. Parce qu’il n’y aurait qu’un seul rangement possible... C’est extrêmement réducteur et non représentatif de la pensée humaine, qu’on a toujours eu du mal à faire rentrer dans des cases hermétiques. Non ?
Moi, quand je range, je n’utilise, et n’ai jamais utilisé qu’un seul concept : la patate.
comprends pas.
je te dirais, moi je ne range pas. j’indexe et je recherche plein texte si nécessaire.
mais chacun son truc. la demande systématique des rédacteurs est ’mais où je range’.
c’est con mais c’est la vie.
je n’ai pas dit que le concept ’poly’ n’était pas intéressant, fut-il appliqué qu’aux rubriques. mais je pense que son véritable déploiement serait comme méthode d’indexation (ce qu’il est presque) et donc plutôt du côté des mots-clef (qui sont ’traditionnellement’ dévolus à cette fonction dans tous les autres outils).
Une patate est un lasso, un ensemble, une collection... cf. Théorie des ensembles. J’ai appris ça en maternelle, c’est dire si c’est simple. Y’a pas mieux, sauf si on tient à se compliquer la vie, en utilisant des trucs limités (comme les « rubriques » ou les « mots-clés » de SPIP).
ah dac. mais…
les ensembles, c’est des mots-clef ;-)
les rubriques, c’est des mots-clef (un peu limités)
ce qui rend les choses compliquées, c’est quand elles ne sont pas ergonomiques. et il y a rien de moins ergonomique qu’un écran lié à un clavier et une souris. du coup, on série, on découpe, on liste, on range…
ce qu’il faudrait c’est des dropbox. tu survole avec l’icône de ton article, pop elle s’ouvre. tiens, il y a des sous-choix ? pop, il s’ouvre. mouse up sur la sélection et c’est classé, le fil d’ariane est sauvé. tu veux un deuxième classement pas de problème tu repars avec ton icône. et paf deuxieme classement, deuxième fil d’ariane.
il y a les stats qui peuvent aider aussi, mais ça fait un peu pensée unique.
NON ! Les patates, on peut les mettre les unes dans les autres, les emboîter à l’infini, pas les mots-clés. Les patates peuvent se recouper les unes les autres, un peu, beaucoup ou passionnément, pas les rubriques.
:-P
Pour le reste... peux-tu éviter de truffer tes messages de termes anglais incompréhensibles ? Et ajouter une couche d’interface gadget ne comble jamais les manques.
têtue mais alors !
Il ne faut pas se prendre le chou — la patate ? — inutilement !
Le plugin polyhiérachie est très bien pour une classification élaborée des articles sans faire appel aux mots-clés qui sont limités par le fait qu’ils ne sont pas arborescents.
Affecter artificiellement des mots-clés arborescents aux auteurs ou à d’autres objets avec ce plugin devient donc techniquement possible et exploitable grâce à quelques contorsions de boucles. L’ergonomie de l’interface liée à l’affectation des mots-clés en souffrira pour le moins.
Les deux systèmes (polyhiérachie /mots-clés arborescents) ont donc chacun leur usage. Je suis convaincu qu’ils trouveront respectivement leur public.
À suivre...
Répondre à ce message
le concept permet ceci :
l’auteur A indexe son contenu avec ’c’ en choisissant une arborescence qui lui est naturelle, disons a>b>c (ex un toxicologue au sujet d’un champignon)
l’auteur B indexe un autre contenu avec ’c’ selon une arborescence qui lu est naturelle, disons e>d>c (ex un botaniste au sujet du même champignon)
l’auteur C… x>y>c (ex un cuisto…)
le lecteur fait une recherche, mettons sur ’c’ et découvre une arborescence ’on the spot’ à 3 branches ’b’, ’d’, ’y’.
il retrouve donc le contenu selon l’univers de sa recherche (cuisine, botanique, toxicologie…)
le mot clef ’c’ n’existe qu’une fois
en fait, ce qui se passe, c’est qu’on fait un focus sur le terme et que toute l’arborescence se redessine en fonction du nouveau point de départ. s’il fallait un exemple, je citerais http://thinkbase.cs.auckland.ac.nz/.
@ivandps. par ailleurs j’avais fait un test de liaison freemind/SPIP http://www.etopia.be/outils/squelet.... le résultat arborescent est satisfaisant sauf… qu’il est bloqué à devoir faire des sauts entre branches (ex habiter/cadre de vie/ paysages/>lien vers milieu)
à+ éric
Répondre à ce message
Hello,
Je ne comprends pas bien l’argumentation développée pour justifier l’utilité du plugin.
D’abord dans la partie « pourquoi ce plugin », tu cites l’exemple de wikipedia qui dit
Et dans la partie « que fait le plugin » tu dis :
L’exemple elliptique de cuisine libre n’est pas tellement plus probant, scientifiquement parlant.
Cela étant posé, en lisant entre les lignes, je comprends qu’il s’agit en fait de pouvoir classer un contenu dans plusieurs arbos. C’est à dire comme les mots clés arborescents, mais implémenté ici sur la techno des rubriques pour aller vite.
Alors puisqu’on discute, voici mon avis : je crois que c’est le concept plutôt de rubrique qui vieillit, plus que celui de mots clés.
En résumé, nous voilà fasse à un chouette plugin, qui va permettre d’attendre le vrai plugin mots clés arborescents, type taxonomie dans Drupal.
Le concept du rubrique qui est dépassée ? Faut pas exagérer quand même. C’est pas parce qu’il y a une envolée des sites fourre-tout où tout le monde rajoute son contenu (cad sans ligne éditoriale précise) et où là effectivement, un système de mots-clés est plus approprié, que les rubriques sont mortes.
Espèce de progressiste !
Dans la majorité des cas, un système hiérarchique de rubrique est largement suffisant pour classer des objets, mais surtout largement supérieur intellectuellement parlant pour que le cerveau retrouve facilement un objet qu’il cherche.
Le tout, comme l’a dit Cédric c’est d’arriver à permettre plusieurs types de classements avec la même implémentation derrière, pour que techniquement ce soit facilement maintenable et facilement compréhensible pour les devs et pour ceux qui ajoutent le contenu.
Reprenons l’exemple passionnant, car inépuisable, des recettes de cuisine : la recette des « carottes râpées à l’échalote » doit être rangée dans « carotte » ET dans « échalote » (eux-mêmes dans « légumes »), ainsi que dans « entrée » ET « salade », ainsi que dans « végératien » ET « végétalien » (ce dernier étant une sous-catégorie du précédent), etc. Un tel classement peut, bien évidemment, être réalisé avec des mots-clefs, de préférence arborescents, comme toutes les autres catégorisations propres à cet exemple (types de plat, régime alimentaire, niveau de difficulté, saisons, etc.)
Ce faisant, toutes les recettes se trouvent correctement étiquetées de mots-clés, mais en vrac, dans une énorme rubrique « recettes » (puisqu’il est obligatoire, dans SPIP, d’avoir au moins une « rubrique »)...
Il est alors nécessaire de choisir une des catégorisations comme principale, ne serait-ce que pour pouvoir proposer une navigation principale sur le site public. Cela n’est actuellement pas possible avec les « mots-clés » de SPIP, mais depuis toujours correctement réalisé par les « rubriques » de SPIP.
Ceci dit, puisqu’il semble falloir choisir entre les deux, mon avis est que « mots-clefs » ou « rubriques », on s’en fiche, pourvu qu’il soit possible de catégoriser vraiment le contenu, ce qui nécessite parfois de dépasser leurs limites respectives et de combler leur manques, car bien que deux, « mots-clefs » et « rubriques » ne font jamais que ce que l’autre ne fait pas, là où un seul type d’objet aurait suffit à tout faire. Ainsi pourrait-on en débattre longtemps...
@tetue :
Tu confonds la fonction (rangement anti-vrac) avec l’organe (rubrique). En conséquence, tu considères que si on remplaçait le classement en rubriques par un classement avec des motclés... on ne changerait par contre pas le classement en rubrique pour les usages de rangement !
Mais si on remplace le rangement en rubriques par l’usage de motclés arborescents, oui, il n’y a plus qu’une seule rubrique où tout est en vrac, mais alors l’usage de ’rangement’ des rubriques doit être remplacé par un groupe de motclés dédiés - refaisant ce qu’on faisait avec les rubriques, et ci, y compris dans la partie privée.
Exemple : Si l’arborescence des rubriques (n’existant plus) était décrite par l’arborescence issue d’un groupe de motclés appelé ’rubriques’, par exemple, il suffirait que la partie privée de spip utilise ce groupe réservé pour proposer une navigation privilégiée et hop, on aurait plus ce bordel horizontal que tu décris.
En plus, il pourrait y avoir plusieurs navigations privilégiées sélectionnables. Ce pourrait être une option des groupes de motclés « Oui/Non : Pouvoir se servir de ce groupe de motclé comme d’une navigation entre les objets ». Et on pourrait dans la partie privée sélectionner selon quel groupe de motclé doit être le mode de navigation privilégié (proposé par la partie privée de spip).
Heu je comprends pas la logique....
Tu propose donc de rendre les mots clés arborescents et de refaire toute la navigation de l’espace privé en fonction d’un des groupes de mots clé.
Ce n’est pas plus simple de renommer les rubriques ’mot clé’ à ce compte là ? Qu’est-ce que tu veux faire avec les mots clés arborescent que tu ne peux pas faire avec les rubriques polyhierarchiques ?
@Cédric : Ce n’est pas une proposition, mais une discussion. Je cherche la justesse dans le débat et je corrige @T en précisant ce que ça pourrait être avec des motclés arborescents et comment ça ne génèrerait pas de vrac mais au contraire des organisations et rangements parallèles.
Si on renommait les rubriques polyhiérarchie en « motclés » comme tu le suggères, on aurait presque la même chose en effet, à la différence près qu’avec la polyhiérarchie du plugin, il y a par conception une arborescence principale et les autres secondaires, et des boucles différentes pour les interroger, alors que tous les groupes de mot-clés sont par défaut au même niveau.
La limitation c’est que la polyhiérarchie des rubriques se traduit donc dans l’interface privée ET publique par une navigation principale et des navigations auxilliaires.
- Dans l’interface privée, c’est le plugin qui fixe les choses ainsi.
- Dans l’interface publique, c’est fortement induit ainsi puisque ce ne sont pas les mêmes boucles pour interroger l’une ou les autres, mais il est je pense possible de concevoir quand même « comme on veut » une équivalence apparente des hiérarchie.
Ceci dit, cela n’enlève rien à l’intérêt de ce super plugin qui apporte quelque chose d’attendu depuis longtemps !
Cela correspond peut être à l’état historique majoritaire de conception de la réalité, et c’est rassurant pour aborder la création de contenu. Juste c’est un peu limitant aussi en nos époques ... ’post-modernes’ ?
En effet, ce joli plugin me semble être une solution d’attente en vue d’un plugin (ou d’une fonctionnalité native de SPIP) de mots-clés arborescents et attachés à tous les objets de SPIP. L’attribution de mots-clés aux auteurs est par ailleurs, et curieusement, un vieux serpent de mer qui a fait couler beaucoup d’encre.
En tant qu’utilisateur, je recherche depuis longtemps à associer une région et un département à un auteur via un système de mots-clés arborescents. Pas sûr, comme le laissait entendre Cédric, que le plugin polyhiérarchie permette cela facilement.
Enfin, mon regard profane comprend mal pourquoi l’arborescence est si difficile à mettre en oeuvre sur les mots-clés alors l’arborescence des rubriques existent depuis la nuit de SPIP !
En tout cas, bravo aux auteurs !
Mais arrêtez avec cette histoire de noms différents à la fin !
Le plugin Polyhiérarchie propose déjà ça. Peu importe que le nom donné à l’élément de classification soit le mot « rubrique » ou le mot « mot-clé ». Vraiment.
Techniquement les mots de SPIP sont un vrai bazar puisqu’il y a une table de liaison de créée pour chaque objet auquel on veut lier des mots. Hors le plugin Polyhiérarchie a été développé directement avec la même solution que ce qui existe déjà pour les documents : une seule table de liaison où l’on met l’id de la rubrique, le type de l’objet et son id.
Ce qui signifie que l’on peut dors et déjà lier les auteurs ou n’importe quoi d’autre à des rubriques de la polyhiérarchie ! Ce n’est qu’une question d’interface pour le faire, techniquement c’est déjà possible.
Le seul truc qui manque pour l’instant, ce sont les options que l’on trouvaient dans les groupes de mots pour restreindre l’utilisation d’un secteur à tel type de compte (admin, rédac, visiteur), à tel type d’objet (ce secteur ne peut être lié qu’avec des articles/documents/auteurs/etc), obligatoire ou pas (pour forcer le choix d’une rubrique de ce secteur). Bref comme pour les mots.
Et c’est bien évidemment plus simple d’ajouter ces options au plugin polyhiérarchie, que d’ajouter l’arborescence et les liaisons à tout type d’objets aux mots.
Ah oui, mais alors dans le « concept » ce sont des mots polyhierarchiques, qui choppent leur propriété arborescente sur les rubriques par opportunisme, plutot que sur des groupes de mots qui ne sont pas aujourd’hui arborescents :p.
Est-ce que ca vaudrait le coup d’envisager des groupes de mots arborescents, et des mots liés a tout avec une table de jointure comme les documents ?
On garderait comme ça le distinguo important à mon sens pour l’ergonomie et l’efficacité :
Rubrique -> ranger
Mots-clés -> décrire / trouver
Répondre à ce message
Aujourd’hui sur spip, l’organisation du contenu est mono logique = un seul sens de lecture, défini par le(s)responsable(s) éditorial(aux).
L’avancée : permettre au lecteur de s’approprier le contenu selon sa logique. Requière une navigation transversale.
En ce sens ce plugin répond à un vrai besoin. Merci aux auteurs.
Ces autres chemins de navigation peuvent être définis par les ontologies (taxonomie drupal vue ci-dessous ?). J’attendais de mettre cela en application avec les mots clés et je n’étais pas loin de partager cette réflexion de Booz ci-dessous : la rubrique est dépassée. Je suis d’accord avec l’homme à la cravache et au monocle, elle suffit et répond très bien à organiser un site dont le contenu est bien balisé. Mais très vite lorsque le volume d’information est important (tendance lourde de notre époque), trouver l’information quand on en est pas l’organisateur peut se révéler complexe (voir les nombreuses rubriques de Clubic). On aimerait dans ces cas là au moins une recherche multicritère, en associant des mots clés, en les filtrant (voir la page powersearch d’IMDB pourtant pas avant gardiste), et encore mieux, des suggestions en fonction d’un mot tapé, genre plugins étiquettes- (merci rastapopoulos)- nuage -sélecteur générique - snippets). Pour cela, il faut avoir structuré et qualifié le contenu du site avec des ontologies. Vous avez dit Linked data, web sémantique ?
Alors le roi est mort ? Pas vraiment. Car l’héritier légitime le mot partout, même arborescent, même sous spip 2, ne permet pas encore d’associer un mot clé à un autre mot clé. Id parent reste l’apanage du groupe de mot. Logique mono hiérachique pyramidale. Bye bye ontologie, on garde les thésaurus et le champ « rechercher sur ce site ».
Le roi n’est pas mort, il se porte mieux même. Merci pour la cure de jouvence et les nouvelles possibilités offertes. Pour autant, mis de côté l’aspect maintenance du code, le plugin offre t il autant de possibilité que ce que laisse entrevoir le prometteur mot clé - vraiment - partout et arborescent de zerax ? Et je me pose la question de la dispersion d’énergie.
oublie les dénomination de rubrique et mot-clé, et réfléchis au niveau fonctionnel. En creusant, tu verras vite que tout ce que tu voudrais faire avec des mots-clés arborescent peut se faire au moyen d’une polyhierarchie. Avec une économie de moyen que le temps montrera, mais que j’ai pu constater...
oui, a priori bien d’accord avec vous deux (Romy Cédric) : qu’importe la dénomination, pourvu que l’horizon soit vaste. Le besoin fonctionnel est bien le même. C’est d’ailleurs compatible avec la vue heuristique citée ci-dessous (mind mapping) et qui m’est chère. A ce sujet Eric Luyckx, voir l’excellent plugin Afficher la zone. Donc j’applique et je vous dis quoi.
Répondre à ce message
Salut à toutes et tous
j’ai l’impression qu’on tient le bon bout ! d’autant que moi ce qui m’interesserait c’est une polyhierarchie… de mots-clef.
Je m’explique : pouvoir associer un mot-clef à plusieurs groupes ou sous-groupes de sorte à pouvoir organiser les mots-clef comme un mind-mapping (à l’instar de l’icône du plugin ;-)
intérêt ? une indexation complexe arborescente nécessite une connaissance approfondie du thésaurus. une organisation en carte heuristique permet un cheminement naturel vers le bon mot-clef via des trajectoires (fil d’ariane) différentes et qui correspondent respectivement mieux à chaque ’encodeur’… et à chaque visiteur
bref je ne sais pas si le travail est transposable sur les mots-clef, je présume qu’à part la nomenclature des tables et de quelques champs, il n’y aurait pas grand chose à modifier.
encouragements anyway
Eric
Le code n’est pas transposable aux mots-clés. La preuve en est la difficulté à faire emerger la fonctionnalité de mots-clés arborescents.
peut-être. le problème de mots_partout (outre son instabilité) c’est qu’il reste dans une logique arborescente…
au niveau rédactionnel, je rejoins qqn du forum qui soulignait la facilité naturelle que représente l’arborescence de base pour le quidam qui vient rédiger ses premiers articles. la distinction à ce niveau (purement culturelle et ergonomique) reste intéressante.
Répondre à ce message
Trop génial ce plugin...
Je bute sur un problème pratique quand j’essaye d’installer le plugin -
Message d’erreur :
Impossible d’activer le plugin auto/polyhierarchie
* Nécessite le plugin SPIP_BONUX en version [1.8 ;] minimum.
Alors que j’ai bien Spip Bonux 2.0 installé et activé ....
Télécharge le dernier zip de bonux, réinstalle le, et ça ira mieux !
Yep, ça le fait, je m’y plonge... Merci :-)
Je viens de faire quelques tests de charge serveur sur un bon serveur et un site un peu costaud (beaucoup de rubriques, beaucoup d’articles) pour une même rubrique
1/ id_rubrique 2/ branche complete #ID_RUBRIQUE 3/ enfants #ID_RUBRIQUE
Voici ce que ça donne en comparaison :
1/ 0.244152162613
2/ 2.20104440564
3/ 0.81874920459
Est-ce qu’il y moyen d’optimiser la charge à part de se limiter à l’option 3 et/ou de faire un squelette particulier pour certaines rubriques, ce qui revient à créer de la complexité ?
Sinon, je confirme et signe toujours trop génial la polyhiérachie :-)
le critère
{branche}est lent car il necessite plusieurs requetes consécutives pour parcourir la descendance de façon recursive.Ce n’est pas lié à la polyhierarchie, mais à la modélisation interne de l’arborescence dans SPIP, qui repose sur un simple pointeur sur le parent.
Il y a des méthodes de représentations des graphes plus efficaces, mais il faut les implémenter au niveau de la table des rubriques. Ca n’a pas été prioritaire jusqu’ici. C’est surtout délicat car il faut blinder la migration, tester, valider etc ..., l’erreur et la perte éventuelle d’arbo n’étant pas permises !
Je vais surveiller un peu la charge globale du serveur - le cache devrait éviter le pire. Après pour amener Spip à être encore plus souple pour de très gros sites, je suis fan et je le serai tous les jours un peu plus ;-)
Répondre à ce message
Bonjour,
Merci pour ce plugin intéressant. Je le commente ici :
http://icp.ge.ch/sem/cms-spip/spip.php?article818
SPIP exploite justement les mots-clés et famille de mots-clés pour suppléer à ces insuffisances. Ainsi, les mots clés dans SPIP sont conçu pour créer des navigations transversales complémentaires à la navigation naturelle dans l’arborescence des rubriques. Ce qui donne généralement pleine satisfaction.
De plus, zerax a créé un plugin pour des arborescences de mots-clés :
ou gestion des mots clés avec un principe d’arborescence
dimanche 23 septembre 2007, par zerax
http://www.spip-contrib.net/mot-clefs-partout
Il permet d’utiliser les mots clefs dans une structure en arborescence. Il permet aussi d’ajouter facilement les mots clefs sur les documents.
Ainsi, ce nouveau plugin Polyhiérarchie va nourrir notre réflexion et peut-être notre pratique, en ce sens que maintenant nous pouvons réfléchir à des stratégies de navigation qui exploitent quatre concepts complémentaires :
Meilleurs messages
FDG
Je réponds ici aux remarques que tu fais dans ton article.
Tu note notamment que nous avons omis de citer les mots clés comme solution à la navigation transversale. Il est vrai que nous n’avons pas développé toutes les solutions qui ne marchent pas (ce n’était pas vraiment le but de l’article), mais les exemples cités ne peuvent être résolus non plus de manière satisfaisante avec les mots clés de SPIP.
Ensuite, tu évoques la possibilité existante des mots clés arborescents. Effectivement, ce type de fonctionnalité, tel le serpent de mer va et viens au gré des contrib (au temps de la 1.8) ou plugin plus ou moins à jour.
La vrai question à poser, à mon sens, est : quand on en arrive à rattacher un objet à 2 ou plusieurs arborescences, pourquoi devrait-on utiliser 2 types d’objets différents pour modéliser ces arborescences ? Je ne vois aucun avantage à cela, et que des inconvénients :
Pour aller jusqu’au bout de ma pensée, les mots-clés de SPIP sont un concept batard.
Il faut laisser le temps juger à l’épreuve des faits, mais il me semble que SPIP serait plus efficace (tant du point de vue des codeurs avec plein de code compliqué en moins, que du point de vue des utilisateurs) avec d’un côté une polyhierarchie des rubriques, et de l’autre un objet de type tag très léger et simple.
Répondre à ce message
je travaille actuellement sur accès restreint
je suppose que la hiérarchie des zones n’est pas cassée par cet apport ?
Le plugin accès restreint continuera à fonctionner sur les arborescence principales uniquement, effectivement.
Répondre à ce message
Simple question pour information : quel(s) avantage(s) ce plugin apporte-t-il par rapport à l’utilisation de mots-clefs que l’on dédierait à cet usage ?
Les « mots-clefs » de SPIP ne sont pas arborescents, les rubriques oui. Avec ce plugin, plus besoin de ces « mots-clefs », puisque la navigation transversale peut-être réalisé avec des rubriques supplémentaires liées aux articles.
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 :
|
