Edited handles of nested entries are not respecter when resolving templates

[BramMortier]

Description

I have an entry type called cta which is used by my main content builder field. But I want to reuse the entry type in a nested entry for my CKeditor field. These entry types are prefixed with richText[BLOCK_NAME] so i just renamed the existing entry to richTextCta instead of cta. But it doesn't resolve correctly in the templates.

general config partialTemplates setting is configured to "_elements"

Steps to reproduce

Additional info

• Craft version: 5.10.2
• PHP version: 8.2
• Database driver & version:
• Plugins & versions:

[linear-code]

PT-3132

CMS-2132

[i-just]

Hi, thanks for reaching out!

I’m not sure I understand the issue correctly. You have an entry type with a handle of cta. You are using it in your CKEditor field, and there you’ve overwritten the entry type’s handle to richTextCta. You then render that CKEditor field on the front-end using the partial templates (e.g. {{ entry.myCkeField }}), and your expectation is that it should work with a partial template file called richTextCta.twig, but it only works when you use a partial named by the original handle cta.twig?

[brandonkelly]

This ended up being a core Craft bug. Just fixed for the next release.

[mmikkel]

If I understand the change in 778f97e correctly, this means that Craft will now resolve partial templates using entry types' overridden handles (if there is a overridden handle), as opposed to always using the original handle?

If that's the case, in my opinion this is a breaking change.

I've actually been operating under the assumption that the current behavior was intentional. Which means that after this change, I will almost certainly have an entry type partial template somewhere that will no longer render (or possibly even resolve to the wrong partial template).

Aside from that: IMO, entry types always resolving to a single partial template, named after the entry type's original handle, is a pretty straight-forward convention, and I'd probably vote to retain that behavior regardless 🙂 In cases where the developer happens to want different markup rendered for different entry type usages, that can be handled inside that single partial (including conditions on entry.type.handle).

[brandonkelly]

@mmikkel This is fixing a bug that was introduced in 5.7.5. Before that, the overridden handle was prioritized, then the original handle, then entry. That broke in 5.7.5 via #17213. So that commit is just reverting to pre-5.7.5 behavior.

[mmikkel]

@brandonkelly Aha, I stand corrected then. Thanks for the extra info!

[brandonkelly]

Craft 5.10.4 is out with that fix. Thanks again!

[mmikkel]

@brandonkelly I just tried leveraging this behaviour (i.e. where the overridden entry type handle is prioritised when Craft resolves partial templates), but AFAICT that's still not how it works, and Craft will always render the partial template named after the entry type's original handle, if that template exists.

Here's a simple setup I made to reproduce:

• An entry type with the handle original
• A Matrix field matrixField, where the original entry type's handle is overridden to overridden
• Two templates in the partials folder: _partials/entry/original.twig and _partials/entry/overridden.twig.

With the above setup, I'd expect overridden.twig partial template to be rendered when I do entry.matrixField.render(), but Craft renders the original.twig template instead.

If I delete the original.twig template, then the overridden.twig template is rendered, so the overridden handle is taken into account, but Craft still seems to prioritise the original handle.

I wrote some debug code to confirm that the original and overridden entry type handles do contain the expected values:

{% for entry in entry.matrixField.all() %}
    Entry type handle: {{ entry.type.handle }}<br/>
    Original entry type handle: {{ entry.type.original.handle }}<br/>
    Template rendered: {{ entry.render() }}
{% endfor %}

The above renders as

Entry type handle: overridden
Original entry type handle: original
Template rendered: _partials/entry/original

Note: Both partial templates consist of this code:

{{ _self }}

To rule out a regression, I tested this on both 5.10.4 and 5.10.13.2 – same result. Maybe I'm misunderstanding something?

[BramMortier]

@mmikkel My use case was within a CKEditor field rather than a Matrix field, so there's a slight difference. However, I understand your point. I'm also assuming that if I created a cta.twig file in my partials folder (where richTextCta.twig already exists), the cta.twig file would take precedence.

So to confirm: the handle override works only if that specific overridden filename is the only one present in the templates folder?

[mmikkel]

@BramMortier I just tested it with CKEditor and I'm getting the same result as I do with Matrix entries – which makes sense, considering the partial template candidates comes from the Entry class, it's not something that is specific to neither CKEditor or Matrix (or sections, for that matter).

And yeah, if an entry type has its handle overridden from richTextCta to cta, I'd expect the cta.twig partial to always be rendered, if it exists. I though that was the point of this fix. But as far as I can tell, that doesn't happen if there is also a richTextCta.twig partial.

Are you seeing different behavior?