Using Boards - How to install boards(templates ) Not on a new Install

carl101lee · November 4, 2025, 2:28pm

OK

I have set-up and used Boards on a couple of new installs and set-ups. And it seems to work ok if you install and set-up a new install with the theme and sample content.

How ever I have a number of Older Sites that I have updated to new Concrete CMS v9.xxx

I have tried a few ways to get the templates and boards to install and work on Live sites - But installing the Theme adn Docs doesnt set-up the boards -

So I have tried to include it onto a new Bedrock Theme Files - But again i put all the Files and XMLs in place on the theme files, but can’t get the Board Templates to install . I like the use of Boards and the layout options customablitly of it just like the containers system.

But I seem to find it hard to get the boards to work on a custom Theme and Can’t re-start blank install all my sites to get this functionality.

Can Anyone Provide a basic templete files, to add to a Bedrock Blank theme that installs and set-ups Boards with the theme install? Or point me in the direction of documnetation to do this.

Or have the atomic theme modified to install boards when its installed and not only when sample data is installed.

Thanks

Carl

carl101lee · November 25, 2025, 1:41pm

Ok … Then it seems this is a no Go..
Seems like a pretty basic feature to be able to use the boards - I guess then they are Useless, and unuseable feature, as I can’t build themes that use them unless you install the sample data at the get go.

I just ended up building my own Page-list templete that does the same layouts as boards and Works without all the Hassel of Updating the Front end everytime.

Carl

JohntheFish · November 25, 2025, 5:54pm

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.

github.com/concretecms/concretecms

Build Board Content out of Blocks and Containers Instead of Custom Slot Objects

opened 05:34PM - 24 Apr 23 UTC

aembler

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