Symphony.

If you’re differentiating between the idea of content history (where you’re keeping track of changes made to the content itself) and entry history (where you’re keeping track of changes made to the entry, such as its publish state), then it wouldn’t, in my opinion, make sense to generate a new line in the content history upon switching the entry’s publish state.

On the other hand, if the idea of a revision is that it encompasses both content and entry history then perhaps you’d want to capture it.

Maybe it doesn’t make much sense programatically, but I kind of like the idea of having the two separate. A list of content revisions, like you’ve got above, and a history of changes that’ve been made to the entry, for example:

• Revision 5 edited and published, 10 August 2009 12:05pm
• Revision 5 created, 9 August 2009 8:15pm
• Revision 4 published, 8 August 2009 11:47am

I think you hit the nail on the head here. My original implementation was limiting entry revisions to content revisions, but in reality they are very much separate.

In your example you have a content edit and an entry edit as a single event in the history. Was this intentional? If the distinction is made between content and entry revisions, then this would never occur — a change to the content would always result in a new version number:

• Revision 7 created 10 August 2009 12:25pm
• Revision 6 created 10 August 2009 12:15pm
• Revision 5 published, 10 August 2009 12:05pm
• Revision 5 created, 9 August 2009 8:15pm
• Revision 4 published, 8 August 2009 11:47am

As tonyarnold was saying, he sees every edit creating a discrete read-only version with its own version reference. Therefore I can only see two states ever being visible in the UI:

• entry created
• entry published

An “entry edited” item in the log would actually be a new version number (“entry created”). Is that expected behaviour? Allen brings up the idea of major/minor edits. Perhaps there should be the option to edit a revision without creating a brand new revision number, thereby allowing for an “edited” item in the logs. This would make sense for fixing typos in content, whereas creating a brand new revision suits major content changes.

I wonder whether users (clients) would care, understand, or be trusted to make the distinction. Is it exposing too much complexity?

• [button] Save this revision (minor edit)
• [button] Save as a new revision (major edit)
• [checkbox] Publish this revision

Back from my traveling and catching up on my reading… really like this extension!

Some thoughts and points of interest after reading everyone’s ideas:

1. I think there should be an option under settings which gives the option to display only “save as new revision button” or default to showing all revision buttons.

2. I like the idea to be able to publish a previous version and not default to the recent revision.

Thanks Mark, useful ideas.

Unfortunately this extension is onto the backburner for now but hopefully it will resurface in the coming months.

Last night I reworked the UI a little. This follows Craig’s thought of splitting out the revision “history” from the revisions themselves. Each action is now logged, as an audit trail. Only when the revision appears in the list for the first time (“created”) is it clickable.

I intend on providing two user levels for publishing/approving, based on the Developer/Author levels already within Symphony.

There will be two buttons:

• Save as Draft
• Save and Publish

The former will always create a new revision. However when clicking Save and Publish a check is made against the data itself. If content has changed, a new revision is created and published. If no data changes, it just publishes this current revision.

This enforces a one-way direction of updates such that edits are always non-destructive of previous revisions. If a user publishes a previous revision, it goes into the history as such. (For example see below, Revision 5 was published recently, but then superseded by revisions 20–24).

Ohhh yeaaahhh,

This is a feature I will definately want to implement! nickdunn - the vision - the creativity - the mind! awesome… look forward to working with it, when you get time to complete it!

moonoo

Nice work, Nick. I’m not totally convinced that “Save as Draft” should always create a new revision. My experience is that I’ll often make minor edits that aren’t worth cluttering up the revision history with. Unfuddle use a checkbox to get around this problem:

What do you think?

Good idea.. I did think when I saw all the changes/revisions that it will very quickly become a long list.. but the idea is there.

Save Changes or Save as Version?

I decided against this after Tony’s comment further up the discussion. Minor or major, you’re still changing content. From an audit trail point of view (which is enterprise CMS language, but is important) you’d want every change logged.

Having a long list of revisions is a challenge for the UI.

Don’t forget that you don’t need to add Revisions to every section in your site. Only use it where you need it, e.g. articles that clients are editing.

I’m thinking perhaps the UI needs two views: a list of revisions, and a history of actions. This for example:

This is the action history list. It documents the chronological history of a version, both revision creation and changes to published status. This is where dates, actions/status and author names matter.

However a simpler view would be:

Less information, but just a list of the content revisions themselves.

Both are equally useful to different people for different purposes. So perhaps the field needs to support the rendering of both views. Unless they can be cunningly displayed simultaneously.

RE: Overwriting versions

I agree that it’s important for the audit trail—that’s just not how I see myself using something like this. More for rolling things back quickly if I break something. I like the idea of overwriting so I can keep the data as clean as possible. Perhaps you could allow only Developers to overwrite?

RE: UI

The cleaner the better. I prefer the second option, but would be nice to have both. Perhaps a JS-tab thing that remembers your last preference?

Additionally, would it possible to filter a DS based on the revision? Am thinking that could be very useful for allowing users to preview the output at the frontend. I guess it gets a bit complicated if you were using multiple versioned sections, but that’s not the most likely scenario.

How about a toggle link to the right of the header: [Collapse | Expand]?

Thanks for the comments chaps, will bear these in mind.

Additionally, would it possible to filter a DS based on the revision?

I hope so, but not sure if it’s possible yet. I’m using a delegate in the backend to swap in the correct entry data just before the page is rendered. I’m not sure whether there are any hooks to do this for frontend Data Sources and Events. Worst-case it might be a fixed custom Data Source that enables this functionality (pass it a section, and entry ID and a revision number).

In my opinion this should be a core feature without the need of using delegates or hackish static data sources. It will be a great extension though :)

I’m with Nils on this - content versioning is pretty key to the “management” part of a content management system. Symphony team - is this something that’s on the roadmap for our favourite WCMS’s future?

Hmmm… fits my criteria for core:

1. Must be independent of any one type of data.
2. Must not break existing functionality.
3. Must make managing content easier.

Nick, brilliant as usual.

Some UI updates. I’ve used Nils’ Mediathek tabs idea as this is a really neat and tidy UI concept:

Shows the latest 5 revisions by default. Can click “More” to expand the list to show all.

The “Full History” tab provides the complete list of activity for the entry. Again, by default it shows the last 5 actions, but can be expanded to show all.

The Revision/History tabs and expanded/contracted states are stored in a cookie so they are remembered between page loads and visits. Different users can therefore save different preferred views.

I think currently the difference between “Revisions” and “Full History” isn’t apparent enough.

It might be good to change “Revisions” into “Content Revisions” or similar (am I right in thinking that “Revisions” means changes to content and full history also includes publishing of revisions?).

Is this extension ready for release yet? I’m kinda excited to test drive it.

Editor experiences etc.. like a ground troop in the trenches of day to day working content editor….

moonoo

I think currently the difference between “Revisions” and “Full History” isn’t apparent enough.

Agreed. Originally I just had “Revisions” and “History”, and toyed with the idea of “Content Revisions”. Yes you are correct, “Revisions” is purely content changes, whereas “History” is everything including creation, publishing, pending moderation requests and so on.

How about “Content Revisions” and “Publish History”?

@moonoo2, I’m rewriting it from scratch after my first attempt a few months ago. It’s still weeks away from anything public, but this thread will document its progress. The extension uses a couple of delegates available only in the next release of Symphony, so I’m unlikely to release this extension properly until the next Symphony release is made anyway.