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 ?
[1] C’est-à dire que vous n’aurez pas à vous en soucier, mais le code (et en particulier les noisettes utiles) sera à rechercher en cas de besoin dans le dossier sus-cité.
[2] Noter que cet identificateur de clé ne respecte pas absolument les normes des champs SPIP
[3] Il faut préciser que ce modèle désormais standard en SPIP est appelé par l’intermédiaire d’une fonction en php balise_LESAUTEURS_dist()
qui « parachute » pour vous l’insertion contextuelle d’une valeur id_article
..