On pourrait effectivement créer une rubrique à l'installation. Et ensuite, peut-être simplement interdire la suppression d'une rubrique si c'est la dernière ?
Quel problème pourrait poser l'existence forcée d'une rubrique vide ? Autrement dit: dans quels cas peut-on vouloir un site en production totalement dépourvu d'articles et de rubriques, même vides ?
Désolé de répondre au-dessus du message d'origine, le client mail de symbian est naze.
Pour simplifier le système de création d'articles à la volée ne plus simple n'est-il pas d'ajouter en natif un système de gestion de page unique (cf le plugin de même nom) ?
En gros, garder d'un coté le modèle structurant rubriques>articles et ajouter un champ 'type' ou 'objet' dans spip_articles pour pouvoir contrôler le type de contenu. Ce champ 'type/objet' permettrait de référencer le type de contenu crée ('article' ou 'page'). Ainsi, les articles non attachés à une rubrique seraient automatiquement spécifiés comme 'page' avec une id_rubrique définie en -1.
Et l'interface vierge après première installation pourrait proposer un bouton de création de page unique et un bouton de création de rubrique. Le bouton de création de page unique pointant sur exec=article_edit avec épuration contextuelle de la page court-circuitant toutes les informations relatives aux rubriques.
Pour simplifier le système de création d’articles à la volée ne plus simple n’est-il pas d’ajouter en natif un système de gestion de page unique (cf le plugin de même nom) ?
En gros, garder d’un coté le modèle structurant rubriques>articles et ajouter un champ ‹ type › ou ‹ objet › dans spip_articles pour pouvoir contrôler le type de contenu. Ce champ ‹ type/objet › permettrait de référencer le type de contenu crée (‹ article › ou ‹ page ›). Ainsi, les articles non attachés à une rubrique seraient automatiquement spécifiés comme ‹ page › avec une id_rubrique définie en -1.
Et l’interface vierge après première installation pourrait proposer un bouton de création de page unique et un bouton de création de rubrique. Le bouton de création de page unique pointant sur exec=article_edit avec épuration contextuelle de la page court-circuitant toutes les informations relatives aux rubriques.
Là je suis assez d’accord ! Généraliser le principe de page unique me parait ici le plus opportun et répondrait de ce que j’en visualise, à plus de besoin que la systématisation d’un rubriquage forcé.
Perso, je considère la rubrique comme un objet éditorial au même titre que l’article ou que le site référencé. Or, une méthode éditoriale, quand j’en n’ai pas besoin je l’utilise pas. Là avec les rubriques c’est pas possible.
Puis, si l’on corrobore ce débat avec les récents échanges qu’il y a eu autour du court-circuit et des cas d’articles uniques, je me dis qu’en intégrant « page unique » au core, on tord le cou une bonne fois à ces problématique en 2/2…
On pourrait effectivement créer une rubrique à l'installation. Et ensuite, peut-être simplement interdire la suppression d'une rubrique si c'est la dernière ?
Quel problème pourrait poser l'existence forcée d'une rubrique vide ? Autrement dit: dans quels cas peut-on vouloir un site en production totalement dépourvu d'articles et de rubriques, même vides ?
un site qu'avec des mots-clés (j'en ai un) mais, même dans ce cas, une rubrique vide ne gêne pas puisqu'elle n'apparait pas en public
le mot et le groupe de mots sont les seuls objets (avec les auteurs) à ne pas avoir besoin de rubrique
J'ai des sites où il y a essentiellement des objets non-SPIP + quelques articles transversaux où je n'ai absolument pas besoin de rubriques. J'utilise alors le plugin Pages pour faire un article de contact, un article de mentions légales et basta.
Il vaudrait peut-être mieux permettre dans le core de créer des articles non-classés, et comme le fait le plugin, de pouvoir permuter à tout moment entre page et article classé.
Lorsqu'on a très peu d'articles SPIP dans un site, c'est justement "débile" et peu intuitif de se dire qu'on doit avoir un site avec juste une rubrique. Les rubriques ont un intérêt uniquement s'il y en a plusieurs, puisque c'est un système de catégorisation de l'information.
Quel problème pourrait poser l'existence forcée d'une rubrique vide ? Autrement dit: dans quels cas peut-on vouloir un site en production totalement dépourvu d'articles et de rubriques, même vides ?
J'ai des sites où il y a essentiellement des objets non-SPIP + quelques articles transversaux où je n'ai absolument pas besoin de rubriques. J'utilise alors le plugin Pages pour faire un article de contact, un article de mentions légales et basta.
Ça m'intéresse
Pourrais-tu donner quelques exemples ?
Il vaudrait peut-être mieux permettre dans le core de créer des articles non-classés, et comme le fait le plugin, de pouvoir permuter à tout moment entre page et article classé.
+1
Lorsqu'on a très peu d'articles SPIP dans un site, c'est justement "débile" et peu intuitif de se dire qu'on doit avoir un site avec juste une rubrique. Les rubriques ont un intérêt uniquement s'il y en a plusieurs, puisque c'est un système de catégorisation de l'information.
Plutôt que de créer systématiquement une première rubrique, l'installation de SPIP pourrait laisser le choix à l'étape finale entre "installer la base de démarrage" ou "terminer l'installation maintenant", comme cela se pratique dans d'autres outils de publication.
ce n'est pas débile, ça évite de tomber dans les travers de
Wordpress avec la confusion des pages qui sont appelées par
articles, et des articles qui sont appelées avec p (ou l'inverse).
Se garder la possibilité de choisir, c'est une bonne idée, parce que
ça laisse un choix.
Que renverrait une boucle RUBRIQUES dans cette situation? etc?
Mais essayons de ne pas faire les mêmes erreurs que dans Wordpress.
[...]
Lorsqu'on a très peu d'articles SPIP dans un site, c'est justement
"débile" et peu intuitif de se dire qu'on doit avoir un site avec
juste une rubrique. Les rubriques ont un intérêt uniquement s'il y
en a plusieurs, puisque c'est un système de catégorisation de
l'information.
Bonsoir,
ce n'est pas débile, ça évite de tomber dans les travers de
Wordpress avec la confusion des pages qui sont appelées par
articles, et des articles qui sont appelées avec p (ou l'inverse).
Se garder la possibilité de choisir, c'est une bonne idée, parce que
ça laisse un choix.
En quoi le système pages/posts est-il confus sur WP ?
Les pages sont des conteneurs d’info, les posts des billets/articles imbriqués.
Les pages sont plus que nécessaires non seulement pour gérer des contenus spécifiques (par ex : des formulaires, ou
des contenus exclusifs) mais aussi pour pouvoir manier des objets non éditoriaux. Les CMS actuels (qui ont le vent en poupe) tendent à dépasser le cadre d’une gestion éditoriale pure et dure. Le système de page doit apporter un complément à la logique tout edito (spip comme framework).
dans WP, il y a la notion d'articles et de pages. Sur l'un on peut
associer des attributs, sur l'autre non. A l'inverse, sur le second
il y a un truc que l'on ne peut pas avoir. Bref, c'est vite
l'impasse, et il faut être attentif à ne pas avoir le même genre de
contraintes à la noix dans Spip.
Ça semble super intéressant.
Y a-t-il plus de détails sur la manière de l'utiliser, l'installer, etc. ?
Le Samedi 30 Avril 2011 15:54:14 bruno bergot <brunobergot@gmail.com>, dans un message intitulé "Re: [spip-dev] Rubrique 1 à l'installe, toujours là pour toi" nous a informés :