#4 exclure des rubriques de la racine

Closed
opened 8 months ago by olivier_t · 16 comments
Collaborator

Dans la V1 du squelette, il etait possible d'exclure de tout affichage certaines rubriques (techniques, par exemple).
j'aimais bien.
Il y avait deux comportements interessants :

  • elles n'etaient pas affichées sur le sommaire (cela est possible avec la V2, car on peut décider de choisir les rubriques à afficher, et donc n'afficher qu'un subset des rubriques de la racine)
  • elles n'etaient pas affichées dans le sidemenu

La version v2 ne permet pas le second comportement sans devoir modifier le squelette sidemenu.

Est-ce KISS de proposer une case à remplir dans le panneau de configuration, ou bien laissons-nous cela aussi (et il est necessaire de coder une variante de squelette) ?

Dans la V1 du squelette, il etait possible d'exclure de tout affichage certaines rubriques (techniques, par exemple). j'aimais bien. Il y avait deux comportements interessants : - elles n'etaient pas affichées sur le sommaire (cela est possible avec la V2, car on peut décider de choisir les rubriques à afficher, et donc n'afficher qu'un subset des rubriques de la racine) - elles n'etaient pas affichées dans le sidemenu La version v2 ne permet pas le second comportement sans devoir modifier le squelette sidemenu. Est-ce KISS de proposer une case à remplir dans le panneau de configuration, ou bien laissons-nous cela aussi (et il est necessaire de coder une variante de squelette) ?
Poster
Collaborator

j'aivu par hasard qu'il existe le plugin "Exclure secteur". ca fait peut etre l'affaire

j'aivu par hasard qu'il existe le plugin "Exclure secteur". ca fait peut etre l'affaire
Poster
Collaborator

j'ai testé. Cela fonctionne... un peu trop!
L'effet de bord, c'est que cela exclut aussi des articles qu'on aurait chosis comme "hero" "majeur" ou "mineur".

cela peut se contourner en modifiant le squelette avec un critère {tout voir}, mais cela ne fait que déplacer le problème

j'ai testé. Cela fonctionne... un peu trop! L'effet de bord, c'est que cela exclut aussi des articles qu'on aurait chosis comme "hero" "majeur" ou "mineur". cela peut se contourner en modifiant le squelette avec un critère \{tout voir\}, mais cela ne fait que déplacer le problème

Mon avis : si les menus étaient avec Menus, et non pas tout automatiques, ça permettrait de choisir quoi mettre dedans (et donc pas forcément tout à la racine).

Mon avis : si les menus étaient avec Menus, et non pas tout automatiques, ça permettrait de choisir quoi mettre dedans (et donc pas forcément tout à la racine).
Collaborator

@olivier_t : Si la rubrique (et ses articles) ne sont accessibles ni par le menu, ni par l'accueil, par où on y accéde ? Si on n'y accède que par des liens rajoutés manuellement quelque part (squelette, contenu...), est-ce que le plugin Pages uniques ne serait la solution ?

@rastapopoulos : Perso, je suis pas fan du plugin qui nécessite des plugins pour des fonctions non indispensables car c'est souvent préjuger de l'usage de l'utilisateur final. Après, on peut tester l'existence d'un menu principal via le plugin Menus dans l'idée de ce qu'on fait dans le pied des autres plugins HTML5up pour le pied de page https://git.spip.net/spip-contrib-squelettes/html5up_forty/src/branch/master/footer/dist.html#L50.

Bon, je me trompe peut-être, mais je me dis que quelqu'un qui maitrise l'utilisation plugin Menus n'est pas loin, avec un peu d'aide de la communauté, de maitriser la notion de surcharge des squelettes sans, dans ce cas précis en tout cas, risquer grand chose sur le long terme niveau évolution du plugin.

@olivier_t : Si la rubrique (et ses articles) ne sont accessibles ni par le menu, ni par l'accueil, par où on y accéde ? Si on n'y accède que par des liens rajoutés manuellement quelque part (squelette, contenu...), est-ce que le plugin Pages uniques ne serait la solution ? @rastapopoulos : Perso, je suis pas fan du plugin qui nécessite des plugins pour des fonctions non indispensables car c'est souvent préjuger de l'usage de l'utilisateur final. Après, on peut tester l'existence d'un menu principal via le plugin Menus dans l'idée de ce qu'on fait dans le pied des autres plugins HTML5up pour le pied de page https://git.spip.net/spip-contrib-squelettes/html5up_forty/src/branch/master/footer/dist.html#L50. Bon, je me trompe peut-être, mais je me dis que quelqu'un qui maitrise l'utilisation plugin Menus n'est pas loin, avec un peu d'aide de la communauté, de maitriser la notion de surcharge des squelettes sans, dans ce cas précis en tout cas, risquer grand chose sur le long terme niveau évolution du plugin.

Si la rubrique (et ses articles) ne sont accessibles ni par le menu, ni par l’accueil, par où on y accéde

Ce n'est pas à toi de décider comment les gens rangent leurs contenus. Si une personne veut faire des rubriques qui justement ne doivent pas être visibles par défaut, mais seulement pour des liens ailleurs, c'est son droit. Mais oui si c'est spécifiquement pour faire des pages différentes autonomes alors ça devrait être avec Pages Uniques. Mais ce n'est pas forcément pour ça : ça peut aussi être pour donner accès à une rubrique entière ailleurs, mais qui n'a pas à apparaitre en menu principal (parce que pas à ce point important, qu'on veut que le menu principal ait moins d'entrées, seulement les trucs efficaces, ou que c'est que pour tel profil de personne, etc).

pour des fonctions non indispensables

Euh on parle du menu… en quoi c'est pas indispensable ? :)
Si en plus on parle du menu principal c'est encore plus indispensable. Quasiment toujours les gens me demandent à ce qu'ils aient la main sur le menu principal, c'est quand même LE truc central qu'on voit en premier et qui est le cœur de la navigation… donc le forcer à être automatique et n'avoir aucunement la main dessus…

Et non, utiliser une interface d'admin, c'est totalement différent de savoir surcharger des squelettes. Sachant que le principe des squelettes "prêts à l'emploi" c'est aussi dans plein de cas que les gens n'ont pas accès à la technique à l'admin sys donc à aucun moment à surcharger eux-mêmes : les admins du contenu du site, ça n'a rien à avoir avec les admins du serveur.

> Si la rubrique (et ses articles) ne sont accessibles ni par le menu, ni par l’accueil, par où on y accéde Ce n'est pas à toi de décider comment les gens rangent leurs contenus. Si une personne veut faire des rubriques qui justement ne doivent pas être visibles par défaut, mais seulement pour des liens ailleurs, c'est son droit. Mais oui si c'est spécifiquement pour faire des pages différentes autonomes alors ça devrait être avec Pages Uniques. Mais ce n'est pas forcément pour ça : ça peut aussi être pour donner accès à une rubrique entière ailleurs, mais qui n'a pas à apparaitre en menu principal (parce que pas à ce point important, qu'on veut que le menu principal ait moins d'entrées, seulement les trucs efficaces, ou que c'est que pour tel profil de personne, etc). > pour des fonctions non indispensables Euh on parle du menu… en quoi c'est pas indispensable ? :) Si en plus on parle du menu *principal* c'est encore plus indispensable. Quasiment toujours les gens me demandent à ce qu'ils aient la main sur le menu principal, c'est quand même LE truc central qu'on voit en premier et qui est le cœur de la navigation… donc le forcer à être automatique et n'avoir aucunement la main dessus… Et non, utiliser une interface d'admin, c'est totalement différent de savoir surcharger des squelettes. Sachant que le principe des squelettes "prêts à l'emploi" c'est aussi dans plein de cas que les gens n'ont pas accès à la technique à l'admin sys donc à aucun moment à surcharger eux-mêmes : les admins du contenu du site, ça n'a rien à avoir avec les admins du serveur.
Poster
Collaborator
  • @olivier_t : Si la rubrique (et ses articles) ne sont accessibles ni par le menu, ni par l'accueil, par où on y accéde ? Si on n'y accède que par des liens rajoutés manuellement quelque part (squelette, contenu...), est-ce que le plugin Pages uniques ne serait la solution ?

oui, je sais ça a l'air étrange. J'ai découvert moi aussi ce comportement. c'est adressé dans la doc du plugin, et ca se gère par un critère supplémentaire (pour des cas très particuliers):
https://contrib.spip.net/Plugin-Exclure-secteur#Faire-des-exceptions
Après des tests, comme je l'ai ecris, je pense que cela ne fait que déplacer le problème. Donc, je ne pense pas que le plugin "exclure_rubrique" puisse etre utilisé dans ce cas.

  • Utiliser Menus (pour les menus) me parait plus judicieux.
    Il serait peut-être aussi possible d'utiliser Menus pour le choix de ce que l'on doit afficher sur la page sommaire (le procédé est simple).

  • et pour rester simple pour le novice au besoin limité, cela n'empeche évidement pas que le plugin propose par défaut d'afficher toutes les rubriques de la racine + les mettre dans le menu. L'utilisateur avancé téléchargera Menu pour simplement compliquer cela.

  • je plussoie "utiliser une interface d’admin, c’est totalement différent de savoir surcharger des squelettes".

- > @olivier_t : Si la rubrique (et ses articles) ne sont accessibles ni par le menu, ni par l'accueil, par où on y accéde ? Si on n'y accède que par des liens rajoutés manuellement quelque part (squelette, contenu...), est-ce que le plugin Pages uniques ne serait la solution ? oui, je sais ça a l'air étrange. J'ai découvert moi aussi ce comportement. c'est adressé dans la doc du plugin, et ca se gère par un critère supplémentaire (pour des cas très particuliers): https://contrib.spip.net/Plugin-Exclure-secteur#Faire-des-exceptions Après des tests, comme je l'ai ecris, je pense que cela ne fait que déplacer le problème. Donc, je ne pense pas que le plugin "exclure_rubrique" puisse etre utilisé dans ce cas. - Utiliser Menus (pour les menus) me parait plus judicieux. Il serait peut-être aussi possible d'utiliser Menus pour le choix de ce que l'on doit afficher sur la page sommaire (le procédé est simple). - et pour rester simple pour le novice au besoin limité, cela n'empeche évidement pas que le plugin propose par défaut d'afficher toutes les rubriques de la racine + les mettre dans le menu. L'utilisateur avancé téléchargera Menu pour simplement compliquer cela. - je plussoie "utiliser une interface d’admin, c’est totalement différent de savoir surcharger des squelettes".
Poster
Collaborator

disons que la V1 du plugin etait une version simple, codée en dur, qui n'etait qu'un simple canevas dans lequel l'utilisateur adaptait son contenu au squelette.

j'ai l'impression que si il a été décidé de coder la V2 avec zcore, c'est qu'il y avait plus d'ambition pour ce plugin/squelette, et donc autant le rendre compatible avec un des plugins les plus commun (Menus)

disons que la V1 du plugin etait une version simple, codée en dur, qui n'etait qu'un simple canevas dans lequel l'utilisateur adaptait son contenu au squelette. j'ai l'impression que si il a été décidé de coder la V2 avec zcore, c'est qu'il y avait plus d'ambition pour ce plugin/squelette, et donc autant le rendre compatible avec un des plugins les plus commun (Menus)

Il serait peut-être aussi possible d’utiliser Menus pour le choix de ce que l’on doit afficher sur la page sommaire (le procédé est simple).

C'est plutôt le plugin Sélections éditoriales qui sert très précisément à ça (et que j'utilise sur toutes mes "animations éditoriales de pages d'accueil". :)

> Il serait peut-être aussi possible d’utiliser Menus pour le choix de ce que l’on doit afficher sur la page sommaire (le procédé est simple). C'est plutôt le plugin Sélections éditoriales qui sert très précisément à ça (et que j'utilise sur toutes mes "animations éditoriales de pages d'accueil". :)
Collaborator

Je pensais "pas indispensable" dans le sens où il y a un système qui fonctionne de base (le squelette), sans avoir à installer un plugin (Menus) :)

Je comprends bien les exemples donnés, mais ça ne me semble pas être le cas générique, donc obliger à installer systématiquement un plugin ne me semble pas être la solution : par ex pour ma part, on ne me demande jamais d'avoir la main dessus, donc Menus serait contreproductif.
Après, pourquoi pas le faire de façon optionnelle comme proposé ?

Pour la surcharge des squelettes, je pensais à la personne qui est capable d'installer un site SPIP sur un hébergement, pas aux utilisateur·rices de l'admin bien sûr. Mais il est vrai que c'est un besoin (gérer le menu) qui peut apparaitre plus tard.

Plus globalement, on parle de la limite des sites tout en un click-and-play capables de tout faire. Perso, j'y crois moyennement : dès qu'on va vouloir un usage ou des fonctionnalités un peu spécifiques, il faudra certainement mettre les mains dans le cambouis car on ne peut pas, à la conception, penser tous ces besoins/usages. Ou alors on repart sur Sarka qui fait tout mais qui est complexe à maintenir.

D'où mon point de vue de souhaiter garder un fonctionement le plus générique possible sachant qu'on a la chance d'avoir une communauté réactive qui accompagne les utilisateur·rices en cas de besoin. Mais comme toujours, c'est une question de curseur : où chacun place le générique ? :)

Je pensais "pas indispensable" dans le sens où il y a un système qui fonctionne de base (le squelette), sans avoir à installer un plugin (Menus) :) Je comprends bien les exemples donnés, mais ça ne me semble pas être le cas générique, donc obliger à installer systématiquement un plugin ne me semble pas être la solution : par ex pour ma part, on ne me demande jamais d'avoir la main dessus, donc Menus serait contreproductif. Après, pourquoi pas le faire de façon optionnelle comme proposé ? Pour la surcharge des squelettes, je pensais à la personne qui est capable d'installer un site SPIP sur un hébergement, pas aux utilisateur·rices de l'admin bien sûr. Mais il est vrai que c'est un besoin (gérer le menu) qui peut apparaitre plus tard. Plus globalement, on parle de la limite des sites tout en un click-and-play capables de tout faire. Perso, j'y crois moyennement : dès qu'on va vouloir un usage ou des fonctionnalités un peu spécifiques, il faudra certainement mettre les mains dans le cambouis car on ne peut pas, à la conception, penser tous ces besoins/usages. Ou alors on repart sur Sarka qui fait tout mais qui est complexe à maintenir. D'où mon point de vue de souhaiter garder un fonctionement le plus générique possible sachant qu'on a la chance d'avoir une communauté réactive qui accompagne les utilisateur·rices en cas de besoin. Mais comme toujours, c'est une question de curseur : où chacun place le générique ? :)
Poster
Collaborator

le plugin peut avoir un comportement par défaut (menu, sommaire) simple, comme l'idée du theme html5up initial, mais si l'utilisateur le souhaite, il peut activer Menus et Selection Editoriale et ces plugins prennent la main.

Cela simplifie (externalise) la maintenance de ce plugin, car c'est Menus et Selection Editoriale qui restent à jour.

le plugin peut avoir un comportement par défaut (menu, sommaire) simple, comme l'idée du theme html5up initial, mais si l'utilisateur le souhaite, il peut activer Menus et Selection Editoriale et ces plugins prennent la main. Cela simplifie (externalise) la maintenance de ce plugin, car c'est Menus et Selection Editoriale qui restent à jour.

Ouais c'est régulièrement ce que je fais, par ex en prenant une sélection "accueil" en priorité si existante, mais soit si le plugin n'est pas là soit si la sélection de ce nom n'existe pas, soit si elle est vide, alors ça fait une liste auto des X derniers trucs. Disons que dans le code c'est plutôt la formulation inverse : on utilise en priorité un plugin qui fournit une interface (et qu'on n'a pas à maintenir, et ça fait moins de panneau de config du squelettes justement), mais sans l'obliger, avec un fallback auto si pas présent.

Ouais c'est régulièrement ce que je fais, par ex en prenant une sélection "accueil" en priorité si existante, mais soit si le plugin n'est pas là soit si la sélection de ce nom n'existe pas, soit si elle est vide, alors ça fait une liste auto des X derniers trucs. Disons que dans le code c'est plutôt la formulation inverse : on utilise en priorité un plugin qui fournit une interface (et qu'on n'a pas à maintenir, et ça fait moins de panneau de config du squelettes justement), mais sans l'obliger, avec un fallback auto si pas présent.
Collaborator

Quand je parle de complexité à maintenir, je parle aussi de code plus ou moins simple et donc que plus ou moins de gens pourront maintenir dans le temps. Et je sais bien qu'ajouter juste un test pour le menu n'est pas ultra complexe mais je sais aussi qu'il y aura d'autres cas comme ça dans le futur. Sarka ne s'est pas fait en un jour... ou alors c'est Rome ? :)

Après tant que ça n'ajoute pas de necessite et que le comportement par défaut ne change pas, gogogo...

Quand je parle de complexité à maintenir, je parle aussi de code plus ou moins simple et donc que plus ou moins de gens pourront maintenir dans le temps. Et je sais bien qu'ajouter juste un test pour le menu n'est pas ultra complexe mais je sais aussi qu'il y aura d'autres cas comme ça dans le futur. Sarka ne s'est pas fait en un jour... ou alors c'est Rome ? :) Après tant que ça n'ajoute pas de necessite et que le comportement par défaut ne change pas, gogogo...
Poster
Collaborator

J'ai remplacé ainsi le contenu du fichier inclure/sidemenu.html du plugin

<BOUCLE_test(CONDITION){si #PLUGIN{menus}|oui}>
	<nav id="nav">
	<ul>
	<li class="special">
	<a href="#menu" class="menuToggle"><span>Menu</span><i class="fas fa-bars"></i></a>
	<div id="menu">
	<INCLURE{fond=inclure/menu,env} />
	</div>
	</ul>	
	</nav>
</BOUCLE_test>

[(#REM) j'ai mis ici le reste du contenu de l'ancien fichier inclure/sidemenu.html]

<//B_test>

note: j'ai essayé demetre la conditions de test à l'intérieur de la boucle rubriques, mais il y avait des soucis de boucles imbriquées. Cela fonctionne ainsi.

J'ai remplacé ainsi le contenu du fichier inclure/sidemenu.html du plugin ``` <BOUCLE_test(CONDITION){si #PLUGIN{menus}|oui}> <nav id="nav"> <ul> <li class="special"> <a href="#menu" class="menuToggle"><span>Menu</span><i class="fas fa-bars"></i></a> <div id="menu"> <INCLURE{fond=inclure/menu,env} /> </div> </ul> </nav> </BOUCLE_test> [(#REM) j'ai mis ici le reste du contenu de l'ancien fichier inclure/sidemenu.html] <//B_test> ``` note: j'ai essayé demetre la conditions de test à l'intérieur de la boucle rubriques, mais il y avait des soucis de boucles imbriquées. Cela fonctionne ainsi.

Généralement de mon côté je fais plutôt :

<BOUCLE_menu_principal(MENUS?){identifiant=firstnav}>
	<INCLURE  ce menu> et des trucs autour s'il faut
</BOUCLE_menu_principal>
	fallback menu automatique
<//B_menu_principal>
Généralement de mon côté je fais plutôt : ``` html <BOUCLE_menu_principal(MENUS?){identifiant=firstnav}> <INCLURE … ce menu> et des trucs autour s'il faut </BOUCLE_menu_principal> fallback menu automatique <//B_menu_principal> ```
Poster
Collaborator

j'ai modifié le squelette content/sommaire.html de la sorte, en utilisant le plugins selections_editoriales, pour sélectionner l'article Hero, les rubriques, l'article major, l'article minor, sans devoir passer par le panneau de configuration,

exemple pour le section one:

<B_hero>
<section id="one" class="wrapper style1 special">
<BOUCLE_hero(SELECTIONS){identifiant=html5up_hero}>

		<BOUCLE_hero_contenus(SELECTIONS_CONTENUS){id_selection}{par rang}>
<B_hero_article>	
	<div class="inner">
			<BOUCLE_hero_article(ARTICLES){id_article=#ID_OBJET}{lang}>

		<header class="major">
			[<h2>(#TITRE)</h2>]
			[<div class="chapo #EDIT{chapo}">(#CHAPO)</div>]
		</header>
		[<ul class="actions stacked">
			<li><a href="(#URL_ARTICLE_ABSOLU)" class="button fit"><:html5up:lire_la_suite:></a></li>
		</ul>]

			</BOUCLE_hero_article>
	</div>
</B_hero_article>
		</BOUCLE_hero_contenus>
</BOUCLE_hero>
</section>
</B_hero>

note:

  • l'utilisateur doit activer le plugin et créer une selection éditoriale nommée html5up_hero

  • ce n'est pas très propre, mais dans cette selection éditoriale, l'utilisateur peut mettre les articles hero dans différentes langue. Seul l'article Hero dans la langue du contexte sera affiché (devrait être fait avec {traduction}

  • en effet, j'utilise Multidomaine (avec un secteur par langue) avec ce squelette,

  • je n'ai pas mis de fallback sur l'article Hero si l'utilisateur n'a pas installé Selections Editoriales

j'ai modifié le squelette content/sommaire.html de la sorte, en utilisant le plugins selections_editoriales, pour sélectionner l'article Hero, les rubriques, l'article major, l'article minor, sans devoir passer par le panneau de configuration, exemple pour le section one: ``` <B_hero> <section id="one" class="wrapper style1 special"> <BOUCLE_hero(SELECTIONS){identifiant=html5up_hero}> <BOUCLE_hero_contenus(SELECTIONS_CONTENUS){id_selection}{par rang}> <B_hero_article> <div class="inner"> <BOUCLE_hero_article(ARTICLES){id_article=#ID_OBJET}{lang}> <header class="major"> [<h2>(#TITRE)</h2>] [<div class="chapo #EDIT{chapo}">(#CHAPO)</div>] </header> [<ul class="actions stacked"> <li><a href="(#URL_ARTICLE_ABSOLU)" class="button fit"><:html5up:lire_la_suite:></a></li> </ul>] </BOUCLE_hero_article> </div> </B_hero_article> </BOUCLE_hero_contenus> </BOUCLE_hero> </section> </B_hero> ``` note: - l'utilisateur doit activer le plugin et créer une selection éditoriale nommée html5up_hero - ce n'est pas très propre, mais dans cette selection éditoriale, l'utilisateur peut mettre les articles hero dans différentes langue. Seul l'article Hero dans la langue du contexte sera affiché (devrait être fait avec {traduction} - en effet, j'utilise Multidomaine (avec un secteur par langue) avec ce squelette, - je n'ai pas mis de fallback sur l'article Hero si l'utilisateur n'a pas installé Selections Editoriales
Collaborator

Ceci devrait convenir à tout le monde : 266dde37fb
pour ce qui est du menu principal

Ceci devrait convenir à tout le monde : https://git.spip.net/spip-contrib-squelettes/html5up_spectral/commit/266dde37fbb99cad806be4cf4b809eb00e42cc34 pour ce qui est du menu principal
chankalan closed this issue 1 month ago
Sign in to join this conversation.
No Label
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.