I tamed the boards! 🤕 Evil laughter

JohntheFish · January 1, 2024, 7:51pm

There was a Friday on it. https://www.youtube.com/watch?v=j-_BeGmQuOo

Also, there could be many changes happening with boards, see

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

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_

github.com/concretecms/concretecms

Add support for new Collection concept, personal boards, bespoke board data pool

opened 06:23PM - 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 Currently, Boards are automatically generated from a dynamic da…ta pool. You specify criteria for how pages or calendar events are added into the data pool, and periodically the pool is refreshed/added to, and boards are regenerated. There is no ability to add a specific page or event into the data pool, in order to generate a board. They are purely for content aggregation, at least until the board is created (at which point you _can_ put specific pieces of content into a specific slot.) ## Collections Let's add the concept of Collections to Concrete CMS (please set aside the fact that Collection is an early name for Page in Concrete CMS, so you may see the method `getcollectionID()` and the variable `Collection` strewn about existing code.) In this concept, Collections are bundles of pages, calendar events or other objects that users find useful. New themes will be created that add functionality for adding these objects into collections, like bookmarks, useful links, etc... This is very similar to BrandCentral, which has its own concept of Collections and allows resources to be grouped into them. Behind the scenes, Collection objects will be tracked against users. Additionally, Boards will be created for these collections, and objects placed into the collections will be placed manually into the Boards data pool. ## Rendering Boards Upon first visit to the view layer of a collection, a board will be generated and rendered for the objects in its data pool. The result? Collections of useful objects will automatically generate attractive, useful boards. These boards are personal to the user who created them, but can be made public and shareable. Boards will have private, non-guessable URLs, similar to Google Docs that are shareable with a link. Users who build these boards from a collection may "re-roll" or "regenerate" the board by clicking a button next to the share, edit and delete button. Adding new objects or updating collections to remove objects will regenerate the board. ### Example _No response_

github.com/concretecms/concretecms

Features/improve boards

concretecms:develop ← marcokuoni:features/improveBoards

opened 01:38PM - 10 Oct 23 UTC

marcokuoni

+87 -115

Small improvements after first production ready use of boards --- Not related… to PR but to Topic @aembler Who is responsible for the concept of this boards. I would like to add my experience to the development docs, but i am not sure i got it right. We did summary templates with categories for * Blog with author image * News with dates * Products with product informations Now all of this are pages and all of them have all of this properties (author, dates, description). But depending on the context (Blog, News, Product) one of the property is more important and cause of them visible in the teaser design. So we did this by creating three custom datasource which all extend the page. But they have an own icon and an extra filter (datasource handler = summary template category). Does this make sense and should we describe this or was there a other idea for this? We did this cause otherwise the pemutation of boards gives you also every Blog Teaser with Designs for News, Products and so on for the others (News, Products). This makes the GUI exploding. Here how we filtered and extended Page: ``` /** * The page object in Concrete encapsulates all the functionality used by a typical page and their contents including blocks, page metadata, page permissions. */ class PagePublication extends Page { /** * {@inheritdoc} * * @see \Concrete\Core\Summary\Template\Category\CategoryMemberInterface::getSummaryCategoryHandle() */ public function getSummaryCategoryHandle(): string { return 'page_publication'; } public function getSummaryTemplates(): array { $app = Application::getFacadeApplication(); $em = $app->make(EntityManagerInterface::class); $filter = $app->make(Filterer::class); $driverCollection = $app->make(\Concrete\Core\Summary\Data\Extractor\Driver\DriverManager::class); $driverCollection = $driverCollection->getDriverCollection($this); if ($driverCollection) { $data = $driverCollection->extractData($this); $templates = $filter->getTemplates($this->getSummaryCategoryHandle(), $data); $items = $em->getRepository(\Concrete\Core\Entity\Page\Summary\PageTemplate::class) ->findByCID($this->getCollectionID()); } $pageTemplates = []; foreach ($items as $item) { $summaryTemplate = $item->getTemplate(); if (in_array($summaryTemplate, $templates)) { $pageTemplates[] = $item; } } return $pageTemplates; } } ```