django CMS 5.1: Your CMS, Your Way — Now Easier to Set Up Than Ever

One of the highlights of django CMS 5.1 is the significantly improved djangocms command-line interface. It can create an entire django CMS project for you — or add django CMS to a Django project you already have.

And there's another important change behind that simplicity: you decide what kind of CMS you want to build.

Versioning? Moderation? Reusable content? Stories? Traditional rendering, headless delivery, or both?

The new CLI lets you choose.

Start a complete django CMS project with one command

Want to start something new?

djangocms myproject

The command scaffolds a ready-to-run project, installs its requirements, runs the migrations, creates a superuser and checks the resulting installation. Instead of spending your first hour wiring together settings and dependencies, you can start working with your CMS.

Don't know exactly which options you need yet? Simply run to let the interactive setup walk you through the available choices:

djangocms

Know exactly what you want? Put everything on the command line:

djangocms myproject --mode hybrid --versioning --moderation --alias --stories

That's where django CMS 5.1 gets particularly interesting.

Build the CMS you need

django CMS has a modular architecture. The core provides the foundation, while additional packages add capabilities such as versioning, moderation and reusable content.

With django CMS 5.1, the project setup makes those choices explicit.

Traditional, headless or hybrid?

First, choose how django CMS should deliver your content.

Traditional mode is the familiar django CMS experience: Django and django CMS render and serve your website's HTML pages.

djangocms myproject --mode traditional

Headless mode exposes CMS content through an API instead of publishing the HTML page tree. This is ideal when your frontend is a separate application.

djangocms myproject --mode headless

And hybrid mode gives you both: django CMS can render regular pages while CMS content is also available through an API.

djangocms myproject --mode hybrid

That means you don't have to make your entire platform headless just because one part of it needs an API.

Versioning: drafts, publishing and content history

For most editorial websites, saving a change and publishing a change should be two different things. That's what djangocms-versioning provides.

Versioning is enabled by default and introduces proper content states including Draft, Published, Unpublished and Archived. Editors can work on a new draft while the currently published version remains live. Publishing promotes the draft, while previous content remains part of the version history.

For a simple project where every saved change should immediately become visible, versioning can be omitted:

djangocms myproject --no-versioning

This makes django CMS useful at both ends of the spectrum: from straightforward single-author projects to sites with substantial editorial workflows.

Moderation: add an approval workflow

Need more than drafts and publishing? Add moderation:

djangocms myproject --moderation

djangocms-moderation builds on versioning and introduces moderation workflows before content is published. This is useful when content needs to move through an approval process — for example, from author to editor before it reaches the public website.

Because moderation builds on versioning, it can't be combined with --no-versioning.

For organizations with multiple editors, this turns the same CMS foundation into a much more controlled publishing environment.

Aliases: create once, reuse everywhere

Websites contain a surprising amount of repeated content.

Calls to action. Contact boxes. Product teasers. Disclaimers. Promotional banners. Footer content. Aliases let editors manage reusable CMS content centrally and place it where it's needed.

Change the reusable content once, rather than finding every page where someone copied it six months ago.

Aliases are enabled by default but can be left out when they're not required:

djangocms myproject --no-alias

This is also a great example of django CMS's modular philosophy: reusable content is a capability you can add rather than something that has to be hard-wired into the CMS core.

Stories: add publishing and blog content

Building a publication, company blog or news section? Add Stories:

djangocms myproject --stories

djangocms-stories is the django CMS blog application, supporting multilingual posts, CMS placeholders, social-network metadata and configurable apphooks.

Instead of having to choose a CMS distribution that assumes every website needs a blog, you simply add the capability when your project needs it.

History: Undo and redo

django CMS 5.1 also exposes undo/redo as an installation option:

djangocms myproject --history

This adds djangocms-history to the project.

Like Stories and moderation, history is off by default, so projects that don't need it don't have to install it.

A CMS that starts small and grows with you

Put those options together and the real advantage becomes clear.

A straightforward company website might start with:

djangocms companysite --mode traditional --versioning --alias

A publishing platform could use:

djangocms publication \
    --mode traditional \
    --versioning \
    --moderation \
    --alias \
    --stories \
    --history

And a project with a separate frontend might start with:

djangocms platform \
    --mode headless \
    --versioning \
    --moderation

The point isn't that every django CMS installation should contain every feature. It's exactly the opposite: Choose the capabilities your project needs.

Already have a Django project? Even better.

Starting new projects is only half the story. Many developers interested in django CMS already have a Django application.

Maybe you've built a customer platform and now need marketing pages. Maybe an existing Django application needs a documentation section. Maybe your editors need control over content that developers currently maintain in templates.

With django CMS 5.1, you don't have to rebuild your project around the CMS.

From your existing Django project, run:

djangocms .

The CLI reads your existing project and makes the changes needed to integrate django CMS.

It can update INSTALLED_APPS, middleware and template context processors, add CMS settings and URL patterns, create a basic template directory when needed, install the selected packages, run migrations and validate the installation.

And the same component choices are available.

For example:

djangocms . --mode hybrid --versioning --alias

Or turn an existing Django application into the foundation for a content API:

djangocms . --mode headless --versioning

Your Django project doesn't have to become a CMS project. The CMS can come to your Django project.

That's an important distinction.

django CMS is built to integrate with Django rather than replace it, and the new CLI makes that philosophy much easier to put into practice.

See what django CMS will change before it changes anything

Automatically modifying an established Django project deserves some caution. That's why django CMS 5.1 provides:

djangocms . --dry-run

The command previews the proposed integration without writing files or installing packages. You'll see a unified diff of the configuration changes and a list of the packages that would be installed.

Review it. Understand it. Commit your current project. Then run the real installation when you're ready.

The integration is also designed to be idempotent: existing entries aren't duplicated when the command is run again.

Automation doesn't have to mean giving up control.

From CMS to content platform

This new setup experience highlights something bigger about django CMS' philosophy:

It's not simply a package for rendering editable web pages. The pieces can be combined depending on what you're building:

• Versioning when editors need drafts and controlled publishing.
• Moderation when content needs approval before publication.
• Aliases when content should be created once and reused.
• Stories when the project needs blog or publication content.
• History when you want editing history.
• Traditional mode when Django should render the website.
• Headless mode when another frontend consumes the content.
• Hybrid mode when you need both.

And because django CMS is built around Django, you're still free to build the domain-specific applications that make your project unique.

Your products can remain Django models.

Your customer portal can remain a Django application.

Your business logic remains yours.

django CMS adds the content-management layer around it.

Less setup. More building.

Every configuration step that can be automated is one less opportunity for an error. Every optional component that can be selected during setup is one less integration guide a developer has to work through manually.

And every minute saved getting an installation running is another minute available for building the things that actually differentiate your project.

That's what makes the new djangocms command more than a convenient project generator.

It makes django CMS easier to evaluate.

It makes new projects faster to start.

It makes adding content management to existing Django applications a first-class workflow.

And it makes the modular nature of django CMS visible from the very first command.

Try django CMS 5.1

Starting fresh?

pip install django-cms
djangocms myproject

Want to explore the options interactively?

djangocms

Already have a Django application?

djangocms . --dry-run
djangocms .

Or configure exactly what you need from the start:

djangocms myproject \
    --mode hybrid \
    --versioning \
    --moderation \
    --alias \
    --stories \
    --history

New or existing. Traditional, headless or hybrid. Simple publishing or a complete editorial workflow.

With django CMS 5.1, you choose the pieces — and the new CLI puts them together.

Your project. Your architecture. Your CMS.