Symphony.

As alluded to here I am putting together a prototype extension to handle entry versioning. It’s still rough and ready, but the direction it’s headed:

(Apologies for the grainy screenshot snapped from a screencast video)

As the entry is saved the Entry object is serialised to the database and can be retrieved at a later date. When queried in a Data Source, only the “Published” entry is returned. It provides “Draft” and “Published” states but also “Pending” and “Declined” to allow some moderation workflow.

The “Save Changes” button is replaced by self-explanatory “Update version” and “Save as new version” buttons.

Before I go further, I’d like feedback on how you would expect versioning and moderation of entries to work. What workflow makes sense to you?

Things like:

• Do you see yourself requiring an approval process all the time. Might you sometimes just need Draft/Published?
• Should a version be editable after creation, or should an edit always create a new version?

I’ve not really used content versioning inside a CMS before so feedback, ideas and suggestions appreciated.

Sorry, that this is not a helpful entry on how versioning should be, but I just have to say: this looks really, really cool and promising!

in the immediate future, i don’t really see my self needing anything more than draft/published. But i can a case where you may want to put the “last update” time stamp instead of “date created”.

adding moderation as apart of the extension, imo would make symphony more usable for online magazines/blogs that have different users but need an approval before pushing it live.

It seems as if you did have a “save as new”, it would be similar to a version control for articles, which could be helpful if for some reason you have to take content down or want to use a different version of what you published.

I like this idea. A lot. It gives you the ability to edit entry information and roll it back, which is especially handy on articles.

Best cases for versioning:

1. I would want it to create a new version but I’d also like to be able to revert to a pervious version without it “creating a new version” from that reversion, if that makes sense.
2. I’d like the option to approve but be able to change it for certain sections. For instance, an About page I’d want to be able to approve any revisions but if an author wanted to edit their own article I wouldn’t need to approve it. Thus it might be best to give people the option of whether or not a certain entry would need authorization.

The way I would use this is for small changes where I’d want to keep a record. For instance, if I published and article and information changed later I’d want to be able to log the change instead of just re-saving or creating a new entry.

Another example of this is on contact pages. You might want to change information, such as a phone number, but then later go back to it and, for some reason, you can’t find that info anywhere. OK, that’s a bad example as you’re hardly going to lose a phone number but you get my point.

Great input chaps, thanks. The prototype almost does what you’re asking for, except for role-based moderation. But it’s something I can consider.

Keep it coming!

Updated screenshot:

I think a first step of role-based moderation could be to define a role which has the right to publish. This would probably cover 90 percent of people’s needs.

But at the moment, we have no more than 2 roles in the backend – authors and admins. I am afraid that this has never been done for Symphony 2.

I think a first step of role-based moderation could be to define a role which has the right to publish. This would probably cover 90 percent of people’s needs.

Agreed. In the short term since we have only two roles, the only option I can see is to have Developer accounts as the moderators, having the ability to publish draft versions. I may make this an option to the field.

However I may leave out moderation altogether, until there is a time that user permissions are natively supported in the backend.

Most larger CMSes (non open source) retain versions as non-editable documents - they’re for reference only. I would probably prefer the same thing here.

In terms of workflow, I’d leave it out until you can sort out exactly how it should work. Moderation can be a tricky thing, and I guarantee you no two businesses will use this the same way. I think you’ll spin your tires trying to figure this out straight away - ideally it would be completely configurable.

Most larger CMSes (non open source) retain versions as non-editable documents - they’re for reference only. I would probably prefer the same thing here

Do you think it is because of technical complexity, or for audit purposes? Any reason for the personal preference? Myself I like the idea of rolling back to a previous revision.

I’ve got the technicalities of revisions nailed, but it’s the workflow that is crucial. I think you’re right about moderation — every time I approach it I have a different requirement. I may need to leave moderation open-ended for now.

@nickdunn - certainly at my current workplace it’s for audit purposes. The way it’s handled is that you can roll back to the previous content of a saved version, but it creates a new version on top of what’s there. The only other thing I can think of is that until an entry is moved from draft to published, it should not be versioned. Only published entries should be versioned (is that how it works now?).

At the moment the creation of a version is dependent on whether the user chooses to “Update version” (which saves the version they are editing) or “Save new version” which creates a new version entirely.

What you propose makes a lot of sense — versions are purely for auditing. However my original thought was that there may be a scenario whereby you have two versions of an entry Version A and Version B, and may want to regularly switch between them (A/B testing or otherwise). Should each “switch” between draft/published create a new entry in the version history? Or should the published flag just be migrated between the two.

It’s these sort of questions I need to answer, so your input is invaluable.

@nickdunn: switching between versions in the A/B scenario you describe would really stop this from being a useful extension for auditing purposes and push it some way from most users understanding of versioning. What tonyarnold describes is how this sort of functionality is most usually implemented. So each “switch” between draft/published should create a new entry in the version history.

The alternative would be to consider building in support for - and the the tracking of - branching. Stepping back to an early version of a document would branch the audit trail, with updates moving to the ‘live’ branch. This would allow multiple version histories of different branches.

In the situation of A/B testing, it would probably be a good idea to keep a version history in order to tie the results of the tests to the dates of each version.

However, if the switch does not change the content of each version, it would seem unnecessary to create a new entry in the version history. Ideally, there should also be a publish history, so you’re only tracking when the entry is in a published state.

This could have additional benefits of being able to use a crontab or event to switch the publish state, so if you want one version to be published at a certain date and time, for example, a sale starts at midnight, you configure the event to fire at a particular date and time to switch the publish states of the two versions.

Well the switch itself would need to be tracked in order for the system to hold a complete audit trail against the content in question, regardless of changes to the content itself, no?

Would it be possible to combine this with Nils’ Date and Time extension for A/B testing? It could specify a date range for each of the test versions or limited time promotions, etc.

(I don’t want to get too bogged-down in the specific A/B testing example — it was just the first example that came to mind of having two or more versions of the same entry that you may want to periodically swap).)

The alternative would be to consider building in support for - and the the tracking of - branching. Stepping back to an early version of a document would branch the audit trail, with updates moving to the ‘live’ branch. This would allow multiple version histories of different branches.

Not really something I want to get involved with just yet but a fair suggestion nonetheless ;-)

I thought you’d like the challenge Nick :)

Well the switch itself would need to be tracked in order for the system to hold a complete audit trail against the content in question, regardless of changes to the content itself, no?

Like Joe said and physics theories aside – time is linear and mono-directional (moving in the positive direction) so regardless of A/B testing, entries are marked with a unique timestamp so I don’t see a need for branching.

This is how other versioning systems I know work. The only functionality that’s missing with other versioned systems is the ability to check if it’s a major or minor edit. Minor edits aren’t shown on the list, but for auditing purposes any edits will be stored. For the sake of UI simplicity though, not having a minor edit checkbox is fine.

Regarding whether or not to store identical entry data for new versions, each version content are already stored as serialised pieces. So size wise, I don’t see this to be a huge issue. The alternative (although I personally think is unnecessary) is to have “pointer” references to serialised pieces, using checksum or foreign keys to pull out data pieces.

The CMFEdition plugin for Plone makes a distinction between versioning and staging, and it handles only the former. I’m trying to cover both: maintaining versions of entry content, but also maintaining which are drafts and which is published.

So we’ve established that every modification of entry content should result in a new dated version number. Plone and this and this seem to assume that the latest version is always the “published” one.

I want to deviate from this and allow subsequent draft versions to exist. I’m with Plone on this — staging flags (draft/published) should be asynchronous to revisions.

My quandary is: should publishing an entry also create a new version, even if no changes have been made to it? Likewise rolling back from a published version to a previous now-draft version — does this just move the staging flag or does it create a brand new version at the top of the list.

My head hurts.