Bricks Builder as a plugin first?

Feature Requests / Improvements
22

Hey @sunny,

Firstly, a great thread that has provoked many comments, which is always a win-win. :+1:

Personally, I sit on the side of Bricks being a theme. Most has been said already in the comments. But here are some of my thoughts:

As all seem to agree, it is not good to have two builder plugins being used simultaneously. I believe most are commenting on it relating to potential conflicts between the two whilst using them, which is a very just reason.

But something I have not seen mentioned is all the residuals and junk code left behind in the DB by the builder plugin you will be replacing (not only that, all the 3rd party plugins you have used to support the builder plugin you are replacing too). That’s why I would never transition, and if it gets to the point that the only choice is to use another builder plugin, then it would be a redesign on a fresh install or, as @omega mentioned about having on a subdomain (but this also has its own implications such as SEO).

You also keep mentioning if it was a plugin, then we have the benefit of choosing from a variety of themes, but you also keep repeating that the themes you would use would be bare-bones (to avoid conflicts, ensure no bloat etc., which is the correct thing to do). However, (and as you also mentioned, which is also correct) bare-bone themes have no real or very limited functionality, so the theme becomes pointless with no benefits over having Bricks as the theme?

I guess the initial opening section in your first comment where you write ‘changing bricks for whatever reason’ actually needs a reason why you would want/need the ability to switch to a bare-bones theme that offers little to no functionality…what does it offer?

2 Likes
23

@sunny I see your point of softly transitionning a big site to Bricks, so let me precise my thoughts.

I’m not against the “plugin” format if everything in Bricks is transferred to a plugin. I come from O2 and I was happy with it (even if the “no theme” solution was a bit extreme in some situations!).

I’m against having both builders or templating systems or ecosystems coexisting, with a lot of redundant and conflicting PHP/CSS/JS.

Or you will have to deactivate with hooks current site’s theme/builder/style/librairies on the new pages and only activate Bricks and new tools, or figure out which current plugin/librairy/CSS can work with the new environment if client needs some current features on the new pages, which is possible on simple sites, but too complex and risky (thus, expensive) for me.

That’s why I’m a bit binary here…

  • Simple addition like a landing page? Decline or use the current environment (and charge the fact you’ll have to dig into Visual Composer :rofl:).
  • Complex addition? Decline or redesign all.

I prefer explaining to the client the limitations of his current environment and charge him for rebuilding everything (or lose him) than having to deal later with updates, conflicts or growing complexity on the site.

Note that in some cases I used a subdomain for a brand new blog or acquisition tunnel because I was 100% sure I would rebuild the whole site later. So the subdomain was kind of a new site’s live and staging environment and all the styling was not just for these additions only and I could keep price reasonable knowing I would compensate later :wink:

2 Likes
24

Also look from the support team perspective. Using Bricks as a plugin with other theme or builder will lead to issues. Users will open multiple support request for such conflicts making the team spend their time debugging things which aren’t issue in the first place. Thomas was smart to make it a theme to avoid conflicts and overrides.

6 Likes
25

That’s what I generally do. As Michael mentions this has a lot of downsides too, such as SEO. Also stops us from building a header, a new page inside their current navigation etc.

I think I’ll have to use something like cwicly for these one off projects and bricks for full builds when I’m able to have full control.

Luckily we have some great alternative choices these days :raised_hands:

2 Likes
26

What is the reality of having two download options. Download Bricks Builder theme. Second choice, Download Bricks Builder Plugin. Maybe that possible, I don’t know. This would allow us to choose the option we need that works best for the project while keeping bloat to a minimum. I am not against it being an additional purchase either.

1 Like
27

Hey @Michael,

Thanks for reading the full thread and providing a detailed response!

I’ve previously used Elementor alongside other page builders/themes, and in general I’ve found that page builders do a good job of isolating from other builders and only loading assets on the page it’s being used. These have mostly been squeeze pages with no header/footer though, so it is possible there could be conflicts if you’re using a header from one builder with page content from another. I wouldn’t peg it as likely, but it is possible.

Great point re: junk code. Junk code being left behind is always something to consider. I’d obviously prefer to start from a fresh install 100% of the time, but there have been some sites I’ve worked on where starting from scratch would’ve added a month to the project scope. The junk code sucks, but is sometimes better than the alternative - especially when the company cares more about being nimble and generating sales than it does potential DB bloat.

Re: the theme, let me clarify a bit after thinking about it more. I think themes have some utility when it comes to setting global headers/footers and maybe some basic styling. I don’t love the idea of relying on a theme for features or page building functionality though, because that’s what creates the lock-in.

As an example, imagine a job board theme. It might have amazing functionality, but if you ever want to pair it with Bricks for full design freedom, well… you’re stuck. You can only ever use that job board theme for as long as you want to keep your pages in tact.

If it were a plugin instead, you’re no longer married to the theme. You can use Bricks and keep your job board.

This is similar for Bricks. If a few years down the road Bricks becomes a legacy builder and there’s a hot new page builder in town, your only option is to nuke the site. If Bricks were a plugin, you could keep the entire site as is and start building new pages with the new builder.

Again, starting fresh would always be preferred, but sometimes when you’re dealing with marketing sites with a ton of content, nuking the site is not a viable option.

And like I mentioned in the original post, this goes for migrating to Bricks as well. If a company is using a legacy theme and wants to start transitioning to Bricks without killing all their content, this isn’t possible either.

If they wanted to do it with Elementor, they absolutely could (which is why I’ve used Elementor in the past, despite it not being my page builder of choice).

Anyways, just wanted to bring those counter points up for consideration. I’m sure there are plenty of things behind the scenes that make Bricks being a theme more preferable, but I think it’s good to at least bring the downsides into discussion.

3 Likes
28

I totally agree with 100% of this. A lot of my thinking comes from considering my own sites or companies that I used to work for.

That’s when having to use Visual Composer REALLY sucks, and declining is obviously not an option :sweat_smile:

If it’s for a client, I’m all for explaining the limitations and charging accordingly. The reality though is I usually just end up recommending something like Elementor ( :smiling_face_with_tear:) because they can slide it right in without any issues or redesigns.

@ItsMe

I’ve thought about this too. I could imagine a way of being able to move the core page building functionality to the plugin, and keeping whatever functionality that needs to be in the theme, in the theme.

Obviously this would mean the plugin wouldn’t be as capable on its own, but it’d go a long way for both future-proofing or transitioning a site to Bricks.

29

It would be great to have bricks as a plugin together with a bricks theme. To use it with another theme should be possible if needed, but in this case, support only for money.

30

@Deanphillips I remember you also have Pinegrow license. So why not make gutenberg blocks and export as plugin from pinegrow for those one off projects / sales funnel?

31

I chose Bricks as a theme because I hate the old model of theme + a bunch of plugins! If Bricks is changed to that way as you understand it, Bricks will lose its distinctive character.

32

that’s possible, but I see no downside for the end user. You would just install the Bricks Plugin+Theme and you have the same thing. You are not forced to use any other thing, same like now.

4 Likes
33

Keep it a theme! Various reasons.

1 Like
34

I hope this is not forking the initial post in this thread. My problem is related, since it probably would not be a problem if Bricks was not a theme-only builder.

I am trying to understand the value of and choose between Bricks and Kadence (or similar approaches) - and not choosing both. But I need to understand the value and limitations of both approaches.

In Kadence I can style all Gutenberg blocks, while in Bricks I can only style native Gutenberg blocks ? Is that true ?

In Kadence I can only use the Gutenberg editor for visual editing with the limitations herein, but in time Gutenberg should get up to par, right ?

I am just so impressed with the Bricks builder. But when I try out the demo and just take the youtube embed block without editing in Bricks and view the result it looks unstyled - and I dont know how to style it with Bricks. Do I then need to import it into Bricks first ? In Kadence there are default styling for all blocks I believe ot at leeast it will look like Gutenberg, when I make the block in Gutenberg.

35

Hey @JacobDK,

Yeah, Bricks and Kadence are fundamentally different.

With Bricks, you can only design elements inside of the Bricks Builder. Your styling doesn’t affect anything in the Gutenberg editor, but you may have styling that affects your Gutenberg content on the front-end.

For example, if you set your heading styling in Bricks, your post headings will inherit that styling on the front-end as well.

Kadence is a block plugin, meaning you’re working within Gutenberg. What you design with Gutenberg is mostly what you’ll see on the front-end.

If you style a heading with Kadence, it’ll typically override Bricks’ styling because it applies a more specific CSS selector.

It’s actually not a terrible idea to use Bricks with something like Kadence.

You can design all your core pages, templates in Bricks, and use it for your main styling.

Since you’ll want to keep your blog post content in Gutenberg, you can either create custom CSS in Bricks to style your content on the front-end, or you can use Kadence to style elements of your post content directly.

Let me know if that’s too confusing!

1 Like
36

Hi @sunny - thank you for replying.

I get what you write, but in relation to my question it is a tiny bit confusing actually.

Could you explain in other words ?

I understand you are suggesting using the Kadence Bocks plugin, but Kadence is much more than Kadence Blocks it is also a theme, and the new Shop Kit is coming along great.

My preference is to stay with Gutenberg as it is coming along great in high speed right now, and my client should not be locked in to yet another builder as Gutenberg is going to be the standard interface when clients edit and create content themselves. I am not going to be the one who makes all the work. Also - Gutenberg works great when editing on mobile. Most builders are - I suppose - in their nature meant to be used on larger screens. But not being able to use an editor on my mobile phone is not really good. I see many great things ahead for Gutenberg.

My preference is strictly no-code. I do not want to mess with any css and copy-paste code. Nor do I want my clients to do that.

Also I do not care much for WooCommerce actually. Ecwid is the preference in this use-case as it is now. I hear many complaints about people working with WooCoomerce and Ecwid is just streamlined, scalable and all automation. Changing the design or a color here and a little thing there is not going to bring in cash-flow for small business owners. But Woo is necessary in my country due to payment methods and shortage in some use-cases.

But then this Bricks builder. It is just awesome. First builder that I really like.

EDIT:

And also. I just need for my clients to post stuff. Not really use blocks. That is just as advanced as using Bricks. And I can control the layout of what they post. But still… Lock-in-efffect is just not good.

1 Like
37

I am actually facing a similar dilema, which after searching a bit in the forums, has led me to this thread.

A client has their existing in-house made theme but plan to gradually move into Bricks. This led me to experiment with Multiple Themes plugin and so far I am able to pick just the pages I am working on to run on Bricks. No issues so far.

3 Likes
38

  1. I’m against Bricks as a plugin with all the reasons here were already written.

  2. I really don’t understand your blogpost. A landingpage is mostly a tempory used tool with a closed story / a fixed result (generate leads, newsletterabos, a closed information for retargeting whatever).
    You can use them on the main domain or subdomains or dedicated domains. Landingpages in most cases hook in the corporate design of the owner (there are some other cases but that are also uncritical.)
    I see no reason at all to use a page with two builders especially not elementor. There is no technical reason for it.

What reason would there be to move the landing pages away from Oxy, for example?
If the job was done right, the corevitals are good. Means it fulfills your purpose. If it does not fulfill its purpose any more it will be switched off. Because otherwise it has worst case negative effects.
If an oxygen is so far “broken” that it has become unusable, the responsible person has screwed up anyway, because something like that must be kept in mind and also looked at with foresight.

But now I look at what I have in return from two page / theme builders:

  • More security risks
  • no more stringent process
  • double risk of failure
  • even more plugins

Landing pages are much more about the story than the technology. The risk of changing the brand or the goals is significantly higher than the technical one.
If I really have to adapt the technical blueprint, I do it for the corporate page first and that is due every 3-5 years anyway. The landing pages are then also derived from this. That’s the job.

40

The most obvious reason there ought to be a Bricks plugin is for use with the Buddyboss ecosystem. @Sunny made some great points throughout, including:

I want to add that Marketing sites is not the only reason to use a powerful builder like Bricks. Wiki sites, recipe sites, magazine/editorial sites - the list goes on. But also those sites may require functionality where a Bricks theme gets in the way - or they need to have a custom theme developed.

And just to echo these sentiments:

I totally get it from a support standpoint - the compatibility issues would be an issue. But I’d be happy to pay one-off to solve those compatibility issues from the team, because the builder is just so darn good.

41

Please let Bricks be a theme.
Gone are the days of incompatibility issues with Oxygen and other plugins.

1 Like
42

Most things you added like “Wiki sites, recipe sites, magazine/editorial sites” you’re able to build with bricks. You’ don’t need additional things with exception a good form and CPT plugin.

If you need a great buddypress template - buy a great buddypress template. I agree it’s not possible. But than is bricks not the right choice for that project.