Hi, Elementor has more Template options than Bricks. It has a SIngle Page, Single Post, Page and plain old Single. So I think we are trying to force all those functions into a single Bricks Template and its not working.
It would depend on the type of sites you build and way of working if this is a big or small problem.
For instance I generally build listing sites using CPT’s. As such I have very few pages - so easy to hand style alike. Most of the design is handled by Single Post templates which gives a single place to control the design. So for me having a common Page design isn’t that important. Obviously others mileage will vary.
Cheers
Alan
Some terminology:
- Bricks data: Anything created in Bricks builder (Edit with Bricks) and attached to a post. For example, you can create a regular WordPress post in Bricks builder, and everything you create is Bricks data.
- WordPress data: Anything created in Gutenberg / Classic editor (
post_content) and attached to a post.
Note how a post/page can have both WordPress data and Bricks data.
There is no element currently that renders Bricks data. So Bricks data cannot be rendered in a template. If a template applies to a post/page, Bricks data will be overriden.
So if I wanted say all my pages to show the page title inside a container with a background colour and a specific height, and then the actual unique page content beneath that, I can’t currently do that?
I’m afraid not, or at least not yet. We will add an “Inner Content” element which renders Bricks data if people ask for it. It currently has around 70 upvotes on the idea board. However, you can create a global element and insert it on every page.
Are you saying that the Single template should not be used to control the display of Bricks posts? Which is how I use it and it works fine. Again the Academy suggests that it should be used for Bricks Posts.
Yep, there’s no template which can be used to render Bricks data. Only WordPress data.
I will update An Intro To Templates – Bricks Academy to make this clearer.
Hope that clears things up.
Thank you for clarifying, @ribarich I’m very surprised that this isn’t a default feature (I can include Gutenberg data but not Bricks’ own data? Seems like an oversight IMO).
I’ll upvote the feature request and hope for it in the future. I guess I may not be able to use Bricks for too many sites just yet then as I’m looking to convert many from Elementor to Bricks in the future. I guess I’ll need to stick to the two single-page websites for now. I thought Bricks was far enough along for me but maybe not quite yet as I didn’t realize that was a current limitation (which is a big one to me).
Thanks again for the clarification.
PS - it seems there may be two duplicate feature requests (or at least very similar)…. So you may have more votes than you think.
1 Like
@ribarich Thanks for clarifying. Not good news though and as @d19dotca says not being able to use native Bricks even to create a plain blog post is a huge oversight. Certainly scuppers my plans.
There are fewer votes than might be expected because I don’t think everyone really understands what the ideas mean - I certainly didn’t, esp the Inner Content one.
So for my case … I create Custom Posts using Metabox. I then use the Single Template to display them. This works - Is this because the data saved by the CPT is classed as Wordpress data? I don’t use Gutenburg at all and do not save its data.
Thanks
Alan
@d19dotca Those 2 idea board entries are not exactly the same. The second one “Ability to add…” is about making it possible to add Bricks content within Gutenberg, which is already possible with Bricks template shortcodes, so we’ll probably close that suggestion.
We are having some discussions within the team about this. I’ll reply to this thread in a few days if there are any news.
2 Likes
Thank you! I look forward to hearing from you about this, as I (and others) really do see this as a large oversight / bug (even if it’s not technically a bug since it sounds like it’s working as designed) which needs to be a priority focus for the Single templates to be of any real use. Additionally, every other page builder does it the way we are requesting, so hoping Bricks follows suit too as that’s how users would expect it to work.
Hi @ribarich, I was hoping there may be an update you can share at this time with us. Please. Thank you in advance. At the moment, the current behaviour is preventing me from going “all-in” on Bricks Builder for my client sites.
Hi @d19dotca,
I am happy to inform you that after some discussion we decided we’ll add this feature to Bricks. It’s added to our system and it will be available soon. We’ll probably make it as a toggle on the “Post Content” element where you can choose between Bricks data and WordPress data.
1 Like
Hmmm, good, I think.
But can you explain exactly what “Bricks” data actually is?
To me the data is just data. I don’t differentiate between Wordpress, Bricks, Gutenburg or Metabox/ACF. Aren’t they all just data that we then use a template or page/post to display?
Personally it would make more sense to me for Bricks to be data agnostic, much like many of us dumb users.
Cheers
Alan
@ribarich - that’s perfect! Very happy to hear that. And that sounds fair to have a toggle on the Post Content element to look at where to pull the data from. Thank you so much for listening to user feedback. Hope to see that soon. 
@alanj - The data from any source will usually be stored in a different method, meaning the portion of the website which needs to “decrypt” or “interpret” the data must understand the source to know how to display it properly. They come from different parts of the database too, when you’re referencing things like Meta Box / ACF, as they generally create their own tables for custom fields. So all in all, the “data” may be the same in the end, but they are pulled from different areas of the website’s database and interpreted in different ways. That’s why Bricks will need to understand where the data is coming from and where it was written, etc in order to properly render it on the front-end. As such, I think it’d be nearly impossible to be “data agnostic” unless it can become smart enough down the road to know what is what automatically without user intervention. Hope that helps clarify that a bit.
Yep understand the difficulties, but that’s what computers/software are for, to make life easier!
To turn your argument on its head I go back to asking how I know what data is where? I use multiple plugins. So maybe I use bricks to display a form to create a CPT made in Metabox. Whose data is that? Is it Bricks or Metabox? Bricks knows about the Metabox fields ( or ACF if you prefer ).
I’m not trying to be difficult. I genuinely don’t understand the differences when multiple tools are used together. Not the mechanics of how to access different tools data but how you know whose data it actually is.
My worry with a toggle is that it then limits the Posts element to only use a single source.
I think I’ve confused myself now. Back in the hutch.
I don’t think it’s worthwhile to think about other sources of data here like Metabox. I’ve explained the terminology a few posts above PLANNED: Single Page Templates removes/hides previously added Bricks Builder content on Pages - #22 by ribarich So there’s only a distiction between “WordPress data” and “Bricks data”
Advanced and unnecessary: WordPress posts are fundamentally entries in wp_posts MySQL table. When you put some elements in Gutenberg and click save, that stuff is saved in the wp_posts table under post_content. But when you go to Bricks builder, make some elements, and click save, that’s not saved under post_content, but rather it’s saved in the wp_meta table and associated with the appropriate post. So when a post is being rendered, Bricks needs to choose whether to use post_content from wp_posts (WordPress data) or metadata about a post from wp_meta (Bricks data).
2 Likes
lol, yes I think you may be overthinking it if you ask me. 
I think understanding some fundamentals may help you see the bigger picture.
- When using ANY page builder to design a page, they store their own data in their own format in the WordPress database.
- When using WordPress’s Gutenberg, it’s the same thing as all other page builders… Gutenberg stores in its own format in the database.
- When editing a Custom Post Type (CPT) via any of the multiple plugins available, they all will store in a pre-defined format which is publicly documented in those tools developer documentation, and that is where compatibility comes in for any Page Builders tools where they need to specify which ones they support. For example, some page builders don’t support Pods, some don’t support Toolset, etc. For Bricks, they support the ones laid out on this page: Dynamic Data – Bricks Academy
- For most page builders - Bricks included - you must enable support for CPTs first if you wish to use Bricks or any page builder to edit the CPT content itself. In this case, you’ll know what you’re using for the source. If you choose to use Bricks, then Bricks is obviously your source. If you’re using the built-in editor on a CPT, then Gutenberg will be the source since Gutenberg is the default editor for WordPress.
So you see, you don’t really need to know “where” the data is specifically, just what tool you used for creating the main content. It’ll generally either be one or the other… Gutenberg or Bricks, or if you’re using Elementor for example it’ll be Gutenberg or Elementor. You can forget about the ACF / Meta Box stuff because they aren’t the tools that you use to edit the CPT content, they just create the ability for you to edit the content.
I think it may be helpful to you to review YouTube and many other great sources to better understand the WordPress platform and how the data types are viewed and edited, etc. This would likely solve a lot of your hesitation. At the end of the day, I don’t think that’s really a responsibility of Bricks to fix, because there’s nothing to really “fix” here on the items that you’re bringing up. Using any tool at all assumes the user knows at least the fundamentals of it. You don’t start using a jackhammer before knowing how to safely operate it, right? lol. Same philosophy in my mind anyways. 
Hope that helps a bit.
I think what you’re going after here is not something Bricks has anything to really do with, and you’d be better off served by reviewing some great YouTube videos or some great blogs that explain all of these things in good detail.
Agreed definitely over thinking.
Maybe it’s all down to trying to do multiple things with one template? Bricks just has “Single” but Elementor has 3, Single Post, Single Page and plain old Single.
Of course which one should be used for what is anyones guess! ( I just use Single post to display a matching post via a grid view - I don’t use Page templating which is where you are coming from I think )
Bring back Lotus Domino, I was happy there!
Cheers
Alan
Just curious when approximately this improvement will be added. Are we thinking in a month or two, or will it be a fair bit further down the road? Just trying to plan out some possible site migrations to Bricks.
“Render Bricks Data in ‘Posts’ Element” is scheduled for Bricks 1.3.5 (= in less than a month)
6 Likes
Right, thanks for the hint!