django CMS application is constantly upgraded by the community with the support of core developers and the technical board. The main goal of these updates is to improve the CMS to make it easier to use and more powerful, while still being as much backward-compatible as possible. Version 3.0, released on the 8th of April 2014, has been an important step to ease the developers work load.
3.1 has been another step forward, and our efforts aimed at make the CMS even more stable and easier to work with, and we strongly believe they payed off.
Let's see the details.
MPTT to Treebeard
Over the years the major complaint in larger django CMS installations where the fragility and sluggishness of working through the page treeand the different side effects (when not plain and simple corruptions) that concurrent editing and quick edits and page tree reorganisation may trigger.
What's the cause of this?
MPTT stands for Modified Preorder Tree Traversal, and is a known algorithm to save a tree (i.e.: a hierarchical structure) in a flat data structure (i.e.: a database): something like trying to fit a square peg in a round hole. Yet, it's a good way to rapresent the data and it's easy to calculate it by using a pen and paper (I've done a few times to check the django CMS tree consistency), but it requires to rebuild the tree for every change operation (adding a node -a page-, moving a branch in a different position etc).
This is fine when you operate in a single-user, syncronous world, but the web has evolved in the hectic, multiple-user highly-asyncronous universe of today, and the mptt limits were a wall django CMS constanlty smashed into. Soon the core team decided for a new approach, and treebeardwas picked, as it has a long story of robustness and a fairly large installed base, including some other django CMSes.
￼- root: "001"
- child "001001"
- child "001002001"
- sibling "002002"
- child "002002001"
This makes every node autonomous from the others: adding or removing a pages requires only changes on the page itself, and moving pages only impact the ones involved in the moving (e.g.: moving page "002002" requires changes to itself and child "002002001"). Other common operations are very fast too: retrieving a branch from the database is easy as a like: SELECT id FROM cms_page WHERE path LIKE '002%'.
Tree structure is also used by plugins, which where the most affected by the mptt issues: triggering concurrent editing issues on plugins were easier (e.g. adding and moving quickly plugins around and not waiting for each operation to complete.
Which impact will this have on your projects? Migrationis entirely handled by django CMS and the migration process is straightforward and nearly automatic: check the upgrade guide
To further improve the flexibility in terms of workflows, we added a special permission to access the Frontend Editor “Structure mode”. This permission allows to setup a workflow which allows only a subset of the project editors to create the page layout, while the other editors can only update the content in the already defined plugins. Migration of existing user is made by migrations, then you can use this feature as required in each project by adding / removing this permission from the users.
django 3.1 version also fixes a few inconsistencies in the user interface, such as the “Draft”/”Live” switch.
It was conceived to afford the current status of the page, but sometimes it confuses the user, so we replaced in with a simpler “Edit” / “Save and close” button which affords the action the user is going to trigger.
Please notice that this release does not support Django 1.4 and 1.5 versions. So if you'd like to employ django CMS 3.1 remember to install a newer Django version. make sure that your third-party applications are also up-to-date with it.