un besoin dont j'entend de plus en plus parler, et pour lequel je
souhaiterais trouver une réponse "propre" avec SPIP, est la gestion de
plusieurs versions d'un article.
L'idée, c'est qu'un article, une fois publié, n'est plus modifiable
par son auteur. C'est logique, ça évite qu'un auteur peu scrupuleux
aille rajouter des choses qui ne seraient pas passées à la validation.
Par contre, s'il a des mises à jour à faire, mais souhaite travailler
dessus et ne le faire publier que plus tard, tout en laissant la
version actuelle en ligne, pas moyen de faire autrement que créer un
nouvel article et y copier le contenu du précédent.
C'est simple à faire, et ça ne nécessite aucune modif de SPIP, mais du
coup, difficile de suivre les évolutions d'un même article, et de
s'assurer qu'il n'y a toujours en ligne que la dernière version
validée.
Je suis bien conscient que j'ai de plus en plus un besoin de workflow
bien plus avancé que celui proposé par SPIP, mais je ne vois pas trop
comment le mettre en place simplement à l'heure actuelle.
Deux solutions. Une table secondaire, pour stocker les articles à
valider, pour remplacer les articles en ligne, genre_spip_articles_new
avec le même n° d'ID que l'article en ligne,
Un nouvel article dans la base, mais avec un lien sur l'article en
ligne. L'article est à nouveau proposé pour la validation, une fois
validé, on écrase l'ancien par le nouveau, et on a un ID "perdu".
Dans le même ordre d'idée (En plus simple), la possibilité de créer
un nouvel article à partir d'un article existant serait un plus.
Un simple bouton "Créer un nouvel article à partir de..."
C'est bien ce que je voulais entendre par "y copier le contenu du
précédent", j'ai juste oublié de préciser que ce serait
automatisé ...
C'est vrai que c'est une fonctionnalité qui pourrait servir à pas
mal de gens.
Heureux que ça soit le cas !!!
Il faudrait :
- une nouvelle table spip_articles_versions stockant les modifs
correspondant à un article
Oui.
- éventuellement, un algo de diff sur texte permettant le stockage
sous forme différentielle (par rapport à la version suivante), et
l'affichage automatique des différences
Ca me parait un peu ambitieux, mais pourquoi pas dans une évolution.
Je pense qu'il faut mettre ça de côté pour une première version.
- un système de numérotation automatique et de marquage manuel
(comme pour les tags cvs)
Oui.
Fonctionnalités :
- activable manuellement dans la config du site
C'est clair. Que ceux qui n'en ont pas besoin ne soient pas
embrouillés.
- on ne travaille que sur la dernière version mais on peut récupérer
les anciennes versions en consultation (=> plus simple à
apprivoiser)
Uniquement dans l'interface privée, ou aussi en public ??? Ou
paramétrable, aussi ...
- dans la table spip_articles, il y a les versions "figées"
(officielle) de chaque article
Oui.
- mailer automatiquement les auteurs du texte quand il y a une
nouvelle version (le mail contient la liste des différences si
algo de diff), un nouveau marquage, un changement de version
officielle
Et idéalement, puisque'on gère complêtement les versions, une gestion
des versions proposées par les relecteurs lorsuq'un article est proposé
à l'eval ?
- on ne travaille que sur la dernière version mais on peut récupérer
les anciennes versions en consultation (=> plus simple à
apprivoiser)
Uniquement dans l'interface privée, ou aussi en public ??? Ou
paramétrable, aussi ...
A priori, pas de changement dans la boucle ARTICLES : ça n'affiche
que la version officielle de chaque article (celle qui est dans
spip_articles). Comme ça, techniquement c'est facile et pour le
webmaster c'est simple aussi.
A côté de ça, il pourrait y avoir une boucle VERSIONS qui permettrait
d'afficher les différentes versions d'un article donné (par date, etc.).
juste un mot pour dire que vos histoires de versionnage d'articles, ça me
paraît être du pur délire de téchos, et que je ne vois pas l'intérêt
dimplémenter ça dans SPIP. Mais c'est "àmha".
Si on reprend juste l'idée de départ (permettre à un rédacteur de
proposer une version mise à jour d'un article) c'est quand même
intéressant (àmha à moi perso;).
La solution de lui demander de travailler sur une copie de l'article
n'est pas géniale car elle demande un peu de manip mais surtout change
le numéro de l'article (liens internes cassés ensuite si on veut swapper
les deux articles).
juste un mot pour dire que vos histoires de versionnage d'articles, ça me
paraît être du pur délire de téchos, et que je ne vois pas l'intérêt
dimplémenter ça dans SPIP. Mais c'est "àmha".
Ben, si tu travailles à plusieurs sur un texte au long cours
(ou même un article vachement fignolé), c'est très très utile
de pouvoir récupérer une ancienne version, de créer une nouvelle
version sans zigouiller celle en cours. Si tu crées des articles
"bidons" pour gérer ça à la main, c'est totalement bordélique dès
qu'il y a plus de deux versions à stocker.
Y a aussi des gens qui utilisent SPIP pour de la doc, ou pour
des textes à délibération un peu plus solennelle que le webzine
de base (imaginons la communication externe d'une assoce : les
membres du CA veulent la changer sans forcément que ça apparaisse
tout de suite en ligne, en attendant que ce soit validé par
l'ensemble de l'équipe). Actuellement le seul outil vaguement
utilisable est l'affichage des modifs sous Word, mais ça implique
d'échanger sans arrêt les versions par mail (les emmerdes
habituelles : y en a toujours un qui a oublié d'envoyer ou de
récupérer la dernière version) et c'est pas vraiment commode.
