Le Suivi des Révisions (d’Articles etc..)

L’activation des Révisions se fait dans un menu de Configuration, et sera traitée dans le ./plugins-dist/revisions/ qui est un plugin verrrouillé [1].

Les Tables de VERSIONS

Selon les nouvelles habitudes de SPIP 3 les tables de VERSIONS sont désormais des tables de liaison implicites, avec la clé primaire habituelle, et l’index par le champ objet et le champ id_objet, permettant d’attacher cette révision à son objet éditorial de référence.
-  la table VERSIONS contient une ligne enregistrée par modification, identifiée par sa clé primaire id_version...
Deux champs id_auteur et date assurent un horo-datage automatique de cette révision de l’objet concerné (clés ci-dessus)...
Des champs titre et permanent proposent d’affiner ce suivi, le premier est chargé à « Version initiale » lors de la création de l’objet (en base, correspondant à l’auteur -1), et le second reçoit la valeur ’non’ à chaque modification de l’occurrence d’objet éditorial...
Enfin le champ champs contient un tableau associatif des id clés de fragments modifies, associés aux noms de champs concernés de l’enregistrement révisé...
Un exemple partiel pour une création d’article : a:13:{s:11:"id_rubrique";s:1:"1";s:8:"surtitre";s:0:"";s:5:"titre";s:1:"2";s:9:"soustitre";s:0:"";s:16:"jointure_auteurs";s:1:"3";s:10:"descriptif";s:0:"";s:8:"nom_site";s:1:"4";s:8:"url_site";s:1:"5";s:5:"chapo";s:3:"6";...}

• id_rubrique dans le fragment 1
• titre dans le fragment 2
• pas de surtitre, ni de descriptif
• les liens à des clés étrangères sont références par les noms fictifs jointure_TABLES (jointure_auteurs ou jointure_documents..)

-  la table VERSIONS_FRAGMENTS contient une ligne enregistrée par modification, identifiée par sa clé primaire id_fragment [2], et reprenant les champs d’index objet et id_objet, pointant sur l’objet éditorial de référence.
Deux champs version_min et version_max permettent de balayer l’étendue des révisions traitées : ce sont des clés étrangères rebouclant sur les lignes de la table VERSIONS, pour détailler l’intervalle de versions inchangées pour ce fragment.
Enfin le champ fragment contient le texte (ou la valeur) saisie, éventuellement en mode compressé selon un indicateur compress à 0 ou 1=compressé.

Un exemple d’application

Le premier usage des révisions vous permet, dès activation dans l’espace privé, de voir un pavé supplémentaire en bas d’accueil montrant les dernières modifications réalisées sur le site (pour les seuls objets configurés...). Cela vous permet notamment de suivre l’activité éditoriale de vos administrateurs et rédacteurs (surtout en correction après publication initiale), sans devoir vous créer un squelette spécifique.

Un deuxième usage vous permettra de compléter l’affichage public des articles pour actualiser leur date affichée : normalement l’article affiche sa date de publication par une ligne analogue à
<p class="publication"><time pubdate="pubdate" datetime="[(#DATE|date_iso)]"><i class="icon-calendar"></i> [(#DATE|nom_jour) ][(#DATE|affdate)]</time>[<span class="authors"><span class="sep">, </span><i class="icon-user"></i> <:par_auteur:> (#LESAUTEURS)</span>]</p>

Chaque article embarque d’autres champs de date, en particulier la date de dernière modification #DATE_MODIF, vous pourriez ajouter :

<p class="publication"><time pubdate="pubdate" datetime="[(#DATE_MODIF|date_iso)]">
<i class="icon-update"></i> [(#DATE_MODIF|nom_jour) ][(#DATE_MODIF|affdate)]</time>[<span class="authors"><span class="sep">, </span><i class="icon-user"></i> <:par_auteur:> (#LESAUTEURS)</span>]</p>

Mais, la balise (exactement le modèle : voir dans ./squelettes-dist/modeles/lesauteurs.html) utilisée #LESAUTEURS n’est plus valide car cela ne précise pas le véritable auteur de la dernière modification : voici son contenu d’origine [3] :

<BOUCLE_auteurs(AUTEURS){id_objet}{objet}{par nom}{", "}>
<span class="vcard author"><a class="url fn spip_in" href="#URL_AUTEUR">#NOM</a></span></BOUCLE_auteurs>

Vous pourrez alors le remplacer, par exemple en créant un modèle analogue #MODELE{lastauteur} qui contiendra la noisette suivante (recevant l’ID_article comme paramètre de modèle, ou par défaut l’article contextuel) :

[(#REM) modele retournant le dernier auteur modifiant un article ]
#SET{id_article,#GET{id,#ENV{id_article}}}
<BOUCLE_lastauteur(VERSIONS){objet='article'}{id_objet=#ENV{id_article,0}}{!par date}{0,1}><span class="vcard author"><a class="url fn spip_in" href="#URL_AUTEUR">#INFO_NOM{'auteur',#ID_AUTEUR}</a></span>
</BOUCLE_lastauteur>

Nota Bene : Vous aurez noté la récupération par défaut de la valeur d’id ou d’id_article dans l’environnement en fonction du mode d’appel du modele (dans un champ d’objet comme <lastauteur|id_article?>, voire <lastauteur0> ou #MODELE{lastauteur,id_article} //à vérifier// ; par ailleurs la balise #INFO_{NOM}{'auteur',#ID_AUTEUR} récupère le #NOM de l’auteur en dehors de toute boucle auteur..
Et pour assurer l’insertion explicite du numéro d’article, vous devrez écrire l’appel de ce nouveau modèle dans votre squelette sous la forme suivante :

<p class="publication"><time pubdate="pubdate" datetime="[(#DATE_MODIF|date_iso)]"><i class="icon-update"></i> [(#DATE_MODIF|nom_jour) ][(#DATE_MODIF|affdate)]</time>[<span class="authors"><span class="sep">, </span><i class="icon-user"></i> <:par_auteur:> (#LASTAUTEUR{#ID_ARTICLE})</span>]</p>

Autre exemple (peut être le placer ici après expertisation ?), signaler les révisions côté public

Qui a dit que SPIP n’était pas adapté au travail coopératif ?