Inside the Work That Moves django CMS Forward

Copying content, publishing a page, or editing a paragraph should feel straightforward. Behind those interactions sit permissions, data consistency, and integrations that need to keep working as Django and its ecosystem evolve.

Maintain: safer sites, smoother workflows

We addressed ten published CVEs across four packages, strengthening content permissions and protecting against cross-site scripting, denial of service, and cache-handling vulnerabilities. The fixes protect everyday operations such as copying content, accessing moderation comments, and working with drafts.

We also reduced repeated database queries when copying content between languages and removed redundant text-toolbar updates. These changes improve workflows editors already use. Core #8727, text #156.

Enable: help contributions reach users

We submitted 645 reviews on 546 PRs authored by others, covering security, compatibility, publishing, and more. Alongside that review work, we improved accessible icon descriptions, navigation labels, and image descriptions. Contributions become more useful when they are easier to maintain and the results are easier to use. Frontend #397, website #255.

Build: better integration and publishing

We added application REST endpoint registration, giving Django applications a way to expose their capabilities through the CMS API. We also added database enforcement of page URL uniqueness by site and language, and transactional publishing so related changes can roll back together when publication fails. These changes provide clearer integration points and stronger consistency guarantees. REST #115, core #8730, versioning #581.

Modernize: more choice for editors

The move from CKEditor 4 continued with Tiptap as the default editor and CKEditor 5 as an alternative. CKEditor 5 now supports text-enabled CMS plugins, preserving embedded content workflows within the newer editing architecture. Editor update.

We upgraded to Tiptap 3, made the internal page tree the default for the next CMS version, and removed the treebeard runtime dependency. Compatibility fixes and updated plugin test environments help carry these changes forward with Django. This work builds on earlier maintainers and the wider contributor community. Text #149, core #8827, picture #178.

The work in numbers

Across 42 repositories, we submitted 646 PRs, with 595 merged by the September 10 cutoff, performed 977 merges, and closed 246 distinct issues. Merge counts include other authors' contributions; authorship, reviews, and merges overlap and should not be added together as separate delivered changes. The examples above describe merged work; availability depends on package versions.

An estimated classification of 1,292 tracked items puts 54% in Maintain, 5% in Enable, 9% in Build, and 32% in Modernize. Each PR or closed issue counts equally; reviews follow the purpose of the PR. The split describes activity volume and includes open authored PRs, rather than measuring the scale of completed outcomes.

Outlook: build on what works

Better editor integration, application APIs, and more reliable publishing give projects a stronger starting point.

We want to learn how these capabilities work in practice: how migrations preserve existing content, how applications connect to CMS APIs, and where editorial workflows still need improvement. Those experiences can guide better examples, documentation, and integration.

If you have migrated an editor or connected an application, tell us what worked and where you got stuck. Concrete examples help us turn this year's progress into improvements for the next project. Thank you to everyone contributing code, reviews, security reports, and real-world experience to django CMS.

Reach us on Discord.