Provide more flexibility for element partial templates

[MoritzLost]

In Craft 5, we have moved our templates for matrix blocks (now entry types) to the folder for element partials, in part as preparation for using embedded entries in CKEditor. However, we've noticed that we can only have one folder for all entry types, regardless of what context or in this case, matrix field, they're used in. This can get a bit messy. In our current use-case, we have two matrix fields – one for sections, and another one for content blocks inside those sections. Previously, the templates for those two hierarchy levels were placed in different folders. Now, they are mixed together, and we can't see at a glance which field a template belongs to. This is a user-level distinction, of course, since all entry types are equal from Craft's point of view. But in terms of AX and DX, there are different types/groups of entries, and we would like to be able to have those in different folders.

The only available option right now is the partialTemplatesPath option, but that only allows us to change the base folder, not the folder structure within that folder.

Not sure what the best way to solve this would be, but here are some ideas:

• Introduce a new config option elementPartialTemplatePath (or something like that) that accepts a function as its value. The function would return the path for the twig template. That would allow for custom logic – for example, using different paths based on which matrix fields an entry type is used in.
• Support setting partialTemplatesPath to a single Twig template file instead of a path. In this case, the one specific template would always be used regardless of element and entry type, and we could include the correct template from a custom folder and implement our custom logic in Twig.

[mmikkel]

Like I suggested during the 5.0 beta, I think the best and most obvious solution would be if entry types had a "Partial Template" setting, similar to the "Template" setting available to sections.

[mmikkel]

this would make this feature much more involved than it is right now

Personally, I think there's a very decent argument to be made that having to work within the rigidness of the current implementation is just as "involved" and complicated, just in different ways.

As for the other suggestions in this thread... the one thing I like about the current implementation is that it imposes a convention that is completely unambiguous (if somewhat "magic"). If this system were to be replaced by something to afford developers the same level of control over partial templates as they enjoy in other aspects of templating in Craft, I think the most sensible option would be an equally unambiguous "Partial Template" setting, not a more convoluted system with multiple layers of fallbacks and defaults.

[mmikkel]

A "Partial Template" setting would also increase discoverability for the partial templates feature and the render() function. As is, it wouldn't surprise me if some developers never even discover the feature.

[MoritzLost]

@mmikkel But then every custom element type would need to explicitly add and support this setting. And not all custom element types have a concept of a managing entity like a section or entry type. So a usable fallback should definitely exist.

[mmikkel]

The current implementation requires elements to have a field layout layout provider w/ a handle (i.e. like an entry type, volume, etc). I.e. if the custom element type doesn't have anything like that, it's probably not going to work out of the box with render() regardless 🙂

But yeah, it could make sense to retain the current behaviour as the default/fallback for element types that hasn't explicitly added support for (or explicitly opted out of supporting) partial templates, either via a "Partial Templates" setting (which IMO would be the best solution for the core field layout providers) or some other solution that makes sense for that particular element type.

[mmikkel]

...I also realise that a lot of people probably like the current behaviour, and that introducing something like a "Partial Template" setting in entry types et al. at this point is probably going to be less popular than it might've been if that was how it'd been done from the get-go – especially if the current behavior isn't also retained in some capacity (which I personally feel would make the whole thing start to get a little too complicated). So FWIW I'm not holding my breath that I'm going to have my way on this one 😄

[mattbloomfield]

Agreed. It's too confusing having everything in one place. We have a similar distinction where some are cards that appear within blocks and some are high level blocks.

[brandonkelly]

Worth mentioning here that CKEditor 4.1.0 is out now, which you complete control over how field values/nested entries are rendered on the front end. You can completely bypass entry partial templates, if you want. (craftcms/ckeditor#241)

[MoritzLost]

@brandonkelly Thanks for that, we'll use that approach then. For now, we've moved our templates back into our custom folder structure, since we don't need to follow the partials structure for CKEditor any more. Would still be cool to have more options there, but very good that using partials is optional now.

[leevigraham]

@MoritzLost Created this PR which would allow you to override the rendering: #17189 It could easily be tweaked to check for output and if it's empty continue to template rendering. In a hook you could add your own template paths.