Bricks team's stance on Cwicky's sudden end of development

Which can also mean Bricks is vulnerable to such Gutenberg takeover too :see_no_evil::no_good_man:… we’re in the eye of the storm right now in WordPress world as more native “blocks” get implemented…

Which was the whole point of this topic…

It’d be nice to at least hear from Bricks team on what they think about the future of WordPress and where Bricks stands with Gutenberg advancing, the new WooCommerce Product Editor & Blocks improving rapidly…

March 26th is WordPress 6.5, and many of my plugins have updated to indicate the new feature to let other plugins know they rely on each other… just the other day WP Fusion says incompatible with the new WooCommerce editor… everything happening so fast…

Custom development I will go for a bit until Full Site Editing Themes (FSE) get forced and classic themes start getting deprecated…

Bricks will be unbeatable if it doesn’t rely heavily on Gutenberg. Even more unbeatable with the addition of improved post and page editing capabilities. And we’re completely invincible if, instead of integrating with Gutenberg, everyone wants to integrate with Bricks :slight_smile:

Not really. If Bricks remains the “developer’s choice” and block editing is for the non-dev end users monkeying around with point-n-click and drag-n-drop pre-made widgets, then their paths will never really cross.
It’s like saying legos could overtake lumber yards and contractors. Or prepackaged frozen foods will overtake restaurants and chefs.

Yes, a great chef can try to make prepackaged foods ‘work’, just like a dev can try to make lego widget block building work, but it’s not fun.

We will see how it all plays out.

Right now things are moving quite fast in the WordPress world…

no, I don’t think so

block editor fundamentally very very different and serves more than one way in the wp core.

did you checked the gutenbricks ?

That is a very cool approach to Bricks, but heavy “vendor lock-in”. What if I wrote 100 Posts, and inserted these “Gutenbricks” into those posts, then in 2 years change themes? :scream:

For developers managing clients, this is excellent!

I like only implenting CTA’s in blog post content through hooks / Javascript to never touch the actual content.

You can then simply use a Bricks shortcode to hook into the_content, or just use a plugin for after every nth header.

Allows your website to add/remove CTA’s without embedding into the content.

This is an interesting thought

1 Like

Yes this way the content remains high-quality, and you can change out your CTA at any time.

Instead of hooking into the_content(), right now I quickly hacked together some quick jQuery that looks for h2:nth-of-type().

As a bonus, you can only show these ads to non-members by only enqueuing based on WordPress Role, if logged in… or if they have a Tag (if you use a CRM) for a better user experience!

Here’s my example:

jQuery( document ).ready(function($) {

// Store your image into a variable
var firstBanner = '<a class="ctaBanner" target="_blank" href="#"><img src="#"/></a>';

/**
* .the-content class for  WordPress the_content() I think..
* And look for <h2> inside, and add it right before it :)
*/
$('.the-content > h2:first-of-type').prepend(firstBanner);
  
// Can also use another image for variety
var secondBanner = '<a class="ctaBanner" target="_blank" href="#"><img src="#"/></a>';
$('.the-content > h2:nth-of-type(3)').prepend(secondBanner);
  
// Can also repeat the first banner later on..
$('.the-content > h2:nth-of-type(7)').prepend(firstBanner);

Obviously too many CTA is spammy… but has been a really easy way to implement CTAs, enqueued only on single() pages :slight_smile:

2 Likes