Versie geschiedenis in Joomla

1. De basis

1.1 Wat is Content History?

Het Content History component (com_contenthistory) maakt elke keer dat je een inhoudsitem opslaat een momentopname ervan. Joomla introduceerde dit in versie 3.2 (2013), en sindsdien zit het standaard in core.

Kort samengevat doet het het volgende:

• Elke keer opslaan schrijft een momentopname (een "versie") naar de databasetabel #__history.
• Een momentopname bewaart de volledige gegevens van het item op dat moment, plus wie het opsloeg, wanneer, en een optionele notitie.
• Vanuit het bewerkscherm kun je elke eerdere versie bekijken, vergelijken, herstellen of verwijderen.
• Je kunt een versie markeren met Keep Forever, zodat Joomla deze nooit opschoont.

Zie het als een ingebouwde ongedaan-maken-geschiedenis die uitloggen, server herstarts en zelfs een afgesloten browser overleeft. Het is geen back-up van je hele site, het houdt een item tegelijk bij. En het is precies het juiste gereedschap voor de alledaagse vraag "ik heb de versie van gisteren van dit artikel nodig".

1.2 Wat Content History niet is

Drie korte verduidelijkingen:

• Het is geen site-back-up. Het versiebeheert losse inhoudsitems, geen bestanden, templates of de database als geheel.
• Het is niet hetzelfde als de Action Logs:
  Action Logs leggen vast dat iemand een artikel opsloeg;
  Content History legt vast hoe het artikel eruitzag bij elke keer opslaan.
• Het is niet iets dat je voor core-artikelen zelf hoeft aan te zetten. Joomla's installer schakelt het al in voor Articles, Contacts, News Feeds, Banners, Tags en User Notes. Modules komen met de functie uit, en je eigen extensies moeten er zelf voor kiezen (zie sectie 2).

1.3 Waar vind ik het?

Content History heeft geen eigen menu. Je bereikt het van binnenuit het item dat je bewerkt. Open een willekeurig artikel:

Content → Articles → (open een artikel) → Versions  (knop in de werkbalk)

De knop Versions verschijnt alleen wanneer geschiedenis is ingeschakeld voor die component en er minstens een versie bestaat. Een klik erop opent een popup met elke opgeslagen versie van dat ene artikel. De component zelf staat in administrator/components/com_contenthistory/ en werkt volledig als hulpmiddel voor andere componenten, het toont nooit een eigen lijst met "alle versies overal".

3. Werken met versies

3.1 De Versions-popup

Open een artikel en klik op Versions. De popup toont elke opgeslagen versie, nieuwste eerst, met deze kolommen:

De werkbalk boven de lijst bevat de acties: Restore, Compare, Keep On/Off en Delete.

3.2 Een versie bekijken (Preview)

Klik op de datum van een versie en Joomla opent een alleen-lezen Preview. Het toont de veldwaarden die die versie had, titel, tekst, publicatiedatums enzovoort. Preview verandert niets; het laat je alleen kijken voordat je beslist.

3.3 Twee versies vergelijken

Vink precies twee versies aan en klik op Compare. Joomla toont een diff naast elkaar: velden die verschillen worden gemarkeerd, zodat je in een oogopslag ziet dat de introtekst is veranderd en de publicatiedatum niet. Dit is de snelste manier om de vraag "wat is er nu eigenlijk veranderd tussen maandag en dinsdag?" te beantwoorden.

3.4 Een versie herstellen (Restore)

Vink een versie aan en klik op Restore. Joomla laadt de gegevens van die versie terug in het bewerkformulier. Twee dingen zijn hier belangrijk:

• Restore vult het formulier. Het slaat niet uit zichzelf op. Je moet nog steeds op Save klikken om het terugdraaien definitief te maken.
• Wanneer je de herstelde gegevens opslaat, maakt dat opslaan een nieuwe versie aan. Er gaat niets verloren, de versie waarvan je terugdraaide blijft ook in de lijst staan.

3.5 Een versienotitie toevoegen

Het bewerkformulier heeft een veld Version Note (vaak onder het tabblad Publishing of bij de werkbalk). Typ een kort label als "voor herschrijving" of "goedgekeurd door klant" voordat je opslaat, en die notitie verschijnt in de Versions-lijst. Notities maken van een muur van tijdstempels een leesbare tijdlijn.

5. De versielimiet en Keep Forever

5.1 Hoe het opschonen werkt

Na elke nieuwe versie handhaaft Joomla de history_limit. Als je 10 versies bewaart en een elfde keer opslaat, wordt de oudste versie verwijderd zodat het aantal op 10 blijft. De logica is "bewaar de nieuwste N op opslagdatum, verwijder de rest".

Zet history_limit = 0 en Joomla bewaart elke versie zonder opschonen. Dat is krachtig maar laat de tabel onbeperkt groeien op een drukke site, gebruik het bewust en niet per ongeluk.

5.2 Keep Forever verslaat de limiet

Het opschonen raakt nooit een versie aan die met Keep Forever is gemarkeerd. De opschoonquery slaat expliciet elke rij over waar keep_forever = 1. Zo overleeft een mijlpaalversie, "de tekst die de klant goedkeurde", zelfs nadat honderd latere bewerkingen voorbij de limiet zijn gegaan.

Om het in te stellen vink je een versie in de popup aan en klik je op Keep On/Off. Keep Forever omschakelen verandert niet de auteur of datum van de versie; Joomla behoudt die, zodat de markering puur een beschermingsmarkering is.

5.3 Een limiet kiezen

7. De SHA1-hash: geen dubbele versies

7.1 Waarom twee keer opslaan niet altijd een versie toevoegt

Open een artikel, verander niets, klik op Save. Je zou een nieuwe versie verwachten. Joomla maakt er geen. De reden is de kolom sha1_hash.

Voordat Joomla een versie opslaat, bouwt het een SHA1-vingerafdruk van de momentopname. Als er al een versie met hetzelfde item en dezelfde hash bestaat, en de versienotitie ongewijzigd is, slaat Joomla het wegschrijven over. Geen duplicaat, geen verspilde rij. Dit houdt de geschiedenis schoon en voorkomt dat de limiet zich vult met identieke versies.

7.2 ignoreChanges: velden die niet meetellen

Sommige velden veranderen bij elke keer opslaan, zelfs als de inhoud identiek is, de wijzigingsdatum, de wijzigende gebruiker, de hitteller. Als die meetelden voor de hash, zou elke keer opslaan "anders" lijken en zou de ontdubbeling nooit triggeren.

Dus voor het hashen verwijdert Joomla een lijst met vluchtige velden. De standaardlijst ignoreChanges bevat:

modified         modified_by      modified_user_id   modified_time
checked_out      checked_out_time version            hits            path

Een content-type kan deze lijst overschrijven via de JSON content_history_options in #__content_types. Er is ook een lijst convertToInt (voor velden als publish_up, ordering en featured) die waarden normaliseert, zodat een "0" en een 0 dezelfde hash opleveren. Het praktische resultaat: Joomla detecteert betekenisvolle wijzigingen en negeert cosmetische.

9. Rechten en toegang

9.1 Geschiedenis volgt het item, geen aparte ACL

Content History heeft geen eigen rechtenscherm. Of je een versie mag bekijken, herstellen of verwijderen, wordt bepaald door je rechten op het bovenliggende item. De regel die Joomla toepast is:

Als je het artikel mag bewerken (core.edit), mag je de geschiedenis ervan beheren.

Een editor die een artikel mag bewerken kan dus de Versions-popup openen, bekijken, vergelijken, herstellen en versies verwijderen. Een gebruiker die het artikel niet mag bewerken, kan ook de geschiedenis ervan niet aanraken. Er is geen manier om "de geschiedenis te zien maar het item niet te bewerken".

9.2 Edit-own telt ook mee

De controle is iets ruimer dan een kale core.edit. Als een gebruiker Edit Own-rechten heeft en het artikel er een is dat ze momenteel bewerken, verleent Joomla ook toegang tot de geschiedenis van dat item via de actieve bewerksessie. Auteurs die hun eigen concepten beheren krijgen zo geschiedenis voor hun eigen werk zonder globale bewerkrechten nodig te hebben.

9.3 Een versie verwijderen

Het verwijderen van een enkele versie gebruikt hetzelfde recht als bewerken. Een waarborg: een versie die met Keep Forever is gemarkeerd, kan niet worden verwijderd voordat je de markering eerst uitzet. Dit voorkomt dat een onoplettende klik de ene mijlpaal wist die je wilde beschermen.

11. Content History toevoegen aan je eigen extensie

11.1 Het recept

Als je een component bouwt, kun je Content History bijna gratis krijgen. Drie stappen:

1. Maak je Table versiebeheerbaar. Implementeer VersionableTableInterface en geef je type-alias terug:

use Joomla\CMS\Versioning\VersionableTableInterface;

class ItemTable extends Table implements VersionableTableInterface
{
    public function getTypeAlias()
    {
        return 'com_myext.item';
    }
}

De versionable-behaviour-plugin controleert op precies deze interface bij onTableAfterStore. Met dit op zijn plaats komen je keren opslaan in aanmerking voor versiebeheer.

2. Registreer het content-type. Voeg een rij toe aan #__content_types voor com_myext.item, die naar je tabel wijst en een JSON content_history_options meegeeft als je een eigen ignoreChanges-lijst wilt:

{
  "ignoreChanges": ["modified", "modified_by", "checked_out", "checked_out_time", "hits"],
  "convertToInt":  ["publish_up", "publish_down", "ordering"]
}

3. Voeg de twee opties toe. Zet de velden save_history en history_limit in de config.xml van je component, precies zoals core doet. Voeg het veld Version Note en de Versions-werkbalkknop toe aan je bewerkview. Let op: core levert deze velden met default="0" maar zet de functie aan via zijn install-SQL (de geseede #__extensions-params bevatten "save_history":"1"). Je eigen component erft de default="0" tenzij je op dezelfde manier een waarde seedt, dus geschiedenis staat uit tot een beheerder Save History = Yes zet.

11.2 Wat je krijgt

Zodra die drie stukken op hun plaats staan, hergebruikt je component de volledige core-motor: momentopnames, SHA1-ontdubbeling, de limiet, Keep Forever, preview, compare, restore, de ACL-regel en het REST-endpoint. Je schrijft geen eigen versiebeheercode, je verklaart alleen dat je item versiebeheerbaar is en laat de behaviour-plugin het werk doen.

11.3 Een opmerking over de toekomst

De huidige versiebeheerklassen (Versioning, de table-event-handlers van de behaviour-plugin) zijn in Joomla 6 als deprecated gemarkeerd, met een nieuw versiebeheerconcept gepland voor een latere hoofdversie. De functie en de databasetabel verdwijnen niet; de interne API die ontwikkelaars aanroepen kan veranderen. Als je vandaag geschiedenis in een eigen extensie inbouwt, houd dan de migratienotities voor Joomla 8 in de gaten.

13. SEO, metadata en de frontend

Een veelgestelde vraag: beinvloedt Content History de SEO of wat bezoekers zien? Het korte antwoord is nee, en dat is met opzet.

• Versies zijn alleen backend. Ze worden nooit op de frontend weergegeven. Er is geen openbare "versiegeschiedenis"-pagina en geen dubbele URL's, dus er is niets voor zoekmachines om te indexeren.
• Een versie herstellen verandert het live artikel pas nadat je opslaat. Op dat punt gelden de normale SEO-regels voor de herstelde inhoud, de metadata, alias en tekst die de versie had komen allemaal samen terug.
• Omdat een momentopname metadatavelden bevat, is Content History ook een stil vangnet voor SEO: als iemand een zorgvuldig geschreven meta-omschrijving wist, kun je die herstellen zonder opnieuw te typen.

Met andere woorden, Content History is een redactiegereedschap, geen publicatiefunctie. Het beschermt je werk zonder een enkele byte toe te voegen aan de pagina's die je bezoekers laden.

13.1 Ken de grenzen

Het helpt ook om duidelijk te zijn over wat Content History niet is. Mensen verwachten soms dat het zich als Git gedraagt, en dat doet het niet:

• Er is geen branching en geen merging. Geschiedenis is een rechte lijn van keren opslaan per item; je kunt geen twee parallelle concepten bijhouden en samenvoegen.
• De vergelijking is een eenvoudige veld-voor-veld-weergave, geen volledige broncode-achtige diff met inline woordwijzigingen.
• Het versiebeheert een inhoudsitem tegelijk. Het is geen vervanging voor een echte site- of database-back-up.

Zie het als redactioneel versiebeheer: een betrouwbare ongedaan-maken-en-herstellen-geschiedenis voor de inhoud die je in Joomla bewerkt, geen versiebeheersysteem op ontwikkelaarsniveau.

15. Best practices

Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:

• Zet Save History minstens aan voor com_content, het is de goedkoopste verzekering die je ooit zult kopen.
• Stel een echte limiet in (10 tot 20 is een goed begin). Vermijd 0, tenzij je ook opschoont en Keep Forever gebruikt.
• Gebruik Version Notes. "Voor herschrijving door klant" verslaat elke keer een kale tijdstempel.
• Markeer mijlpaalversies met Keep Forever zodat de limiet ze nooit opeet.
• Onthoud dat restore een actie in twee stappen is: het laadt het formulier, jij klikt nog op Save.
• Toegang tot geschiedenis volgt de bewerkrechten van het item, er is geen apart recht om in te stellen.
• Combineer Content History met Action Logs en Check-in voor een compleet "wat is er gebeurd"-beeld.

17. Samenvatting

Content History is een van Joomla's stilste, meest bruikbare functies. Zet een optie aan en elke keer dat je je inhoud opslaat wordt een herstelbaar punt in de tijd, opgeslagen als een volledige momentopname die je kunt bekijken, vergelijken, herstellen en beschermen.

Het ontwerp is helder en voorspelbaar:

• Een behaviour-plugin bewaakt elke keer opslaan en schrijft een momentopname naar #__history.
• Een SHA1-hash houdt duplicaten buiten, zodat de geschiedenis betekenisvol blijft.
• Een limiet per component schoont de oudste versies op, terwijl Keep Forever de versies beschermt die ertoe doen.
• Toegang volgt het bewerkrecht van het item, dus er is niets extra's om in te stellen.
• Een alleen-lezen REST-endpoint stelt dezelfde gegevens beschikbaar aan externe tools.

Het is geen back-up en het werkt niet met terugwerkende kracht, dus zet het vroeg aan en stel een limiet in waar je mee kunt leven. Als je een Joomla-site beheert waar inhoud belangrijk is, en op de meeste sites is dat de hele bedoeling, dan betekent Content History vandaag aanzetten dat de volgende keer dat een artikel misgaat, de oplossing op een klik afstand is in plaats van een lange avond opnieuw typen. Als je niet zeker weet hoe je site is geconfigureerd, of je versiebeheer in een eigen component wilt laten inbouwen, loont het om er iemand naar te laten kijken voordat je het nodig hebt.