3

Closed

Suggestion for improved content versioning design

description

In the current version of Orchard, when you add or edit a page (or any routable content item for that matter) you can preview the unpublished edited version.

But you can only preview it "stand-alone". Not as part of projections etc. And you cannot preview widget changes, or layer changes, site settings changes, or anything else.

It would be extremely helpful for editors and administrators alike to be able to preview any changes in Orchard, not just individual routable content items. I'm not sure if there are already discussions ongoing in the team about more robust previewing capabilities, maybe even implementation work underway, but in case there's not..

So when thinking about this in the car this morning, an idea sprung to mind. What if the Orchard database schema was extended with a version concept for everything, such that when you make any change, all affected database rows are simply added with a higher version number, alongside the previous rows.

The site would have a notion of the "currently published version" and all DB queries for frontend viewing would include this version nr (unless overridden by a query string parameter) so that only rows for the currently published version are returned from all queries. Conversely, all DB queries from backend editing would include one version number above the currently published version, so that all backend editing is done against the unpublished version.

By DB queries I mean all DB queries that deal with something versioned, regardless of whether it's for site settings, content items, layers, layer rules, widgets. In this way, an editor or admin could make multiple edits and configuration changes to the site, and have them all go into a new version, that's one number higher than the current one.

There would be an admin page where you can do things like:
  • review all the unpublished changes
  • rollback the unpublished changes (drop all rows with a version nr higher than the currently published)
  • publish the unpublished changes (i.e. increase the currently published version number)
  • schedule the unpublished changes for later publishing
  • rollback the site to a previous version (i.e. decrease the currently published version number) in case some mistake is revealed after publishing
  • view the site change history
  • purge old site versions that will no longer be needed
There would also of course be the ability preview any arbitrary version number of the whole site, possibly by appending a query string parameter like so:
https://www.myorchardsite.com?version=3

(The currently published version being nr 2 probably.)

This would really add a level of robust versioning and previewing functionality that goes above and beyond. It would allow editors to make changes much more freely. If they fuck it up, they can just roll back (delete all rows with higher version nr than the currently published). If, after previewing and editing for a while, they ultimately determine the changes look good, they can just publish them.

The thought also occurred to me that maybe this whole thing could even be implemented as a module, if there's an extensibility point that lets you intercept and modify database queries (I'm no Orchard expert so I have no idea if there is).
Closed May 14, 2013 at 7:43 PM by sebastienros

comments

BertrandLeRoy wrote May 2, 2013 at 4:50 PM

Versioning is already implemented.

sebastienros wrote May 2, 2013 at 5:16 PM

I think there is a simpler solution which would just force the Content Manager to use the Latest available version of anything when in Preview mode in the front end.

This could be implemented by the Contents/Preview action only.

sfmskywalker wrote May 2, 2013 at 5:30 PM

That makes sense, and the nice thing about that is that it would not require any changes to the DB schema. Viewing previous site-wide versions as proposed would probably be another story, but I think that was more of an added bonus to having the suggested implementation.

Decorum wrote May 2, 2013 at 5:41 PM

Sebastien: Yes, that is indeed a much simpler solution, and it would solve part of the need I guess. But would it allow for previewing things such as widget changes, layer changes, etc?

I think the big advantage of my proposal is its robustness - it makes versioning applicable to everything. And it makes the actual publishing of made changes more streamlined, where you can review and publish all made changes in one place instead of having to run around to all the edited content items and click publish on all of them.

The value-to-effort ratio would be high, I think.

Bertrand: Not sure what you mean. If you are referring to what's already in 1.6 then yes I am aware, that's why I use the expression "improved versioning". If you are referring to something else that's been implemented since, I'd love to check it out.

sebastienros wrote May 2, 2013 at 6:25 PM

"The value-to-effort ratio would be high, I think"

Well I don't think we live in the same dimension then ;)

CSADNT wrote May 2, 2013 at 6:43 PM

Easier to clone the VM with Orchard .... :)
Using powershell it could be automated.....idea is now to write an orchard clone manager

CSADNT wrote May 2, 2013 at 6:47 PM

or the site

Decorum wrote May 2, 2013 at 7:41 PM

"Well I don't think we live in the same dimension then ;)"

That might be taking it a bit far... :) But yes, as I said I don't really have enough insight into the inner workings of Orchard to know how difficult this would be.

In my mind it seems like a simple enough concept in which you would just need a layer somewhere in the data access stack that adds the current version key to all queries, and the rest of the code could more or less remain unchanged.

Well I wanted to take the time to express the idea, you've made it clear you don't much care for it so 'nuff said I guess.

sebastienros wrote May 2, 2013 at 10:48 PM

Adding a version to every concept of Orchard. Well simply said, IMPOSSIBLE, even if you had a full time job for that. What about all external modules, with custom records ? So the ratio between Effort/Gain tends to +infinity ;)

The simpler solution I gave is easy to implement and might give most of the required value.

Decorum wrote May 2, 2013 at 11:43 PM

Well, it would be opt-in of course. Modules choose whether to have their content participate in the versioning scheme. Modules that don't remain unaffected.

Modules that do would not need to do much except specify for a given database operation whether it constitutes backend content management or not. A new layer in the database stack would add the NEXTVERSION value to those operations, and the CURRENTVERSION value to all others. Modules would simply save and read their records to the database, blissfully unaware of the versioning implementation.

Widgets, layers, content management, navigation and settings would be examples of functionality that are updated to opt in to the versioning scheme.

It's absolutely not IMPOSSIBLE - it's just a case of you not understanding the idea fully yet. ;) Once you do, infinity will seem closer than ever.

Piedone wrote May 3, 2013 at 5:59 PM