I have multiple containers which work fine, and I want to add alternative versions for each.
In edit mode, when I click on a container tab and select ‘Edit container design’, I get the toolbar and I see ‘Block template’ with a select control but I can’t work out how I add options to this list.
I was hoping that it would have the same approach as with blocks, adding custom template files to a ‘templates’ directory - I have tried this in every option I can think of, but it doesn’t seem to work, unless I am missing something.
I have a container here - eg:
theme/elements/containers/whitefullwidth.php
Can anyone outline where I add a custom/alternative templates?
Create a folder application/blocks/core_container/templates/my_template and copy the view.php from concrete/blocks/core_container into that folder. Edit that copy of view.php as you see fit.
I don’t think you can restrict custom templates to a specific container, but you can probably make this a little more intuitive by having a common prefix to the folder. e.g.
application/blocks/core_container/templates/custom_one
application/blocks/core_container/templates/custom_two
@drbiskit, @jero is right. getBlockTypeCustomTemplates() looks like a flat filesystem scan keyed only by block type handle and current theme, so there’s no per-container filtering hook that I can see. But I think container custom templates actually go against the design intent of the container system. The fact that you can’t scope them per container is evidence of that.
Here’s my reasoning: containers are meant to be first-class structural units. Each one is designer-authored, filesystem-resident, registered in PageContainers, and fixed in structure. The canonical way to make a variant is to make another container — whitefullwidth_default, whitefullwidth_alt_a, whitefullwidth_alt_b, each with its own elements/containers/ template file and its own row in PageContainers. Atomik ships light_stripe.php as one container; a dark variant would be a separate dark_stripe.php, not a custom template on the light one. That’s what the architecture is built for.
So the real issue I see is that the Block Design dialog treats core_container like any other block, including showing the Block Template dropdown — which has no sensible meaning for a container. Areas already get a reduced version of the dialog (no Margin fieldset, no Block Template dropdown, no Block Container Class override — see views/dialogs/area/design.php and the conditionals in elements/custom_style.php). Containers should get the same treatment: a separate design dialog, or at minimum a conditional in the existing one, that omits the Block Template dropdown and other block-specific controls that don’t apply. (Are there others?)
That would stop this confusing “I see a control, but I can’t figure out how to use it” experience you’re running into, and it’d point devs toward the intended one container per variant pattern.
Anyone from the core team want to weigh in on whether that’s a PR worth filing?
Thanks @jans - That all makes sense, and understood - I appreciate the issues you’ve outlined
From a user perspective, it would be an incredibly useful feature - to be able to swap between different versions of a container, while retaining whatever is contained in it. I know it would save a LOAD of time and effort for some of my Admin clients.
I have a marketplace addon Container Magic that installs many containers and can create variants of containers with different styling. What it can’t do is to swap one container for another.
There is a github issue about making containers as easy to swap as page templates, so containers with similar area names can be swapped and blocks are carried across between the matching areas - just like swapping a page template. Any +1 or other up votes on this may help get it some attention.
That Ability to swap containers GitHub issue would need a UI for the swapping. It seems like the Container Design dialog might be a good place for that? So instead of picking a “Block Template”, it would be “Swap Container” and you’d see the other containers in that drop-down.
I’ll write up a full proposal and add it to the GitHub issue. Thanks!
