Skip to main content

django CMS Alias

Latest PyPI version Coverage Django versions django CMS versions

django CMS Alias replicates and extends the alias function of django CMS version 3 for django CMS version 4 and later.

An alias is a collection of plugins that is managed centrally. A reference can be added to any placeholder using the Alias plugin. Since the Alias plugin creates a reference any changes to the alias are immediately reflected at all places it is used.

Aliases are created and edited independently of their usage through their own dedicated editing endpoints, i.e. outside of django CMS pages. This allows content managers to maintain alias content without needing to navigate to a page where the alias is used.

When editing a page that contains static aliases, these aliases are shown in the structure board, providing visibility into the alias’ content while maintaining the separation between alias management and page editing. If the static alias can be changed, it is fully accessible through the structure board.

Static aliases cannot be changed in the structure board on views that have no editing interface.

django CMS Alias supports versioning aliases by django CMS Versioning.

Installation

Requirements

django CMS Alias requires that you have a django CMS 4 (or higher) project already running and set up.

To install

Run:

pip install djangocms-alias

Add djangocms_alias and parler to your project’s INSTALLED_APPS.

Run:

python manage.py migrate djangocms_alias

to perform the application’s database migrations.

Configuration

django CMS Alias provides several Django settings to control its behavior:

STATIC_ALIAS_EDITING_ENABLED

Default: True

Controls whether static aliases can be edited directly on frontend editable objects (such as pages) that include the {% static_alias %} template tag. When set to False, static aliases will not be visible in the structure board and only editable from the alias admin endpoint.

VERSIONING_ALIAS_MODELS_ENABLED

Default: True (if djangocms-versioning is installed)

Enables versioning support for alias models when djangocms-versioning is available. When enabled, aliases support draft/published workflows, version history, and proper content lifecycle management. Set to False to disable versioning for aliases even if djangocms-versioning is installed. Any changes to any alias will then be immediately visible to the world.

MODERATING_ALIAS_MODELS_ENABLED

Default: True (if djangocms-moderation is installed)

Enables moderation workflows for alias models when djangocms-moderation is available. When enabled, aliases can be subject to approval workflows before publication. Set to False to disable moderation for aliases even if djangocms-moderation is installed.

Usage

Static aliases

Static aliases appear in templates and replace static placeholders which were part of django CMS up to version 3.x.

Example:

{% load djangocms_alias_tags %}
...
<footer>
  {% static_alias 'footer' %}
</footer>

New in version 3: Static aliases can now be edited directly on any frontend editable object (such as pages) that includes the {% static_alias %} template tag. Static aliases are marked by a pin icon in the structure board to distinguish them from regular content.

Editing static aliases on the page provides a convenient way to manage alias content in context. However, when using djangocms-versioning, there are important considerations:

Versioning Considerations:

  • Independent Publishing: Static aliases must be published independently from their edit endpoint. Use the edit entry in the alias’s burger menu in the structure board to access the full alias editing interface.

  • Published Content Only: When objects are viewed on the site (not in edit mode), only the latest published alias version is displayed. If no published version exists, nothing will be shown.

  • Draft Creation Required: Published aliases cannot be edited - neither in the structure menu nor on their dedicated endpoint. You must create a new draft version of the alias before editing is possible.

This workflow ensures content consistency and proper version control while providing the flexibility to edit aliases in context when appropriate.

Alias plugin

Alternatively, aliases can be used with the Alias plugin. It allows to select which alias content is shown at the exact position the alias plugin is placed.

Headless API

When djangocms-rest is installed, django CMS Alias adds two endpoints below the prefix you mount djangocms_rest.urls at (/api/ in the examples here). There is no setting to switch on – the integration follows the package.

GET /api/<language>/aliases/

Lists the aliases that have content in that language on the current site.

GET /api/<language>/aliases/<pk or static code>/

Serves one alias’ placeholder content. Static aliases are addressable by their static code, the same identifier used with {% static_alias %}, e.g. /api/en/aliases/footer/.

Both accept ?preview=true to read the draft instead of the published version. That requires the Django view permission on Alias. Published alias content itself is public, as it is already embedded in public pages.

An Alias plugin placed in a page has the referenced alias’ plugin tree expanded inline in that page’s API response, so no second request is needed. An alias that references itself yields empty content rather than recursing.

Templates

For the plugin to work out of the box {% block content %} is expected to exist in your main base.html file. Here is the template hierarchy for the edit and preview endpoints:

base.html
    └── djangocms_alias/base.html {% block content %}
          ├── djangocms_alias/<static_code>/alias_content_preview.html  {% block alias_content %}
          └── djangocms_alias/alias_content_preview.html                {% block alias_content %}

For static aliases, <static_code> is the alias static code (or placeholder slotname when no static code is set). django CMS Alias first tries the slot-specific preview template and falls back to djangocms_alias/alias_content_preview.html.

Use Django’s template override mechanism to customize these templates as needed. Say, if your base template has a different name and the content goes into a block called main_content, you would create a template at templates/djangocms_alias/base.html with the following content:

{% extends "mybase.html" %}
{% load i18n %}

{% block title %}{% translate "Aliases" %}{% endblock %}
{% block main_content %}
    <div class="aliases my-additional-class">
        {% block aliases_content %}
        {% endblock aliases_content %}
    </div>
{% endblock main_content %}

Customizing the alias preview template

When editing or previewing content managed via djangocms-alias (for example, static aliases like headers or footers), django CMS renders the content inside a dedicated template.

This template may extend your project’s base.html template by default. This could cause the full page layout to be displayed while editing a small piece of content and make it difficult to focus on the alias itself.

You can override this default behaviour by supplying your own template at:

templates/djangocms_alias/base.html

For static aliases you can also provide a slot-specific preview template at:

templates/djangocms_alias/<static_code>/alias_content_preview.html

The provided template will then be used when rendering aliases in edit and preview modes. Also, it does not need to extend your main base.html template.

However, be sure that the required CMS tags and assets are included, for example:

{% load cms_tags sekizai_tags %}
<!DOCTYPE html>
<html>
    <head>
        {% render_block "css" %}
    </head>
    <body>
        {% cms_toolbar %}
        {% block content %}{% endblock %}
        {% render_block "js" %}
    </body>
</html>

This helps you keep the editing interface focused on the alias content instead of the surrounding site layout.

A note about versioning

If you enable djangocms-versioning after creating aliases, you need to run the management command manage.py create_versions --userid=<pk> to create Version objects for existing alias content. See the create_versions command documentation for more details.

For more information about djangocms-versioning, see the djangocms-versioning documentation.

Metadata

Release files for djangocms-alias 3.2.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for djangocms-alias 3.2.0
File Size Uploaded Provenance
djangocms_alias-3.2.0.tar.gz 91.3 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for djangocms-alias 3.2.0
File Interpreter ABI Platform
djangocms_alias-3.2.0-py3-none-any.whl Python 3 none any Details

Total release size: 186.1 kB

Release files / djangocms_alias-3.2.0.tar.gz

Download URL djangocms_alias-3.2.0.tar.gz
Size 91.3 kB
Tags Source
SHA-256 checksum
How to use checksums
966dbea32cb8ccc3b0c42bbcef74114c76ebac16d8196c3d2c3681400e604d10
BLAKE2b-256 checksum
How to use checksums
21ad891e23ba4ad3756e27be57708baa465a3c1a6d9c4a7fb2d4d4e51d136153
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 28, 2026.

Transparency log

Release files / djangocms_alias-3.2.0-py3-none-any.whl

Download URL djangocms_alias-3.2.0-py3-none-any.whl
Size 94.8 kB
Tags Python 3
SHA-256 checksum
How to use checksums
f2f9795bd17882ba83643772a2181f256aa05de74c3c12e6bd391790a222b11a
BLAKE2b-256 checksum
How to use checksums
a1ea13deff11778f706cb798afe0bf1393d81b3b687743302a4ed1cce466a734
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 28, 2026.

Transparency log

Security for djangocms-alias 3.2.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for djangocms_alias-3.2.0.tar.gz

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 28, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page