Content: Blog

Three months ago, we marked CMS_MODERATOR as deprecated, and in our release notes we publicly announced this plan.

However the 2.3 release notes failed to explain exactly what we mean by deprecating CMS_MODERATOR and what the impact of this will be for 2.4. This has caused quite some confusion on the mailing lists, which is why I'm writing this blog post trying to explain why we're doing this and what our plan forward is.

What is the moderator?

To understand what we mean by removing CMS_MODERATOR, you have to understand what CMS_MODERATOR is. The moderator is (was?) our workflow engine to enable large organizations to add complex access control over who can publish changes to what pages. Staff members can have permission to change pages, but they might not have permission to publish them. Rather they would request a publication from a person with publishing rights for their part of a website. To make things even more complicated, those publishing rights can be hierarchical. This means in order to get a page published, it might have to be approved by a whole list of managers.

While there might be a use case for this, it really is an edge case. At Divio, my employer, we build django CMS based websites every day and have built a lot of websites, ranging from small one pagers to huge websites for big companies. However only a single website  we ever built has CMS_MODERATOR enabled, and even that website hardly uses it. Probably the biggest reason for that is that the current moderator is over complicated and doesn't actually achieve what people want most of the time. What they usually want is to be able to make changes to a website, that are not immediately visible to the public. They don't usually care about the approval process.

Why we want to remove the moderator

For myself, the single biggest reason I want to remove the moderator is because it slows us down. A lot. The moderator is not a standalone thing. It's not an isolated part of our system but rather deeply rooted in several parts, most notably our permission system. Which is why internally we refer to it as permmod (permission + moderator). Permmod is a beast. A beast that has been re-written about three times in the past few years with the goal to make it easier to understand for developers. This goal has not been achieved. As shocking as it might sound, none of the current core developers have a sound understanding of the full permmod system. This is why it slows us down, as in every release we have to dig deep into this system trying to figure out whether our changes will break anything. Further, since it's not used by anyone we know, it is really hard for us to get reliable feedback on pre-release version from installations that have permmod enabled. 

Another big reason is the fact that permmod does not actually give the user what they want in most of the cases. Again, from what we learned talking to our own clients and other developers, they want to make changes to a page without it going public immediately. This can be done using permmod, but the system is so user unfriendly right now that it isn't useful for this.

Long story short, permmod has to die to make space for a better system in the future. If we keep permmod in core, all it will achieve is slowing down the development process.

So what happens in 2.4

In 2.4, we plan to introduce simple publishing. This is exactly the feature I described above. Every CMS page will have two versions: A live one that is publicly visible and a draft one that is only available to content managers. Changes are always done to the draft version and to make the publicly available, the admin has to publish them (via a publish button in the toolbar). This feature will most likely be enabled by default, and it might not even be optional. The publish action will require a special permission, so it will still be possible to do a certain level of workflow managemnet. However the CMS will no longer try to send automated emails whenever a moderation or publishing action is required.

This will obviously be a big change in 2.4. It will be one of the flagship features of this release, although it might seem as an anti-feature. But we're convinced that this is the right move, and that the gain of simple publishing far outweights the loss of the hydra that is permmod.

But I really want the moderation workflow!

Reading the mailing list I understand that there's at least a few people who seem to really want this, and we don't think we should try to stand in their way. However, we are strongly opposed to build such a system into the CMS core again. I would much rather provide new APIs and hooks in the CMS so a feature such as permmod can be built outside the CMS core. Because even if someone stands up and builds us a new fantastic workflow engine, the issue is maintaining it.

The last thing we want to do is make changes that make it hard for people to keep up with our new releases, which is why we have struggled on for so long with this feature. So if it's something you absolutely must have, we will do out best help you implement it outside the core CMS. We are anxious not to leave anyone behind.

TL;DR

We'll kill moderator. We'll replace it with something better. If you don't like that, tell us what you need to re-build it outside CMS core.

 

I hope this blog post clears some of the questions that the ambiguous deprecation warning in the 2.3 release raised.

 

blog comments powered by Disqus