[CMS] Opzet van versiebeheer van pagina's/sites/...

[gvanh]

Bij deze maar weer eens een topic over CMS-en.

Ik ben al een tijdje aan het nadenken over hoe ik het beste een vorm van versie-beheer in m'n CMS zou kunnen implementeren. En die vraag is dan wat mij betreft heel breed. Ik denk bijvoorbeeld aan de volgende functionaliteiten:

- Nadat een pagina is toegevoegd aan het CMS door een gebruiker met beperkte rechten, dient deze geaccordeerd te worden door de 'Superbeheerder', alvorens deze daadwerkelijk gepubliceerd kan worden.

- Wanneer een pagina wordt aangepast, wordt bijgehouden wanneer dit is gebeurd en het is daarbij mogelijk om terug te gaan naar vorige versies van dezelfde pagina.

- Per pagina(versie) kan worden aangegeven, wanneer deze op de site gepubliceerd moet worden. Zo kan al vantevoren op komende wijzigingen binnen een organisatie worden ingespeeld.

Nu vraag ik mij eigenlijk af, hoe je dit soort functionaliteiten kan implementeren. En dat dan enerzijds aan database/code kant:

- Maak je voor elke versie van een pagina een nieuwe database-entry, of sla je alleen de verschillen op?
- Is er een toplevel-pagina entity, met daaraan verschillende versies van child-entities, of is er één pagina entity, waarvan je er voor de verschillende versies steeds één aanmaakt?

En anderzijds aan de User Interface kant (wellicht iets voor een aparte topic op WS?):
- Wordt er - elke keer als een gebruiker een pagina opslaat - een nieuwe versie van de pagina opgeslagen, of kiest de gebruiker zelf, wanneer een pagina een nieuwe versie is.
- Hoe presenteer je de verschillende versies van één pagina?
(Geef je in eerste instantie al een rij met alle pagina's en pagina-versies, waaruit een bepaalde pagina(versie) kan worden gekozen, of geef je alleen een lijst met pagina's, en een mogelijkheid terug te gaan naar oude versies van de pagina, op het moment dat je de pagina aan het bewerken bent.)

Een uitgebreid topic ... ik hoop dat er hier wat ideeën of wellicht voorbeelden over zijn.

Alvast dank voor de reactie!

[ripexx]

Je zou ook kunnen kijken hoe CVS het oplost. Ik weet niet precies heo ze het bijhouden maar er zal wel een truckje voor zijn. Darnaast kan je je datatbase iets anders inrichten. Door een soort archief nummer te gebruiken maar of dat echt zo handig is weet ik niet.

Volgens mij was men in React ook ziets van plan of zat het er al in maar je zal zeker moeten oppassen voor preformance. Je wil niet iederekeer alle aanpassingen on the fly laten door voeren ofzo.

Een ander opzet die wellicht kan werken is een aparte text tabel met hierin alle teksten. Die link je dan aan een item en dan pak je lde laatste goed gekeurde edit of iets in die richting. Met een beetje handige opzet kan het snel zijn en je kan dan ook eenvoudig lijsten genereren met de aanpassingen.

[MisterData]

Ik ben dit probleem zelf ook tegengekomen bij mijn CMS en hoewel het nog niet echt is opgelost heb ik al wel bedacht dat het een stuk efficienter kan door de GNU-tools diff en patch te gebruiken. Bij het opslaan van een nieuwe versie sla je dan in je archief alleen het verschil op tussen de nieuwe pagina en de oude pagina. Wil je dan terug, dan 'patch' je de huidige pagina met de diff die je hebt opgeslagen in je archief Dat scheelt een hoop opslagruimte in je database als je van een grote pagina maar 1 lettertje hoeft aan te passen

Het probleem waar ik tegenaan liep overigens was dat het vrij moeilijk is om diff en patch te integreren met PHP, zeker als je op meerdere platforms bezig bent (Windows, Linux...). Ik weet niet of er een goede diff-implementatie is die wel lief samenwerkt met PHP, maar als iemand weet of het bestaat dan hoor ik het graag

[ Voor 25% gewijzigd door MisterData op 10-09-2004 10:19 ]

[Verwijderd]

Of je alleen de wijzigingen of het volledige nieuwe document aanpast hangt een beetje af van hoe je CMS werkt:

Als je pagina's opslaat in een cache, dan zou ik alleen de wijzigingen bewaren. Dan kunnen die uitgevoerd worden als de cache vernieuwd wordt.

Maar als je de pagina's niet cachet, en je slaat enkel de wijzigingen op, moet je telkens weer -- elke keer hij bekeken wordt -- die pagina gaan patchen met alle verschillen die er gemaakt zijn (en dat kunnen er na verloop van tijd best wel veel zijn).

[Verwijderd]

Je maakt een table instances aan en een table versions en een table versioncontent:

table instance:
id: identity
label: varchar(50)
version: int (= version.version welke versie is gepubliceerd)

table version:
id: identity
instance: int (= instance.id PK)
datetime: datetime
version: int

table versioncontent:
id: identity
versionid: int (= version.id PK)
data: text
etc.. evt uitbreiden met attributes of properties of columns per datatype


Bij het editten van een instance pak je nu de laatste version adhv de datetime, en bij het tonen pak je de version adhv de version nummering.

Zo simpel is het

[BtM909]

Verwijderd schreef op 10 september 2004 @ 10:22:
bij het tonen pak je de version adhv de version nummering.

Zo simpel is het

Waarbij je dus voor elke wijziging een entry hebt. Concreet zoals hierboven gesteld, 1 letter wijzigen op een grote pagina is 2x dezelfde lap tekst (voor 99,99%) opslaan?

[Verwijderd]

BtM909 schreef op 10 september 2004 @ 10:26:
[...]

Waarbij je dus voor elke wijziging een entry hebt. Concreet zoals hierboven gesteld, 1 letter wijzigen op een grote pagina is 2x dezelfde lap tekst (voor 99,99%) opslaan?

Ja, .. waarom niet? Het betekend namelijk oa dat je
- de mogelijkheid hebt om in versies te zoeken
- niet bij elke request voor een versie je hele content moet gaan opbouwen adhv een hele version history, versie 1 was zus toegevoegd, versie 2 zus weggehaald.

Ik zie de nadelen van losse stukken versiebeheer zich al snel op stapelen. Als je er iets mee wilt doen moet je de hele version history erop naslaan om alle wijzigingen mee te nemen in het eindresultaat.

[Infinitive]

Kan je niet gewoon een koppeling maken met CVS voor dit? Dus de "content-logic" sla je op in de database, maar de fysieke content stop je in een CVS repository. Bijvoorbeeld Subversion.

Je moet dan wel met een aantal dingen rekening houden:
- de objecten in een CVS systeem zijn hierarchies (tja, filesystem). Jouw content moet dan ook op die manier in te delen zijn, maar daar valt meestel wel iets op te verzinnen (/triviaal).
- een CVS systeem kan conflicterende wijzigingen constateren in content door verschillende users. Hoe ga je daar mee om?
- als je naast de objecten nog meta informatie opslaat in de database, hoe zorg je ervoor dat alles netjes in sync blijft? Ofwel, je zult eerst je database moeten bijwerken, dan je CVS repository. Maar als dat laatste niet lukt, dan wil je wel je database changes ongedaan maken (transacties dus). Alleen jammer dat CVS geen transacties ondersteund, dus helemaal goed maken lukt je niet.

[ Voor 65% gewijzigd door Infinitive op 10-09-2004 10:38 ]

[gvanh]

Even hele stomme vraag ... wat bedoel je met de afkorting 'adhv'

-- als die hiervoor?
-- achter de harige vagina?
-- ???

[Verwijderd]

gvanh schreef op 10 september 2004 @ 10:33:
Even hele stomme vraag ... wat bedoel je met de afkorting 'adhv'

-- als die hiervoor?
-- achter de harige vagina?
-- ???

Doe je icoon is na

[Dries Arnolds]

creatieve antwoorden gvanh, maar nee

aan de hand van

[gvanh]

@Gordijnstok:
En hoe presenteer jij dan de verschillende versies aan de gebruikers van je CMS? Waarschijnlijk komen we dan ook een beetje in de hoek van de Workflow-management...

Modbreak:

We hebben een edit-knop Zou je voortaan dan ook niet meer meerdere keren achter elkaar willen posten? Na 24 uur mag je evt. je topic kicken om opnieuw onder de aandacht te brengen

[ Voor 38% gewijzigd door gorgi_19 op 10-09-2004 13:29 ]