Drafts, versionning, rollbacks ...

[jloosfelt]

I open this issue to know how other users feel about this idea.

I really don't want LocomotiveCMS to become a gasworks, therefore I think that something is missing when an editor modifies a page or a model.

• Drafts would allow users to prepare a page modification and preview it before publishing it.
• Versionning would allow rollback, when I make a mistake and want to put back a page like before I modify it.

It should remain very simple for the user. I'm thinking of the history feature in Google Docs which I think is awesome.
I'm not saying it is a must-have feature, but other CMS have it and it's very useful.

Another reason of this issue is that I really hate when a client calls me and says he needs to rollback and all I can do is restoring a backup... :)

What do you think about it ?

[HashNotAdam]

+1

There are only a few of things that keep LocomotiveCMS delegated to my small clients and this is certainly one of them. The opportunity for completely rethinking how data is modelled is huge but the kind of clients that have the budget for such things are generally also the kind that want drafts, versioning, author page creation, and detailed role management.

[Geeza]

+1, definitely one on my wish list

[alepore]

+1, https://github.com/aq1018/mongoid-history seems interesting (Mongoid 3.x only)

[asecondwill]

+1. Silverstripe does this really well, with user permissions so only admins can publish but authors can edit. Essential for large organizations.

[alepore]

@asecondwill good idea, but keep in mind that Locomotive is clearly not focused on large organizations/editorial target

[Tuckie]

+1, even small/mid-size organizations have separation of duties and a need to preview changes before they are live.

[Iteratix]

+1 for us. The situation in which an user may want to roll back changes to content is very common. I think it's an essential feature to have eventually. Or share draft copy/preview before things are live.

[chadwtaylor]

+1. Even small organizations are requesting those capabilities.

[manuchap]

+1

@alepore bbc wattman orange on locomotive's site frontpage are not really small businesses ;-)

[kkrol89]

I did a POC of versioning feature using mongoid-history, but I encountered performance issue described here:
http://stackoverflow.com/questions/20345261/mongoid-history-performance-issue

My plan was to add "published_version" field to each content entry (or site). When the content entry is displayed on the public website, it's version could be reverted to the last published version.

Unfortunately each revert calls 1 database query to the mongodb collection that keeps history tracks.

[ewilliam]

@kkrol89 can you share with me your POC? particularly the parts that get mongoid-history working w/locomotiveCMS. you can put it on github or gist for dev & discussion, whatever works for you. will appreciate it very much, thanks!

[kkrol89]

@ewilliam please have a look at this repository and README file:
https://github.com/kkrol89/publishable_poc

[ArturGajowy]

+1

When can we expect 3.0? Anytime soon? :)

@kkrol89 did your POC end up in production? :) I mean - you probably had a problem to solve so I'm interested how it all turned out. It's important for me, because I'm investigating Ruby CMS for use in our company and I think that versioning (or at least: ease of implementation of it) is quite impotant

[kkrol89]

No, this solution didn't end up in production. I haven't found solution for N+1 queries problem.