Gestion versions des textes de contenu.

Bonjour,

J'aimerais améliorer la gestion de mes sites (je n'utilise pas de CMS) en gérant plusieurs versions des contenus.
Actuellement, quand on modifie un texte via mon administration, la modification est immédiatement enregistré (BdD) et donc diffusé immédiatement pour les internautes qui visite le site.

Je souhaiterais proposer plusieurs étapes de validation de mes textes.
Par exemple, une étape brouillon, puis diffusion (pour validation par d'autres), corrigé et enfin publié..Et c'est cette version qui sera affiché sur le site public.

Ce principe est utilisé par certains CMS et je n'ai pas trop envie de réinventer la roue et de commettre des erreurs de conception.

Si vous aviez quelques idées pour aborder cette question...

Merci

Marco

Hello,

Cela me parait simple au demeurant. Là, en éditant ta question, tu as presque répondu. Je ferai comme ceci par exemple :

* altération de la table commentaire en ajoutant un champ de type ENUM ('brouillon','correction','publication')

ALTER TABLE commentaire
ADD COLUMN publication ENUM('brouillon','correction','publication') NOT NULL;

* Dans le formulaire où tu édites ton message, ajouter un élément select
ex :

<select name="mode">
	<option value="brouillon">brouillon</option>
	<option value="correction">correction</option>
	<option value="publication">publication</option>
</select>

* Pour l'affichage des données, je le verrai à peu près comme ceci si je ne m'abuse :

$sql = "SELECT un_champ, un_autre_champ, encore_un_autre_champ, champ_etc ";
$sql .= "FROM commentaire ";
$sql .= "WHERE publication='publication'";

Est ce que la réponse correspond à tes attentes ?

Bonne soirée à toi

ps : code fait de tête
Modifié par Nolem (11 Jul 2009 - 01:28)

merci nolem

effectivement à ca réponds à ma question...
En fait, c'est sur la méthode que je posais des questions.

Ta solution est d'ajouter un champs à ma table et de le tester...
Mais je pensais aussi à utiliser 2 tables identiques, une avec la texte à publier sur le site et une autre avec les versions "de travail"
Je pensais aussi sauvegarder toutes les modifications du texte (cad, au lieu de faire des updates, je fais des insert avec un champs datetime qui m'indique la dernière version).

Les avantages de ces autres solutions et que je garde une trace des versions...ainsi on peut revenir en arriere ou visualiser des versions précédentes...ou alors proposer des versions de travail avec les modifications en rouge ou barrés....ensuite l'auteur peut accepter ou refuser ces modifs...(comme avec Word en mode "modification").

Voila, c'est plutot dans l'approche et la méthode que je m'interroge...je voudrais prendre la bonne direction qui soit suffisament souple pour évoluer

Merci pour ton aide

Marco

Salut,

pifoux a écrit :
Mais je pensais aussi à utiliser 2 tables identiques, une avec la texte à publier sur le site et une autre avec les versions "de travail"
Je pensais aussi sauvegarder toutes les modifications du texte (cad, au lieu de faire des updates, je fais des insert avec un champs datetime qui m'indique la dernière version).

Les avantages de ces autres solutions et que je garde une trace des versions...ainsi on peut revenir en arriere ou visualiser des versions précédentes...ou alors proposer des versions de travail avec les modifications en rouge ou barrés....ensuite l'auteur peut accepter ou refuser ces modifs...

Pas sûr que d'avoir plusieurs versions soit une bonne idée parce que pour chacune il va falloir la corriger, puis la valider, puis se dire "Bon ben en fait je vais réécrire une nouvelle version"... Bref c'est un peu lourd à utiliser (aussi bien pour le rédacteur que pour les correcteurs) d'autant plus qu'il y a à priori peu de chances de revenir à une version précédente...
Sur Alsa on procède comme ça pour un nouveau tutoriel :
* rédaction de l'article par un membre (avec un statut "hors-ligne").
* création d'un sujet dans le forum (côté modérateurs) : "Kess ke vous en pensez ?"
* tant qu'il y a des remarques à faire on continue sur le sujet.
* quand c'est OK pour tout le monde on passe le statut à "en-ligne".

C'est simple, à mon avis efficace, et il suffit d'un champ en plus dans la table.

Salut,

Heyoan a écrit :

...
Pas sûr que d'avoir plusieurs versions soit une bonne idée parce que pour chacune il va falloir la corriger, puis la valider, puis se dire "Bon ben en fait je vais réécrire une nouvelle version"... Bref c'est un peu lourd à utiliser (aussi bien pour le rédacteur que pour les correcteurs) d'autant plus qu'il y a à priori peu de chances de revenir à une version précédente...
...

Je suis du même avis. Également, je pense aussi dans le cas d'une BDD où il y a plus de 456781213.... enregistrements, je crois que les performances vont chuter suite à des enregistrements plus gênant qu'autres choses.

J'entrevois une solution annexe qui peut être sympa et ainsi tu gardes les performances et tes contraintes de développement.

* Lors d'une nouvelle insertion dans la BDD (nouvel enregistrement et formulaire soumis) :
--> création d'un nouveau dossier,
--> création d'un fichier text voir carrément un fichier xml (plus pratique à manipuler me semble t'il, n'est ce pas ?),
--> création de la fiche dans la SGBDR avec le mode précité ("brouillon","correction","publication").
* Au moment où il y a une modification de la fiche (formulaire soumis) :
-->création d'un fichier text ou xml avec la nouvelle version respective du dossier traité en cour
-->update de la fiche dans la SGBDR toujours avec mode susmentionné ("brouillon","correction","publication")

* Dans le cas où tu désires revenir à une version antérieur, il te suffit de récupérer le fichier en question et le charger/update dans ta BDD.

Pour finir, par soucis de place sur le serveur (nombre d'octets alloués), il te suffit de zipper tes dossiers puisqu'au final, ce n'est que du texte. Il est évident que tu peux tout faire dynamiquement via PHP 5.

++
Modifié par Nolem (11 Jul 2009 - 15:31)

Nolem a écrit :
Également, je pense aussi dans le cas d'une BDD où il y a plus de 456781213.... enregistrements, je crois que les performances vont chuter suite à des enregistrements plus gênant qu'autres choses.

A priori non : il suffit d'avoir un bon index. Après bien sûr il faut tenir compte de la contrainte du stockage maxi d'une base m'enfin bon : en général on choisit son hébergement en fonction...

Pour le reste : je n'y vois personnellement aucun intérêt !
D'abord parce que lorsqu'on a accès à une BDD je ne vois pas pourquoi on s'embêterait avec des fichiers (texte ou xml). C'est toujours bien plus simple de faire des requêtes (je suis bien placé pour le savoir car en ce moment au boulot je dois récupérer des f...ing fichiers xml, les parser, effectuer des traitements, puis regénérer des f...ing fichiers xml pour signifier le résultat du traitement. C'est lourd, lent, etc. et tout ça parce que pour des raisons de "sécurité" on n'a pas le droit de faire directement des requêtes SQL dans la base ! )
Du coup, si l'ami pifoux tient vraiment à gérer des versions il suffit de créer une table versions qui contiendra l'identifiant de l'article et une date (de type DATETIME)...

Je viens de rééditer le message précédent suite à ta réponse.

Heyoan a écrit :
A priori non : il suffit d'avoir un bon index. Après bien sûr il faut tenir compte de la contrainte du stockage maxi d'une base m'enfin bon : en général on choisit son hébergement en fonction...

Je pensais qu'avec des multiples enregistrements (4568421387...), les « perfs » pouvaient baissés même avec une unique clef primaire (pas de clef composite).

Heyoan a écrit :

Pour le reste : je n'y vois personnellement aucun intérêt !
D'abord parce que lorsqu'on a accès à une BDD je ne vois pas pourquoi on s'embêterait avec des fichiers (texte ou xml). C'est toujours bien plus simple de faire des requêtes (je suis bien placé pour le savoir car en ce moment au boulot je dois récupérer des f...ing fichiers xml, les parser, effectuer des traitements, puis regénérer des f...ing fichiers xml pour signifier le résultat du traitement. C'est lourd, lent, etc. et tout ça parce que pour des raisons de "sécurité" on n'a pas le droit de faire directement des requêtes SQL dans la base ! )
Du coup, si l'ami pifoux tient vraiment à gérer des versions il suffit de créer une table versions qui contiendra l'identifiant de l'article et une date (de type DATETIME)...

Je me doute que le traitement est un peu lourd. Je pensais plus à un système de sauvegarde. Néanmoins, je n'avais pas du tout pensé à la table annexe. Là je faisais une petites erreur d'appréciation sur les performances encore une fois. Si les jointures sont faites correctement il ne devrait pas y avoir trop de soucis.

++
Modifié par Nolem (11 Jul 2009 - 15:46)

Merci à tous

Vos réponses m'aident bien.

Pas trop pour l'utilisation de fichiers..Trop compliqué.

Je pense que je vais pencher pour l'utilisation de 2 tables...une contiendra les versions non publiés et l'autre la version publiée.

Je pense limité le nombre de versions conservé (10 par exemple) et l'option de supprimer les versions de travail au moment de la publication.

Les 2 tables, je trouve ca rassurant (pas de risques de publier une version non finalisé) et ca ne gène pas pour les performances.


Encore merci pour votre aide.

Marco