3.2 release notes

    Warning

    Upgrading from previous versions

    3.2 introduces some changes that require action if you are upgrading from a previous version. Please read Upgrading django CMS 3.1 to 3.2 for a step-by-step guide to the process of upgrading from 3.1 to 3.2.

    • touch-screen support for most editing interfaces, for sizes from small tablets to table-top devices
    • enhanced and polished user interface
    • much-needed improvements to the structure-board
    • enhancements to components such as the pop-up plugin editor, sideframe (now called the overlay) and the toolbar
    • significant speed improvements on loading, HTTP requests and file sizes
    • restarts are no longer required when changing apphook configurations
    • a new content wizard system, adaptable to arbitrary content types

    Changes that require attention

    For general information about touch interface support, see the touch screen device notes in the documentation.

    Important

    These notes about touch interface support apply only to the django CMS admin and editing interfaces. The visitor-facing published site is wholly independent of this, and the responsibility of the site developer. A good site should already work well for its visitors, whatever interface they use!

    Numerous aspects of the CMS and its interface have been updated to work well with touch-screen devices. There are some restrictions and warnings that need to be borne in mind.

    Device support

    Smaller devices such as most phones are too small to be adequately usable. For example, your Apple Watch is sadly unlikely to provide a very good django CMS editing experience.

    Older devices will often lack the performance to support a usefully responsive frontend editing/administration interface.

    There are some device-specific issues still to be resolved. Some of these relate to the CKEditor (the default django CMS text editor). We will continue to work on these and they will be addressed in a future release.

    See Device support for information about devices that have been tested and confirmed to work well, and about known issues affecting touch-screen device support.

    Feedback required

    We’ve tested the CMS interface extensively, but will be very keen to have feedback from other users - device reports, bug reports and general suggestions and opinions are very welcome.

    Bug-fixes

    • An issue in which {% placeholder %} template tags ignored the lang parameter has been fixed.

      However this may affect the behaviour of your templates, as now a previously-ignored parameter will be recognised. If you used the lang parameter in these template tags you may be affected: check the behaviour of your templates after upgrading.

    Content wizards

    For a quick introduction to using a wizard as a content editor, see the user tutorial.

    cms_app.py, cms_toolbar.py and menu.py have been renamed to cms_apps.py, and cms_menus.py for consistency.

    Old names are still supported but deprecated; support will be removed in 3.4.

    Action required

    In your own applications that use these modules, rename cms_app.py to cms_apps.py, cms_toolbar.py to cms_toolbars.py and menu.py to cms_menus.py.

    New ApphookReloadMiddleware

    Until now, changes to apphooks have required a restart of the server in order to take effect. A new optional middleware class, , makes this automatic.

    For developers

    Various improvements have been implemented to make developing with and for django CMS easier. These include:

    • improvements to frontend code, to comply better with
    • changes to directory structure for frontend related components such as JavaScript and SASS.
    • We no longer use ; we now use manage.py for all development tasks. See Contributing a patch for examples.

    Code formatting

    We’ve switched from tabs (in some places) to four spaces everywhere. See Contributing code for more on formatting.

    gulp.js

    We now use gulp.js for linting, compressing and bundling of frontend files.

    We now use LibSass rather than Compass for building static files (this only affects frontend developers of django CMS - contributors to it, not other users or developers). We’ve also adopted .

    .editorconfig file

    We’ve added a .editorconfig (at the root of the project) to provide cues to text editors.

    Automated spelling checks for documentation

    Documentation is now checked for spelling. A make spelling command is available now when working on documentation, and our Travis Continuous Integration server also runs these checks.

    See the section in the documentation.

    The structure board is cleaner and easier to understand. It now displays its elements in a tree, rather than in a series of nested boxes.

    You can optionally enable the old appearance and behaviour with the CMS_TOOLBAR_SIMPLE_STRUCTURE_MODE setting (this option will be removed in 3.3).

    Replaced the sideframe with an overlay

    The API documentation still refers to the sideframe, because it is invoked in the same way, and what has changed is merely the behaviour in the user’s browser.

    In other words, sideframe and the overlay refer to different versions of the same thing.

    New startup page

    A new startup mode makes it easier for users (especially new users) to dive straight into editing when launching a new site. See the for more.

    The sub-pages of a page with an apphook will be unreachable (404 page not found), due to internal URL resolution mechanisms in the CMS. Though it’s unlikely that most users will need sub-pages of this kind (typically, an apphooked page will create its own sub-pages) this issue will be addressed in a forthcoming release.

    Backward-incompatible changes

    See the Frontend code documentation.

    There are no other known backward-incompatible changes.

    Please note any changes that require action above, and take action accordingly.

    A database migration is required (a new model, has been added as part of the apphook reload mechanism):

    Note also that any third-party applications you update may have their own migrations, so as always, before upgrading, please make sure that your current database is consistent and in a healthy state, and make a copy of the database before proceeding further.

    Then run:

    to migrate.

    Otherwise django CMS 3.2 represents a fairly easy upgrade path.

    Pending deprecations

    In django CMS 3.3: