A new extension, “Entry Versions” is now available for download. Comments and feedback can be left here but if you discover any issues, please post it on the issue tracker.

Watch a quick screencast why don’t you.

Just had a look at your last version thread… This is really cool! A client asked me about this type of thing as he’d seen it in Wordpress.

A thought, would it be possible to do minor edits as 2.1 2.2 etc, or is that getting silly?

I will be definitely using this!

This is nice! I really like how easy it is, very little complication involved. I bet I’ll use this.

Great work! This extension works with other field types?

Brilliant work, Nick.

This extension works with other field types

Theoretically it should work with any field. When you save an entry this extension stores the entry XML as it appears in a Data Source as well as the Entry object itself. So it’s a true “snapshot” of the entry data, regardless of the field.

The caveat is that it doesn’t correctly version:

  • Uploaded files: if you subsequently change the file, the previous file is still deleted from the server
  • Related entries: such as Mediathek or Subsection Manager. The state of these might be retained (such as which subsection entries are selected), but the subsection entries themselves are not versioned

NIce work, Nick! This will definitely be on my list of favourite extensions.

this looks like a really cool extension. great job, nick! one suggestion for the “show all” link that exposes all the revisions. Instead of listing all of the revisions, maybe have arrows that move the content up and down. If there are a ton of revisions (say over 50), showing all of them may become an issue.

I was just reading the differences between the old and new extension. So if you’re on revision 20, but then you want to revert back to revision 17, do you just copy whatever is in #17 and then create a new version, so then you’d be on version 21?

So if you’re on revision 20, but then you want to revert back to revision 17, do you just copy whatever is in #17 and then create a new version, so then you’d be on version 21?

Correct, although there’s no “copying” involved, just two clicks. You click on Version 17 in the list, which would populate the form with that version, and then click “Save Changes”. When you’re viewing an older version the “Major edit” chekbox is always ticked so when you save it creates a brand new version (i.e. #21). This prevents people sneaking back and making minor edits to previous versions under the radar.

Brilliant work on this Nick. Thank you.

One minor UI suggestion: what do you think of changing the method of saving new versions to two different save buttons at the bottom? Such as “Save Changes” (minor edit) and “Save as New Version” (major edit). This seems a little more intuitive to me.

Although on the other hand this would physically seperate the change log list and the button for making a new version…

it might be nice to have an option to list the revision number in the Section overview page. For example, if I have an Articles section, in that initial list view, the current revision number can be listed per article.

Entry Versions updated to version 0.2 on 30th of August 2010

  • config checkbox now says “Hide version history from publish form” which makes more sense (the default should be “show”, which it now is)
  • you can now choose the “Show column” checkbox to show meta data of the latest version as a column in the entry table

Neither, I like your idea of changing the submit buttons. From a UI perspective it makes sense have these choices at the time of saving the entry. I’ll look into it.

Entry Versions updated to version 0.3 on 30th of August 2010.

The confusingly labeled “Create new version (major edit)” checkbox is no more. It has been replaced with two submit buttons which provide the two choices more explicitly.

just updated the extension, but when I went to my articles section, i get this error message:

DOMDocument::load() [function.DOMDocument-load]: I/O warning : failed to load external entity “/httpdocs/manifest/versions/62/”

pointing to this line in /extensions/entry_versions/lib/class.entryversionsmanager.php:

99: $entry->load(MANIFEST . ‘/versions/’ . $entry_id . ‘/’ . $file);

I checked my manifest folder, and there is no /versions/ folder in there.

Hi Nick,

thanks for this awesome extension.

Just posted a bug: Global modification of submit button.

And I can second wdtan’s error. This is due to missing versions/unversioned entries in combination with the Show column option.

Sorry chaps! Top of my to do list, will try and fix this tomorrow.

Entry Versions updated to version 0.3.1 on 1st of September 2010.

Fixes the above two issues:

  • prevents the JS touching submit buttons when no Entry Versions field is present
  • prevents PHP error in entry table list when of unversioned entries

great, thanks nick. fixed the issue!

Hey, Nick. I’m finally getting around to trying out the Entry Versions extension. I discovered an issue to do with a Symphony install in a subdirectory. The links for selecting the entry versions are wrong because they don’t include the root URL. I was able to fix it by changing line 106 of /extensions/entry_versions/fields/field.entry_versions.php from this:

$href = '/symphony' . $callback['pageroot'] . $callback['context']['page'] . '/' . $entry_id;

to this:

$href = URL . '/symphony' . $callback['pageroot'] . $callback['context']['page'] . '/' . $entry_id;

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details