Suppose you create pages using Bricks and Gutenberg on your website. Perhaps you are building a website for a client that wants to have pages that are easily editable in Gutenberg, but there are certain pages you want to manage with Bricks. You can’t easily specify which templates apply to your Gutenberg pages, and which apply to your Bricks pages. One problem with this is that any CSS you want to apply to Gutenberg content will also output on every other page on the website. Another problem comes in when you use the Post Content element, and your client decides they should add Gutenberg content onto a Bricks page. Bricks would render both the Bricks page and the Gutenberg page on top of one-another, instead of only Bricks.
Here are some proposed solutions to the problem:
One idea is to have a drop down in the template conditions that allows us to apply apply templates to one of: a) only Bricks content, b) only WordPress (Gutenberg/TinyMCE) content, or c) both Bricks and WordPress content. See below.
Another option is to perhaps have a Gutenberg Page template, a Gutenberg Single Post template, and so on. Basically just all of the generic WordPress post types, but it only applies when Gutenberg is used to render the content. I don’t believe this is any different than having, for example, a WooCommerce Single Product template.
Just my thoughts. Please share yours. I would like to make this an official feature request if we can flesh out the requirements enough.
Thanks GrowPlugins, definitely needed since right now there’s no easy, logical way to have a mix of Bricks pages and “normal” pages. This could be similar approach to how building a theme handles hierarchy.
For /about slug, it first checks for page-about.php to see if there’s something custom, then falls back to page.php.
For Bricks, just check to see if there’s a custom Bricks page built first, and if not fall back to a defined Single template with conditions set to post type = page. That template would be the page.php file from a normal theme folder, applied to any page that doesn’t have something custom (Bricks).
On further thought, perhaps an even better solution is just to add a drop down to template conditions that allows you to decide if the condition applies only to Bricks content, only to Gutenberg, or to both. The dropdown could be below the exclude tickbox.
Sorry, definitely wasn’t implying files, this should be part of the conditional logic. I was just using that as an example of how a normal (non-bricks) theme hierarchy works, working it’s way down a list until it gets to the fallback / catch-all.
Right, but how do you use conditions to only apply templates to pages designed in Gutenberg, and not Bricks Builder? That is the whole point of this thread. Some people create some pages in Gutenberg and some in Bricks. There are different styling equirements for each.
That would require adding an additional plugin, or worse, PHP code. I see this as a lack of compatibility with Gutenberg, which is core WordPress. This is an issue Bricks Builder itself should have a solution for, not something we should have to hack together ourselves in order to make it work.
Consider the topic of this video:
Should we be required to know a specific WordPress core function (has_blocks) in order to get templates to work for Bricks and Gutenberg generated content? In addition, as @digismith mentioned in the other thread, a client might add Gutenberg content to a Bricks Builder page, and even using has_blocks won’t prevent Bricks from spitting the Gutenberg content out at the end of the page, as if it were a whole new page appended to the Bricks page. There’s nothing anyone can do to prevent their clients from doing this as it stands right now, which is unfortunate in my opinion.
I believe the simplest solution would be for Bricks to have a “Rendered By” drop-down in the conditions, so that the template can apply to a) Bricks content only, b) Gutenberg content only, or c) both.
If the solution is as simple as that, using a custom post type for Bricks could be the way Bricks Builder works by default. I am all for hashing out different solutions to the problem, as long as the answer isn’t “do it yourself” (i.e., using another plugin or using custom PHP code to hack things together). Gutenberg is core WordPress, so Bricks, being the mature product that it is, should be expected to work in harmony with it out of the box. That is all I’m trying to suggest.
there are two Discourse forums I read–this one and the meta.discourse.com. There at Discourse, it’s a common practice to always look at the title of the topic and then each reply (yours and others’) check whether is on or off the topic… otherwise Jeff Atwood will send you to the bike-shedding land…
Looking at the title of this topic “We Should Have Gutenberg Template Conditions” then I say you, we should and then mark it as “solved”. Anything else, especially all that emotional ventilation, is bike-shedding.
PS: you are free to change the title to something more productive.
There is nothing wrong with asking for Bricks to be compatible with WordPress core out of the box. I would assume this is the end goal of the project. I have not tried your solution yet, but using another plugin to solve a defficiency in Bricks should not be considered a long-term solution. That should only be a temporary fix. And I am not asking for an immediate solution. The point of this forum and the idea board is to collect ideas of how to improve Bricks. I saw something that could be improved and took it upon myself to point that out.
I’ll chime in here since (I think?) I started the conversation. In the simplest explanation, a Single (type) template with condition set to Page (no exclusions), should serve as a fallback for all non-bricks content.
Load the page, check if it has a page created in Bricks, and if not, use the page template. I can’t think of any scenarios or workflows that setup would negatively impact or add more work/complexity to and at least to me, seems like a logical process.
Of course you can do the same thing with a custom taxonomy where someone can choose a “Basic Page” term to set a condition against. Or we can set up a CPT. But these are pages, like any other page, not CPTs. With that approach we could also add a section template, design a header in it, and add that to every page manually, but that’s what the Header template is for as a part of Bricks. This seems like what a generic template for a “page” should be for rather than having to go through the extra steps, or manually excluding every Bricks page after assigning it to post type page. A simple solution is still excessive if it’s solving a problem that doesn’t need to exist in the first place.