[feat] Name placeholder of static alias like the static alias

[fsbraun]

This issue has been raised by Tow Cowan on Slack and @petrklus:

I used static_placeholder to allow site-wide content to be edited, and could control the plugins used in this with the CMS_PLACEHOLDER_CONF setting. I’m now using v4 for a new project - am I able to do something similar with the static_alias tag? I don’t seem to be able to do so with the configuration I’ve tried.
For example, if I have the following in my base.html template (outside of any blocks):

{% static_alias 'banner' %}

And then the following in my settings:

CMS_PLACEHOLDER_CONF = {
	"banner": {
		"plugins": ["BannerPlugin"],
	},
}

When I view the Alias (Django Admin -> Django CMS Alias -> Aliases -> Preview) and then try to add a plugin, it ignores the above placeholder config. If I add a key for a “content” placeholder in CMS_PLACEHOLDER_CONF it does allow me to configure the available plugins, but this would mean that all of my static_alias tags would have the same configuration.

[aacimov]

Also, when using the template system it would be very helpful to have the ability to contextually show different markup regarding the static_alias, as with static_placeholders in v3, e.g:

{% if static_alias_name == 'Static Alias 1' %}
    <div class="static_alias_1_wrap"></div>
{% elif static_alias_name == 'Static Alias 2' %}
    <div class="static_alias_2_wrap"></div>
{% else %}
    <div class="static_alias_default_wrap"></div>
{% endif %}

[aacimov]

Hey @evill33t actually I did exactly the same to achieve the wanted behaviour but dealing with clients is the main cause I asked for the "old fashion" behaviour since they usually expect something to be added and just work OOTB (without selecting the actual template).

Thanks for the heads-up though.

[evill33t]

I deleted my comment, I was wrong about the template - imho it should be able to choose different slots which would solve this issue.

[fsbraun]

There's a basic design problem here:

• All aliases share a template (you can change templates for alias plugins, the render_alias tag within them calls the same common alias template, again.)
• The way django CMS 4 core identifies the templates in a frontend-editable model is static (same template -> same placeholder names - always)

My best assessment is that one could:

• Extend the core's way of identifying placeholder slots in frontend-editable models, and
• Let the placeholder be called like the static_code or "content" if static_code is unset. (This is a breaking change, however, since the placeholder names of existing aliases changes, partly mitigable by a custom migration)

[chschuermann]

With the current solution, all content alias instances are processed internally with the name "content". This means that no placeholder-specific configurations are possible in CMS_PLACEHOLDER_CONF. With the CMS and djangocms-alias drifting apart, I don't see a simple solution right now that I could incorporate via PR.

Nevertheless, we were able to find a solution. Admittedly, it is not very pretty, but it seems to work. Specifically, we have implemented two monkey patches.

First, we dynamize the hardcoded placeholder_slotname in the AliasContent class:

# Dynamize the placeholder slot name
AliasContent.placeholder_slotname = property(lambda self: self.name)

Then we make sure that the hardcoded name in the template “djangocms_alias/alias_content.html” is bypassed. To do this, we patch get_declared_placeholders_for_obj:

from cms.models import EmptyPageContent
from cms.templatetags import cms_js_tags
from cms.utils import placeholder
from djangocms_alias.models import AliasContent

# Save the original function
_get_declared_placeholders_for_obj_original = placeholder.get_declared_placeholders_for_obj

# Patch the placeholder name determination
def monkeypatch_get_declared_placeholders_for_obj(obj: models.Model | EmptyPageContent | None):
    from cms.templatetags.cms_tags import DeclaredPlaceholder

    if isinstance(obj, AliasContent):
        return [DeclaredPlaceholder(slot=obj.placeholder.slot, inherit=False)]
    else:
        return _get_declared_placeholders_for_obj_original(obj=obj)

# Patch both usages (placeholder and cms_js_tags)
placeholder.get_declared_placeholders_for_obj = monkeypatch_get_declared_placeholders_for_obj
cms_js_tags.get_declared_placeholders_for_obj = monkeypatch_get_declared_placeholders_for_obj

Since we are migrating a version 3 project, we also had to migrate data. We solved this using the following management command:

from cms.models import Placeholder
from django.contrib.contenttypes.models import ContentType
from django.core.management import BaseCommand
from djangocms_alias.models import AliasContent


class Command(BaseCommand):
    def handle(self, *args, **options):
        alias_content_type = ContentType.objects.get_for_model(AliasContent)
        placeholders = Placeholder.objects.filter(content_type__pk=alias_content_type.id)
        for placeholder in placeholders:
            placeholder.slot = placeholder.source.name
        Placeholder.objects.bulk_update(placeholders, ["slot"])

[fsbraun]

@chschuermann Interesting! Thanks so much for sharing. I've been keen to look at this!

[wfehr]

Just ran into this as well. I am currently trying out to migrate from 3.11 to 4.1.

Was wondering why some content was looking weird 😅 .. well, I got plugins that do something like

def render(self, context, instance, placeholder):
    # ...
    if placeholder == "something":
        # do different stuff
    # ...

[fsbraun]

@wfehr Yes, I think this is a very reasonable feature we need!

As a workaround, you might want to look at instance.placeholder.source to see what object the plugin is attached to - assuming you want to behave the plugin differently on pages and aliases. source can be of the type AliasContent, PageContent, or any other object that has a PlaceholderRelationField.