[SPIP Zone] r115824 - _squelettes_/html5up_spectral

RealET · Juin 29, 2019, 8:54

spip-zone-commit@rezo.net a écrit le 29/06/2019 à 09:55 :

Author: cent20@gmail.com
Date: 2019-06-29 07:55:04 +0000 (Sat, 29 Jun 2019)
New Revision: 115824

Modified:
    _squelettes_/html5up_spectral/article.html
    _squelettes_/html5up_spectral/mot.html
    _squelettes_/html5up_spectral/plan.html
    _squelettes_/html5up_spectral/rubrique.html
    _squelettes_/html5up_spectral/sommaire.html
Log:
{titre!==^[9]} ce qui commence par 9 ne sera pas référencé.

Details: Connexion · GitLab

Il vaudrait beaucoup mieux utiliser une plugin pour ça.
Par exemple : Plugin « masquer » - SPIP-Contrib

--
RealET

jeanmarie · Juin 29, 2019, 9:01

Le 29/06/2019 à 10:54, RealET a écrit :

spip-zone-commit@rezo.net a écrit le 29/06/2019 à 09:55 :

{titre!==^[9]} ce qui commence par 9 ne sera pas référencé.

Details: Connexion · GitLab

Il vaudrait beaucoup mieux utiliser une plugin pour ça.
Par exemple : Plugin « masquer » - SPIP-Contrib

Il y a Mots techniques - SPIP-Contrib aussi selon les besoins...

Plus généralement, l'idéal est d'éviter les trucs "en dur" dans le squelette

Vincent_ROBERT · Juin 29, 2019, 11:40

Bonjour à vous deux,

Je considère ( considérais…) que {titre!==^[9]} n’était pas en "dur " dans le squelette, car pour activer cette fonctionnalité il faut décider de mettre un 9 en début d’un article, d’une rubrique, etc …

Mais s’l existe un plugin qui fait ça, alors je vais étudier la chose prochainement.

Et par la même occasion je me rend compte qu’il y en a qui lisent les commit… ^^

Mist_GraphX · Juin 29, 2019, 11:59

Le 29/06/2019 à 13:40, Vincent ROBERT a écrit :

Bonjour à vous deux,

Je considère ( considérais...) que {titre!==^[9]} n'était pas en "dur " dans le squelette, car pour activer cette fonctionnalité il faut décider de mettre un 9 en début d'un article, d'une rubrique, etc ...

Mais s'l existe un plugin qui fait ça, alors je vais étudier la chose prochainement.

Et par la même occasion je me rend compte qu'il y en a qui lisent les commit... ^^

Vincent ROBERT

Le sam. 29 juin 2019 à 11:13, Jean Marie Grall <jeanmarie.listes@cousumain.info <mailto:jeanmarie.listes@cousumain.info>> a écrit :

    Le 29/06/2019 à 10:54, RealET a écrit :
    > spip-zone-commit@rezo.net <mailto:spip-zone-commit@rezo.net> a
    écrit le 29/06/2019 à 09:55 :
    >>
    >> {titre!==^[9]} ce qui commence par 9 ne sera pas référencé.
    >>
    >> Details: Connexion · GitLab
    >>
    > Il vaudrait beaucoup mieux utiliser une plugin pour ça.
    > Par exemple : Plugin « masquer » - SPIP-Contrib

    Il y a Mots techniques - SPIP-Contrib aussi selon les
    besoins...

    Plus généralement, l'idéal est d'éviter les trucs "en dur" dans le
    squelette

    ----
    spip-zone@rezo.net <mailto:spip-zone@rezo.net> -
    https://listes.rezo.net/mailman/listinfo/spip-zone

----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

heu "ça c'était avant" masquer , mots techniques, etc

y'a le plugin pages qui sert a faire des pages autonomes ayant la rubrique -1, ça m'as l'air fait pour.

autre détail c'est que la du coup tu peut plus utiliser les prefixes de titre pour ordonner si besoin

--
Bonne journée
Arnaud B. (Mist. GraphX)

nicod · Juin 29, 2019, 1:43

Le 29/06/2019 à 13:59, Mist. GraphX a écrit :

autre détail c'est que la du coup tu peut plus utiliser les prefixes de titre pour ordonner si besoin

Pareil.

Et puis pourquoi "commence par 9" ? Ça répond à quelle logique ?

J'ai fait un truc similaire pour un site, mais j'utilise 00. comme préfixe qui masque, c'est plus compréhensible pour les rédacteurs.

--
nicod_

Vincent_ROBERT · Juin 29, 2019, 4:24

Ben au début j’ai voulu mettre {titre!==^[1]} et puis je me suis dit que c’était abusé et que tous ne comprendrais pas…

Le plugin page me plaît bien, je vais peut-être faire ainsi mais l’idée c’était d’avoir une rubrique qui contiendrait des articles qui n’ont pas être mis en avant sur le site public tout en étant parfaitement classé sur la partie privée… Il faut bien comprendre

Bon sinon « 00. » me parait être un meilleur choix, comme nicod le dit c’est pour la lisibilité des rédacteurs pas forcement experts de spip…

Merci pour vos contributions avisées !

Vincent ROBERT

Le sam. 29 juin 2019 à 14:00, Mist. GraphX <arnaud.berard@mister-graphx.com> a écrit :

Le 29/06/2019 à 13:40, Vincent ROBERT a écrit :

Bonjour à vous deux,

Je considère ( considérais…) que {titre!==^[2]} n’était pas en "dur
" dans le squelette, car pour activer cette fonctionnalité il faut
décider de mettre un 9 en début d’un article, d’une rubrique, etc …

Mais s’l existe un plugin qui fait ça, alors je vais étudier la chose
prochainement.

Et par la même occasion je me rend compte qu’il y en a qui lisent les
commit… ^^

Vincent ROBERT

Le sam. 29 juin 2019 à 11:13, Jean Marie Grall
<jeanmarie.listes@cousumain.info
mailto:[jeanmarie.listes@cousumain.info](mailto:jeanmarie.listes@cousumain.info)> a écrit :

Le 29/06/2019 à 10:54, RealET a écrit :

spip-zone-commit@rezo.net mailto:[spip-zone-commit@rezo.net](mailto:spip-zone-commit@rezo.net) a
écrit le 29/06/2019 à 09:55 :

{titre!==^[3]} ce qui commence par 9 ne sera pas référencé.

Details: https://zone.spip.org/trac/spip-zone/changeset/115824

Il vaudrait beaucoup mieux utiliser une plugin pour ça.
Par exemple : https://contrib.spip.net/Plugin-masquer

Il y a https://contrib.spip.net/Mots-techniques aussi selon les
besoins…

Plus généralement, l’idéal est d’éviter les trucs « en dur » dans le
squelette

spip-zone@rezo.net mailto:[spip-zone@rezo.net](mailto:spip-zone@rezo.net) -
https://listes.rezo.net/mailman/listinfo/spip-zone

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

heu « ça c’était avant » masquer , mots techniques, etc

y’a le plugin pages qui sert a faire des pages autonomes ayant la
rubrique -1, ça m’as l’air fait pour.

autre détail c’est que la du coup tu peut plus utiliser les prefixes de
titre pour ordonner si besoin

–
Bonne journée
Arnaud B. (Mist. GraphX)

spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

666 ↩︎
9 ↩︎
9 ↩︎

jeanmarie · Juin 29, 2019, 5:23

Plusieurs approches possibles :

les rédacteurs doivent pouvoir choisir quels articles (dans l’arborescence générale) apparaissent à cet endroit > mots clefs avec le plugin mot-clefs techniques
les rédacteurs doivent pouvoir choisir quels articles (hors arborescence générale) apparaissent à cet endroit > plugin Pages uniques
les articles sont fixes et plutôt choisis par le webmaster/administrateur > formulaire de config du plugin avec une saisie selection_article + Page uniques si pas dans l’arborescence générale

Pour un usage générique, le plugin Page unique est peut-être le plus adapté. Sinon, il va falloir créer une rubrique spéciale qui devrait être masquée, ça parait moins générique.

nicod · Juin 29, 2019, 6:49

Le 29/06/2019 à 18:24, Vincent ROBERT a écrit :

Le plugin page me plaît bien, je vais peut-être faire ainsi mais l'idée c'était d'avoir une rubrique qui contiendrait des articles qui n'ont pas être mis en avant sur le site public tout en étant parfaitement classé sur la partie privée... Il faut bien comprendre

Le plugin Masquer est une bonne option aussi pour faire ça :

Bon sinon "00." me parait être un meilleur choix, comme nicod le dit c'est pour la lisibilité des rédacteurs pas forcement experts de spip...

J'ai fait ça dans un cas très particulier, c'était une demande des utilisateurs et ils connaissent donc cette astuce spécifique, mais ça sort des pratiques éditoriales habituelles de SPIP et ça ne me semble pas une bonne idée dans un squelette générique.

A mon avis, ce que tu cherches à faire n'est pas lié au squelette lui même, donc pas à coder "en dur" dedans.

--
nicod_

Vincent_ROBERT · Juillet 1, 2019, 5:07

titre!==^ VS page VS masquer

Je viens de faire quelques tests et je ne suis pas convaincu par le plugin page que je trouve déconcertant pour un rédacteur ayant accès à la partie privé…

Je suis toutefois convaincu que vous avez raison sur le fond, sur la manière de coder les squelettes, mais les problèmes soulevés ci dessous sont vraiment bloquants.

Une fois que j’active page, le simple visiteur sur la partie privé n’a pas accès à un dossier contenant toutes les pages, ce qui est paradoxale car ces « articles » sont publics une fois publiés.

Il ne peut donc pas les retrouver via l’arborescence des rubriques. Je sais que la rubriques -1 n’existe pas mais …

Pire, en trouvant péniblement un article depuis la liste des articles, il peut le lire et on lui propose un chemin arborescent « Pages uniques > » qui l’envoie vers un message d’erreur.
« Accès interdit - Vous n’avez pas le droit d’accéder à la page pages ».

Plus ennuyeux, un article passé en « page » n’est plus accessible dans le formulaire de configuration du squelette, alors que ce sont souvent des articles de configuration #SAISIE{selecteur_article, donc si il a été sélectionné avant ça marche, c’est incompréhensible pour celui qui veut configurer son squelette…

La plugin « masquer » correspond bien à mon besoin, il est adopté ! Je rajoute donc des {tout_voir} dans les boucles méritantes

Merci de votre contribution,

Mist_GraphX · Juillet 2, 2019, 6:43

Si tes rédacteurs comprenne mieux que un article qui a le titre commençant par un prefixe ou qui a un mot clef masqué (chose que moi ils ne comprenne pas ou oublie) … tu fais bien comme tu veux c’est Ton squelette ^^

Après que les pages soit dans edition >pages uniques , je trouve que c’est pas pire que d’aller dans edition > rubrique > rubrique_masqée > article.

POur le reste c’est des autorisation ça se surcharge tu peut modifier dans le _autorisations de ton plugin.

Autoriser les rédacteurs a voir les pages uniques

A mémoriser les pages unique sont des ARTICLES il faut donc donner aussi l’autorisation aux rédacteur de voir/modiifer des articles.

function pages_autorisation_defaut($qui) {
  if ($qui['statut']=='0minirezo' OR $qui['statut']=='1comite')
        return true;
    return false;
}
function autoriser_pages_voir($faire, $type, $id, $qui, $opt) {
  if ($qui['statut']=='0minirezo' OR $qui['statut']=='1comite')
        return true;
    return false;
}
function autoriser_page_menu($faire, $type, $id, $qui, $opt) {
  if ($qui['statut']=='0minirezo' OR $qui['statut']=='1comite')
        return true;
    return false;
}
function autoriser_page_modifier($faire, $type, $id, $qui, $opt) {
  if ($qui['statut']=='0minirezo' OR $qui['statut']=='1comite')
        return true;
    return false;
}

Le truc que moi je trouve déconcertant/pas pratique dans Pages, c’est que le champ s’appelle page et pas identifiant, ce qui fait qu’on ne peut pas appeler ou passer en parametre dans l’url l’identifiant textuel de la page pour l’appeler. vu que tout les squelette de spip sont appelable par page=xx, ça se télescope forcément. Et appeler un article page/unique par son id numérique c’est pas pratique, ça perds de son intéret…

Après il manque certainement une saisie lister pages unique pour les champs de config, les menus, … c’est pas le plus dur a faire…

Bonne journée

Arnaud B.

Vincent_ROBERT · Juillet 2, 2019, 7:27

Bonjour Arnaud,

Mes « rédacteurs » seront entre 25 et 50 élèves de 1ère (16ans…) chaque année , tous nouveaux, pas forcement doué au début…

Pour le mot clé « masquer », ne t’inquiète pas, seuls les admin pourront l’ajouter, les rédacteurs n’en sauront rien, par contre le fait que les articles non référencés sur le site public soient tous dans une même rubrique ça peut les aider.

Je suis admiratif du code php qui résout mon bug d’autorisation mais ça me dépasse un peu (bcp en fait) pour l’instant.

Bonne journée à toi aussi !

jeanmarie · Juillet 2, 2019, 8:14

Salut,

Le 02/07/2019 à 08:43, GraphX a écrit :

Si tes rédacteurs comprenne mieux que un article qui a le titre commençant par un prefixe ou qui a un mot clef masqué (chose que moi ils ne comprenne pas ou oublie) … tu fais bien comme tu veux c'est Ton squelette ^^

Ça soulève la question, quand on fait un plugin, de faire le tri entre son besoin spécifique et le besoin générique.

Quand on porte un thème comme ça, déjà on le fait donc bon ! Alors on a envie de le faire coller à notre besoin, c'est assez naturel. Mais, dans l'idéal, il faut voir quel est le besoin générique (qui profitera au plus grand nombre) et quel est le besoin particulier (pour notre projet spécifique).

D'où l'idée de polyvalence pour laisser le choix à l'utilisateur lambda. Mais dans certains cas, ce n'est pas possible donc on se retrouve à devoir surcharger certains fichiers dans un plugin perso car ce sont des besoins trop spécifiques et qui compliqueraient l'utilisation du plugin pour d'autres. C'est là que l'avis de la communauté est intéressant...

                 jean marie

Mist_GraphX · Juillet 2, 2019, 12:07

Le 02/07/2019 à 09:27, Vincent ROBERT a écrit :

Je suis admiratif du code php qui résout mon bug d'autorisation mais ça me dépasse un peu (bcp en fait) pour l'instant.

Alors je le dis tout net ce n'est pas de moi comme tout le reste bien souvent, je n'invente rien, je ne donne de leçons à personne je prends des notes c'est peut être adapé quand j'ai eut a l'utiliser, la pour le coup, je n'ai pas noté la source ou l'auteur-e à l'époque (honte à moi ^^ ) …

les autorisation sont très utiles pour gérer ce que l'on veut afficher dans le privé, mais le mécanisme est pas toujours simple à comprendre, un peut comme l'API liens enfin pour moi (et mon ptit QI ^^ ), j'ai déjà passé du temps à comprendre comment faire ce que je veux …

La mon retour était surtout pour souligner ce que moi je rencontre comme problèmatiques quand j'utilise pages uniques, et ça correspond en partie a tes questions/intérogations. Après souvent je modifie l'interface privé, j'adapte a la problématique "metier" du projet, soit via les autorisations, soit en construisant des pages sur mesure ou via les css … difficile a rendre générique (mais le générique c'est ce que les devloppeur-euses veulent ou souhaiteraient, pas ce que l'utilisateur-trice final veut bien souvent).

Aussi que sur le long terme quand j'ai détourné des objets éditoriaux de leur fonction première (ce pourquoi on aime ou utilise spip aussi => la souplesse ^^), je n'ai jamais été gagnant sur le long terme (doc, formation, reprise du projet 5ans après, …) et la maintenance/mise a jour. Donc j'ai tendance a préférer (ou conseiller) pour la pérénité des objets sur mesure, que mm parfois du générique agrémenté de champs extras que je surcharge quasi intégralement due au choix du framework, des besoins d'interface privé, et du markup public …au final je fais de plus en plus de sites sans utiliser les articles ou même rubriques (ce qui pose problème,sorti de la boite sous spip pas de site sans rubrique) …

Pour exemple dernière réflexion d'une illustratrice : "pourquoi faire, une rubrique un article, y associer un document , alors que je veux publier une illustration …", c'est pas faux ben son site n'as que des documents, y compris pour le blog, pas d'articles (3 pages uniques), une rubrique book, une rubrique blog et que des docs…

Cela dit j'utilise aussi masquer (ou même le couteau suisse ^^ carrément) sur des projets ou ça convient mieux a l'utilisateur final ou au webmestre, ou si c'est un pré-requis … j'ai même des demandes, pour des skel spip sur mesure sans Zcore ou compositions tout les gouts et les apriori sont dans la nature ^^ …

bref l'avantage de spip c'est qu'on fait comme on aime ou veut au final

--
Bonne journée
Arnaud B. (Mist. GraphX)

rastapopoulos · Juillet 2, 2019, 12:43

Le 02/07/2019 à 14:07, Mist. GraphX a écrit :

bref l'avantage de spip c'est qu'on fait comme on aime ou veut au final

Évidemment, mais quand on essaye de faire des trucs partagés, utilisable
par n'importe qui, on essaye de pas faire de bidouille et de fournir un
truc le plus générique possible, tout de même.

Si ya un problème d'autorisations dans Pages Uniques, faut plutôt le
dire et le corriger ou le rendre configurable non ? Plutôt qu'obliger à
surcharger des autorisations PHP.

Ça doit quand même pas être compliqué à ajouter au form de config du
plugin une option "Qui peut voir les pages uniques", "Qui peut éditer
les pages uniques", ce genre de choses.

Le plugin sert explicitement à gérer le contenu des pages transversales
qui ne font pas partie de la vraie arborescence du site.

--
RastaPopoulos

Mist_GraphX · Juillet 4, 2019, 8:18

Le 02/07/2019 à 10:14, Jean Marie Grall a écrit :

Salut,

Le 02/07/2019 à 08:43, GraphX a écrit :

Si tes rédacteurs comprenne mieux que un article qui a le titre commençant par un prefixe ou qui a un mot clef masqué (chose que moi ils ne comprenne pas ou oublie) … tu fais bien comme tu veux c'est Ton squelette ^^

Ça soulève la question, quand on fait un plugin, de faire le tri entre son besoin spécifique et le besoin générique.

Quand on porte un thème comme ça, déjà on le fait donc bon ! Alors on a envie de le faire coller à notre besoin, c'est assez naturel. Mais, dans l'idéal, il faut voir quel est le besoin générique (qui profitera au plus grand nombre) et quel est le besoin particulier (pour notre projet spécifique).

D'où l'idée de polyvalence pour laisser le choix à l'utilisateur lambda. Mais dans certains cas, ce n'est pas possible donc on se retrouve à devoir surcharger certains fichiers dans un plugin perso car ce sont des besoins trop spécifiques et qui compliqueraient l'utilisation du plugin pour d'autres. C'est là que l'avis de la communauté est intéressant...
                jean marie

Tout à fait d'accord avec toi,

Une autre utilisation interressante de Pages que je n'avais pas pensé a citer mais que j'utilise fréquemment :

c'est la possibilité d'import/export des pages-uniques avec le plugin ieconfig_plus, ceci peut permettre de fournir une installation de base avec des pages uniques que l'on utilise souvent comme contact, mention légales, … ou des pages technique qui peuvent êtres utilisés pendant la finalisation/developement du site comme charte typo, charte formulaire, documentation des modèles,… généralement je les dépublie au final et ça fait une doc de référence du squelette, qui peut être utile pour vérifier rapidement que rien n'as cassé lors d'une maj

le plugin propose aussi l'export de mot-clefs (utile dans le cas de mots-clefs techniques), formulaires formidable (utile pour proposer des formulaires perso de base du skel comme contact) ce qui peut être interessant dans le cas d'un squelette générique ayant pas mal d'option ou fonctionalitées configurables. on peut proposer plusieurs configs importables…

--
Bonne journée
Arnaud B. (Mist. GraphX)