First: I really like the new versioning module. It does it’s job well, I as a developer completely understand what and how it does it’s thing. But, maybe not our clients. I see two main points where usability could be improved:
-
Instead of “create a new draft”, we could write (as in 3.X) “edit”, and also re-establish the well known link on the page title, on the left side (same functionality). Users dont need to know that a new version is created at that very moment. Further, the form with only readonly fields, when clicking “settings” without a draft, adds more confusion (would also create a draft).
-
Point one could also be part of a bigger initiative, called “simple mode”, that abstracts away most of versioning, so that we have a system more similar to cms 3.X. With the full versioning power available, but only needed to click around in it when really needed. I.e. “edit > publish > (unpublish)”, nothing more, for day to day use (that is still what it is, no?), and recover a forgotten content every year or so, and that will probably be me/you anyway 
One reason to unbundle djangocms-versioning from the django CMS v4 core is that versioining was opinionated already in v3. djangocms-versioning extends the previous capabilities - but still is opinionated.
To me it seems, you need a much simpler versioning which can be implemented for django cms v4. It probably would just add a “switch” to each content model (say, public = True/False). By implementing it in a separate package, it would become available for all models using versioning and not only page contents.
Admittedly, such a simplified versioning package does not exist for now. If you see that as a good use case, it might be worth creating it.
Yes. Probably this would be the way, for having it super simple (even without real versions). What I dont get for now is, how a third party app can add fields to existing content models (i.e. the PageContent model?), and how exactly the versioning tool injects itself into the cms and into other apps (changelist, toolbar, etc.). Is there documentation on how to do this? I only found this: How to crate an admin class for a grouper model - django cms 4.0.0dev11 documentation
I still think that the new versioning could be simplified not in it’s functionality, but in the way the user interface works - it’s basically the same as in 3.X, (draft/live), but adds a history. So why not get existing users (and not confuse them) easily on board with similar workflow? For example, I dont see the need to explicitly create a new draft everytime, that could happen automatically (as before…). But that’s another story
The magic is CMS v4’s new cms config. If you’re planning on creating a “djangcms-publish-state”, “djangocms-minimal-versioning”, or similar, I’d be happy to help get you on speed. I really think the effort is doable:
- Probably you have a
Version object that only has a BooleanField (published)
- Much of the complexity will drop out: You get “Publish” and “Unpublish” buttons, and that’s it.
- You can tailor it to your user’s needs.
I’d support you in this because I think it’ll be a great showcase of the power of V4. I cannot do it myself due to time restrictions, though. Please let me know on slack or here if you’re in.
Regarding “creating a new draft”, the “other story”: I will be putting out a little package (“djangocms-loose-versioning” or similar) that will allow republishing an unpublished version, etc. (I think I sent you the outdated PR.) You lose on being able to audit who did what change - but many do not need this. Bear with me.
1 Like
Thanks! I saw “Loose Versioning”, but that’s not exactly what I meant, my thing really only is in the user interface. Anyway, future looks bright, but I (and everyone else) will have to invest quite some time, to understand the new things!
Another showcase or good example would be a tool like blog/news/polls, as a real world example of a re-usable app, that can be used with versioning (injected via cms_config, maybe in a contrib app?), or without. As it seems to me, third party apps will be forced to use the Grouper/Content concept, when wanting to provide (optional) versioning, when used with the django-cms. Is that true?
And yes, I will ping you when ready, but…time restrictions apply for everyone of us 
Please don’t hesitate to look at djangocms-alias as a reusable app that utilizes versioning. Blog is in its making.
You are right: To register models for versioning, they must follow the grouper content pattern.
Looking forward to “djangocms-minimal-versioning” 
await ping()