Open jloosfelt opened 12 years ago
HashNotAdam
commented
12 years ago +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
commented
11 years ago +1, definitely one on my wish list
alepore
commented
11 years ago +1, https://github.com/aq1018/mongoid-history seems interesting (Mongoid 3.x only)
asecondwill
commented
11 years ago +1. Silverstripe does this really well, with user permissions so only admins can publish but authors can edit. Essential for large organizations.
alepore
commented
11 years ago @asecondwill good idea, but keep in mind that Locomotive is clearly not focused on large organizations/editorial target
Tuckie
commented
11 years ago +1, even small/mid-size organizations have separation of duties and a need to preview changes before they are live.
Iteratix
commented
10 years ago +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
commented
10 years ago +1. Even small organizations are requesting those capabilities.
manuchap
commented
10 years ago +1
@alepore bbc wattman orange on locomotive's site frontpage are not really small businesses ;-)
kkrol89
commented
10 years ago 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
commented
10 years ago @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
commented
10 years ago @ewilliam please have a look at this repository and README file: https://github.com/kkrol89/publishable_poc
ArturGajowy
commented
9 years ago +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
commented
9 years ago No, this solution didn't end up in production. I haven't found solution for N+1 queries problem.
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.
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 ?