Article versions in Joomla: restoring what someone overwrote

Someone pastes a new text over an article, saves it, and the old version is gone. Or so it seems. Joomla has kept a history of every saved article since version 3.2, and in Joomla 4, 5 and 6 it is switched on by default. You do not need a backup or a database restore to get yesterday's text back. You need the Versions button in the article editor.

Where the versions are

Open the article in the backend. In the toolbar, next to Save and Close, there is a button called Versions. It only appears for an article that has been saved at least once. It opens a list of earlier saves with the date, the author, a character count and an optional note.

Select one row and you get these actions:

• Preview shows that version on its own, field by field.
• Compare needs two selected rows. It shows them side by side and highlights what changed, which is the quickest way to find the save where a paragraph disappeared.
• Restore loads the old version into the edit form.
• Keep On/Off marks a version so it is never cleaned up automatically.
• Delete removes a version from the history.

Restore does not save

This is where people get caught. After Restore, Joomla shows the old text in the form, but the article in the database has not changed yet. Close the editor now and the restore is lost. Check the content, then click Save. That save becomes a new version at the top of the list, so the overwritten text stays in the history as well. Nothing is destroyed by restoring, and you can go back again if you picked the wrong one.

If the article is open in someone else's session, you will first have to release it. The article on checked-out articles and the padlock explains how.

How many versions Joomla keeps

The settings live in Content > Articles > Options, on the Editing Layout tab:

• Enable Versions: Yes by default.
• Maximum Versions: 10 by default. When an article reaches the limit, the oldest version is removed at the next save.

Ten sounds like a lot until an editor saves every few minutes while working. Ten saves in one afternoon push out everything from before that afternoon. On a site with several editors, 30 to 50 is a more realistic number. The cost is database space: each version is a full JSON copy of the article, so a site with a few hundred long articles grows by some megabytes, not gigabytes.

Versions marked with Keep On do not count towards the limit. Use that before a big rewrite: mark the current version as kept, and it survives however many times the new text is saved.

Saving without changing anything does not create a new version. Joomla stores a hash of the content and only updates the date of the existing version when the hash is the same.

Leave a note with the save

The Publishing tab of the article has a field called Version Note. Whatever you type there is stored with that save and shown in the Versions list. "Before price update" or "Text from client, 3 Nov" makes the right version easy to find months later. The field is emptied after each save, so it describes one version only.

When there are no versions

If the Versions list is empty or stops at a certain date, check these in order:

1. Enable Versions is set to No in the Articles options. The categories and other components such as Contacts have the same setting in their own options.
2. The plugin Behaviour - Versionable is disabled. In Joomla 4 and later this plugin does the actual storing. With it switched off, no new versions are written, whatever the component options say. Find it under System > Plugins with the filter set to type "behaviour".
3. The article was created by an import script or an extension that writes straight to the database. History is only stored when an item is saved through Joomla's own table classes.
4. The article was deleted from the trash and created again. Trashing keeps the history, but deleting an article permanently also deletes its versions.

Reading the history in the database

All versions sit in one table, #__history. Each row has an item_id that combines the content type and the id, so for article 42 you can list them with:

SELECT version_id, save_date, editor_user_id, version_note, keep_forever, character_count
FROM #__history
WHERE item_id = 'com_content.article.42'
ORDER BY save_date DESC;

The column version_data holds the full article as JSON, including introtext and fulltext. That is useful when the backend is not available, or when you want to copy one paragraph out of an old version without restoring the whole article. Replace #__ with the table prefix from configuration.php.

What versions do not cover

The history stores the article record: title, text, alias, metadata, publishing fields. It does not store the images the text points to, so if someone deleted a file in the Media Manager, restoring the article brings back a broken image. Menu items and modules have no version history at all.

Versions also tell you what changed, not who was logged in when it happened. The author column shows the user who saved, but for logins, deletions and changes outside articles, use the user actions log. The two together usually answer the question "what happened to this page" in a few minutes.