You may find this encouraging. I don’t know if it will make it into 9.5.x, or whether it will wait for v10, but it will hopefully be an improvement. You could post a ‘bump’ message with your thoughts to encourage it along.
opened 05:34PM - 24 Apr 23 UTC
Affects:Content Creators
Affects:Developers
Product Areas:Boards and Summary Templates
Type:New Feature
Enhancement:Level Of Effort:3
Enhancement:Quality of Life:3
### Description
## Board Template Updates
Currently, boards have a mandato… ry Board template. In truth, we don't even always use these templates. For example, in one site our template is simply outputting 6 slots with no markup one right after another. This is silly. We should make these optional, with the only truly required thing in a template being a number of slots.
## Dynamic Slots
But what about that? Hard-coding the number of slots for a Board was a stopgap solution in order to get to a shipping 1.0 product. Boards should be able to have the number of slots defined, but also changeable based on the instance of the board.
## Board Slot Templates
Next up, we have the concept of Board slots. In Atomik, Board slot templates include the following
* Blog Card
* Blog Image Left
* Blog Image Right
* Blog Three Up
* Blog Two Up
In another site here are the ones we're using.
* Two Up White Blue
* Two Up White Orange
* Two Up Blue White
* Two Up Gray White
etc...
These names probably sound familiar - check out the containers defined in that same site:
* Two Up White Blue
* Two Up White Orange
* Two Up Blue White
* Two Up Gray White
etc...
Yes, there are other containers and templates defined here, but the core of the issue remains: there is very little difference between container templates and board slot templates. And when you actually look at the content contained within these it becomes even more egregious. Check out these board slot templates:
* Image Left Stripe
* Image Right Stripe
The contents of these are the same:
<section>
<?php
$slot->display(1);
?>
</section>
These template files exist only due to the rules being used to govern intelligent content placement within boards. Once these are all configured the results ensure that boards look nice – but at the moment such a setup is actively developer-hostile: developers have to create lots of stub templates and route content types between them in order to get things to work nicely. It's no wonder that few have tried.
### The Solution: Board Slot Templates become Containers
It's time to do what we should have done in the beginning but just didn't have enough of a system to pull off: we need to unify board slot templates and containers. Instead of board slot templates being inserted into board slots, containers will be inserted into the slots, and blocks will be placed into those containers. As stated before, we've basically rebuilt Concrete CMS inside boards as a custom system that has none of the benefits and reusability of Concrete blocks outside of Boards. We need to change that.
Beyond explaining the system to developers and some abstract concept of "cleaner code", why else would we do this? Simply put, by unifying these systems we're going to be able to integrate board contents into the larger Concrete ecosystem in some compelling ways. Read on for more information.
There may be some metadata about containers that we need to track in order to make this work, but thankfully we can add this onto containers as a progressive enhancement. In order for a container to be available in a board, it needs to have a container controller. This enables the container to specify how many slots it has, etc... By making this optional we'll enable containers to be backward compatible, while updating the ones available in Atomik and Oxford Shirt to support this new paradigm.
## Content Slots
Once content makes its way into a board's slot, we need to change how it's stored. Currently there's a custom table that joins board instance slots to blocks. These blocks are all instances of the special core_board_slot block type, which joins content objects to various summary templates. It's needlessly complicated. Instead the blocks that these instance slots join to will simply be instances of the core_container block type. Inside these containers will be real Concrete blocks.
## Summary Block in the Core
In order to make this work, we will need to create an instance of the Summary block that we added to EW2 in the core. This should be done anyway - summary templares are a cool feature but without a block that exposes them they're only useful in boards - and if we want to treat board content like first class Concrete content we'll need to port this block over.
### Example
_No response_
Also a forum thread
A little bit disappointed with boards