Une erreur que je vois très souvent commise, c'est un (jeune) admin qui crée une rubrique en croyant créer un article.
Et qui après se demande comment publier son article (sauf que c'est une rubrique, du coup, c'est pas possible).
Un bouton, convertir la rubrique en article (ou un plugin pour faire ça), ça serait bien pratique (copier/coller, c'est possible, mais fastidieux).
On crée un article, mais au bout d'un certain temps de vie, il s'avère qu'on veut mettre des sous-pages à celui-ci. Ça arrive très souvent dans la vie d'un site qui bouge.
Il faudrait donc pouvoir le transformer en rubrique, sans perdre son contenu (mais là il manque des champs) ni son URL (ça c'est plus facile). Le problème étant qu'une rubrique a moins de champs et n'est pas non lié à des auteurs de la même façon.
Une erreur que je vois très souvent commise, c'est un (jeune) admin qui crée une rubrique en croyant créer un article.
Et qui après se demande comment publier son article (sauf que c'est une rubrique, du coup, c'est pas possible).
Un bouton, convertir la rubrique en article (ou un plugin pour faire ça), ça serait bien pratique (copier/coller, c'est possible, mais fastidieux).
Je plussoie. Il n'y a pas que les jeunes admin qui font cette erreur, mais d'autres rédacteurs plus aguerris. Cela m'arrive aussi…
Une façon simple d'éviter l'erreur (pas besoin de dev) serait d'éviter de présenter ces objets de façon visuellement identique.
L'inverse serait tout aussi intéressant :
Oui, c'est ce qui me fait questionner la pertinence des rubriques dans SPIP…
On crée un article, mais au bout d'un certain temps de vie, il s'avère qu'on veut mettre des sous-pages à celui-ci. Ça arrive très souvent dans la vie d'un site qui bouge.
Il faudrait donc pouvoir le transformer en rubrique, sans perdre son contenu (mais là il manque des champs) ni son URL (ça c'est plus facile). Le problème étant qu'une rubrique a moins de champs et n'est pas non lié à des auteurs de la même façon.
Mais contrairement au problème initial, il existe une solution, très simple : créer une rubrique parente dans laquelle ranger cet article, c'est tout. Puis l'afficher, via squelettes ou plugin dédié, comme première page de cette rubrique et y lister ses copines.
Pourquoi (à part l'histoire) n'avons-nous pas un object unique avec une colonne qui indique s'il peut en contenir un autre (rubrique) ou pas (article) ?
Si on fait cette petite révolution on réduit les formations à la rédaction du contenu sur intranet de 50%
ça va laisser du temps pour aller à la pêche!
Si on va par là il n'y a plus qu'à créer un objet éditorial unique avec son type pour paramètre. Objet = rubrique, article, brève, auteur, site. On n'aurait plus qu'une boucle unique avec le type en paramètre du genre <BOUCLE_principale(OBJETS){id_objet}{rubrique}…> ce qui , je m'avance, pourrait faciliter l'écriture des jointures.
Si on ne veut pas aller par là ça serait bien de standardiser les champs de bases de chaque objet : titre , description, contenu quitte à leur rajouter leurs champs spécifiques, un peu à l'image de extensions / plugins pour faciliter la portabilité d'un objet à l'autre (mais pourquoi diable vouloir changer un site en rubrique et un auteur en article sauf pour réparer une erreur … ?)
Pourquoi (à part l'histoire) n'avons-nous pas un object unique avec
une colonne qui indique s'il peut en contenir un autre (rubrique) ou
pas (article) ?
Même une telle colonne ne serait généralement pas nécessaire: tous les
"rubricles" (cet objet, quoi) pourraient avoir des descendants.
C'est le cas des entrées LDAP: chaque entrée peut avoir des
sous-entrées.
Sur un plan pratique, est-ce qu'ajouter un champ id_parent aux articles
ne serait pas suffisant ? En généralisant, est-ce qu'on pourrait se
dire que tout objet doté d'un champ id_parent est hiérarchisable ?