feat: Add support for upcoming django CMS 5.1

[fsbraun]

Description

This reflects an internal API change of Django CMS 5. Django CMS 5.1 will remove the compatibility shim.

Related resources

• #...
• #...

Checklist

• I have added or modified the tests when changing logic
• I have followed the conventional commits guidelines to add meaningful information into the changelog
• I have read the contribution guidelines

Summary by Sourcery

Enhancements:

• Adapt placeholder rendering calls to prefer the new renderer API that uses an obj parameter instead of page, with graceful fallback for older versions.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Adjusts alias placeholder rendering to support the updated Django CMS 5.1 renderer API while keeping backward compatibility with the previous signature.

Sequence diagram for alias placeholder rendering with Django CMS 5.1 compatibility

sequenceDiagram
    participant View
    participant render_alias_structure_js
    participant Renderer as BaseRenderer

    View->>render_alias_structure_js: call(context, renderer, obj)
    loop for each placeholder in obj.placeholders
        render_alias_structure_js->>Renderer: render_placeholder(ph, language=lang, obj=obj)
        alt new_renderer_api_supported
            Renderer-->>render_alias_structure_js: rendered_js (obj param accepted)
        else old_renderer_api_only
            Renderer-->>render_alias_structure_js: TypeError
            render_alias_structure_js->>Renderer: render_placeholder(ph, language=lang, page=obj)
            Renderer-->>render_alias_structure_js: rendered_js (page param accepted)
        end
        render_alias_structure_js-->>render_alias_structure_js: append rendered_js to js_parts
    end
    render_alias_structure_js-->>View: "\n".join(js_parts)

Loading

Flow diagram for render_alias_structure_js compatibility logic

flowchart TD
    A[Start render_alias_structure_js] --> B[Initialize js_parts]
    B --> C[Iterate placeholders of obj]
    C --> D{Placeholder exists?}
    D -- No --> C
    D -- Yes --> E[Set ph.is_static = True]
    E --> F["Try render_placeholder(ph, language=lang, obj=obj)"]
    F --> G{TypeError raised?}
    G -- No --> H[Append result to js_parts]
    G -- Yes --> I["Call render_placeholder(ph, language=lang, page=obj)"]
    I --> H
    H --> C
    C -->|All placeholders processed| J[Join js_parts with newline]
    J --> K[Return JS string]
    K --> L[End]

Loading

File-Level Changes

Change	Details	Files
Update alias structure JS rendering to work with both old and new renderer.render_placeholder signatures.	Mark placeholder as static before rendering, as before Attempt to call render_placeholder using the new obj= keyword argument expected by Django CMS 5.1 Fallback to calling render_placeholder with the legacy page= keyword argument when a TypeError is raised Preserve overall output format by still joining all rendered JS parts with newlines	djangocms_alias/rendering.py

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• Catching a bare TypeError around render_placeholder risks masking real TypeErrors from inside the method; consider feature-detecting the signature (e.g. via inspection) or checking the exception message before falling back to the old call.
• To make the compatibility intent clearer, it might be helpful to add a short comment explaining that the try/except block supports both the new obj argument and the legacy page argument in different django CMS versions.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Catching a bare TypeError around render_placeholder risks masking real TypeErrors from inside the method; consider feature-detecting the signature (e.g. via inspection) or checking the exception message before falling back to the old call.
- To make the compatibility intent clearer, it might be helpful to add a short comment explaining that the try/except block supports both the new `obj` argument and the legacy `page` argument in different django CMS versions.

## Individual Comments

### Comment 1
<location> `djangocms_alias/rendering.py:84-86` </location>
<code_context>
             continue
         ph.is_static = True
-        js_parts.append(renderer.render_placeholder(ph, language=lang, page=obj))
+        try:
+            js_parts.append(renderer.render_placeholder(ph, language=lang, obj=obj))
+        except TypeError:
+            js_parts.append(renderer.render_placeholder(ph, language=lang, page=obj))
     return "\n".join(js_parts)
</code_context>

<issue_to_address>
**issue (bug_risk):** Catching a broad TypeError may mask real bugs inside render_placeholder.

`except TypeError:` here will also catch TypeErrors thrown inside `render_placeholder` (e.g. bad args, unexpected None), not only signature mismatches. That can hide real bugs and cause a silent fallback to the `page=` call.

If the goal is to support multiple `render_placeholder` signatures, prefer a narrower check (e.g. feature detection via `inspect`/version flag, or validating the exception message is about an unexpected keyword). This keeps genuine runtime TypeErrors visible instead of swallowing them.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): Catching a broad TypeError may mask real bugs inside render_placeholder.

except TypeError: here will also catch TypeErrors thrown inside render_placeholder (e.g. bad args, unexpected None), not only signature mismatches. That can hide real bugs and cause a silent fallback to the page= call.

If the goal is to support multiple render_placeholder signatures, prefer a narrower check (e.g. feature detection via inspect/version flag, or validating the exception message is about an unexpected keyword). This keeps genuine runtime TypeErrors visible instead of swallowing them.