it’s common to have a basic ‘page template’ built for single pages that don’t need to have much of a unique layout/design. Where’s it’s pretty consistant and is just heading, post content, etc. Privacy pages, Terms and conditions, etc the boring stuff that you wouldn’t want to build manually each time. Just one template.
it seems with Bricks there isn’t a way to have a ‘backup’ template, with a lower priority, that kicks in if the page hasn’t specifically been edited in Bricks.
What I would expect to be able to do…
Create a simple template that applies broadly to all pages.
For any individual new pages that need custom layout, edit the page and ‘edit with Bricks’.
Now on the front end that page should not use the original page template, but instead the new layout specific to that page.
Unless i’ve missed a setting somewhere, it seems we have to currently go into conditions in the page template, and manually exclude every pages that we don’t want it to apply to. Otherwise they all get the same layout. So overtime this list of conditions becomes huge.
Ideally this would happen automatically, but having a ‘template priority’ setting would be a solution, so we can choose what overrides what. ie page template applied UNLESS page has been edited in Bricks.
Also this would more closely follow the typical WP template hierarchy that you get with traditional themes, so i think it’ll be the expectation for a lot of users.
In short, use two post content elements in your page template, one for WP content, the other for Bricks content. It is actually even more flexible than other systems, since you can have BOTH contents displayed (so you can have a Gutenberg content AND a Bricks content and lay them out as you wish if your template needs it!).
There seems to be currently no way to mark elements in the Page Template to NOT be output for Pages built with Bricks. For example, let’s say I have a page header section having the Page title and I want this to appear only for Pages that are built with the WP editor, that is not possible. The page header section will appear also for Pages built with Bricks. Now, that may be the desired behaviour in some cases but not all. Even if there were a condition added later on to detect whether the Page is built with WP or Bricks, it is not a good solution since it has be applied to every element of interest.
It only solves the problem partially - that of having to add Pages designed with Bricks into the exclusion list. If you want to have a Posts page at say, /blog (which has been set as the Posts page at Settings → Reading), it won’t take/use the Template that’s designed separately for that unless that Page is added to the exclusion list in the Page Template.
Yes I agree, it was actually just a proposition to quickly fix WP/Bricks content duality.
Bricks templating system is indeed very limited.
A big issue for me is that I need to insert my page header template in all templates (page, archives, CPTs singles, etc.).
Nested templates like O2 would be awesome (without the bugs!).
May 2022, hum we are in August 2023 does Bricks get’s better on that matter with New versions ? It is so weird that so few people wondering for proper basics on wordpress template hierarchy and template priority.
@Sridhar@wplit while you mention those 2 issues with the mentioned approach from yankiara Does recent Bricks releases fix those issues ?
Thanks
Notes: i’m late in the Bricks wagon coming from Oxygen, still looking for a full and proper Templating video or blog post and it’s broken everywhere in little pieces… Does someone made a proper Templating Crash course like Elijah made for Oxygen, but on bricks builder ? with of course Wordpress Template hierarchy standard in mind and common practice with at least one CPT + Woo Commerce
Also is it doable to design let’s say specific layouts and choose from classic editor or gutenberg the one you want to use to render the page or the post like classic templates ?
Edit and not related to this post but my precedent one :
find that one from @Sridhar :