Bricks 2.3.8 – Visual website builder for WordPress

I tested Bricks – Visual website builder for WordPress on a couple of messy client installs, including one WooCommerce site that already had enough plugin soup to make me question my career choices. And yeah, Bricks is good. Annoyingly good, actually. Not “marketing page good”, but “I can finally delete three garbage add-ons and sleep” good.

The builder lives where you expect it: WordPress Admin -> Bricks -> Settings, then the actual visual editing happens through Edit with Bricks on pages/templates. Theme styles are inside the builder under Theme Styles, not buried in the Customizer like some 2016 relic. Global colors, typography, buttons, form styling — all manageable there.

What I liked most about Bricks – Visual website builder for WordPress is that it doesn’t vomit DOM nodes like Elementor on a bad day. I opened Chrome DevTools, checked Elements, and the structure was mostly sane: sections, containers, blocks, not fifteen nested wrappers for a button. Small mercy, but after years of div lasagna, I’ll take it.

Performance: mostly clean, but don’t get cocky

In DevTools -> Network, Bricks behaved better than most builders. On my setup it loaded the main frontend assets as bricks-frontend / bricks-scripts, plus whatever I stupidly added myself. Fonts are controlled in Bricks -> Settings -> Performance and in Theme Styles -> Typography. If you import Google Fonts casually, Bricks will still load what you tell it to load. Shocking, I know.

My usual fix: I set typography to system fonts in Theme Styles, then added one custom font manually through Bricks -> Settings -> Custom Fonts. After that, Network stopped showing the clown parade of five font weights I didn’t need.

For CSS, check Bricks -> Settings -> Performance -> CSS loading method. I prefer external files, because inline CSS on large pages becomes a debugging swamp. If styles look stale, clear Bricks’ generated CSS from Bricks -> Settings -> Performance -> Regenerate CSS files. That button saved me from blaming LiteSpeed for something that was absolutely my own fault.

The stuff you can change in the builder

Most layout work in Bricks – Visual website builder for WordPress belongs in the builder: headers, footers, archive templates, single post templates, Woo product layouts. Go to Bricks -> Templates, create a template, assign conditions, done.

Dynamic data is also decent. For post title, featured image, custom fields, Woo price, etc., use the little database icon in the field. If you’re using ACF, Bricks handles it cleanly. No weird shortcode nesting rituals.

Mobile menu settings are inside the Header template itself. Select the Nav Menu element, then check Mobile Menu settings. I had one case where the off-canvas menu refused to close after clicking an anchor link. My ugly-but-working fix was adding this in the child theme:

add_action('wp_footer', function () {
  ?>
  <script>
  document.addEventListener('click', e => {
    if (e.target.closest('.bricks-mobile-menu a[href*="#"]')) {
      document.body.classList.remove('bricks-is-frontend');
      document.querySelector('.bricks-mobile-menu-toggle')?.click();
    }
  });
  </script>
  <?php
});

Pretty? No. Did the client stop calling? Yes.

What still needs PHP surgery

Don’t edit parent theme files unless you enjoy losing work during updates. Use a child theme and put custom logic in:

/wp-content/themes/bricks-child/functions.php

Bricks stores template content in the database, mainly in wp_posts as bricks_template posts, with builder data living in post meta. So if you’re expecting old-school single.php and archive.php work, adjust your brain. The actual layouts are database-driven, not classic PHP templates.

For custom shortcodes, custom Woo tweaks, extra body classes, or weird conditional logic, I use hooks in functions.php. Example: excluding Bricks scripts from delay in WP Rocket or Perfmatters is not optional on some builds. If you delay everything, Woo variations can break. I had to exclude:

jquery-core
wc-add-to-cart-variation
bricks-scripts

After that, product variation dropdowns stopped acting possessed.

With LiteSpeed Cache, I usually go to LiteSpeed Cache -> Page Optimization -> JS Settings and exclude the same handles from delayed JS. If the mobile menu opens once and then dies, check Console first. Nine times out of ten it’s delayed JavaScript, not Bricks being haunted.

GPL, activation, and updates without the fairy dust

I personally tested Bricks – Visual website builder for WordPress as a GPL WordPress product and it worked normally for me, including the “Unlimited Website Usage” type setup. No fake crippled builder, no locked editor screen, no artificial site count drama in the actual theme files I tested.

Officially, if you buy it, you add your license key in Bricks -> License and updates come through the WordPress updater. If you’re using a GPL package from somewhere else, don’t expect official support or automatic updates. Manual update is boring: download the ZIP, go to Appearance -> Themes -> Add New -> Upload Theme, replace the old version, then regenerate CSS in Bricks. Backup first, unless you like performing live surgery with oven mitts.

Demo imports are under Bricks -> Templates or via JSON template import. Some full demos depend on external plugins or ACF field groups, so if an imported page looks naked, check missing plugins before yelling at the screen.

FAQ

Does Bricks break with WP Rocket?
Only if you delay bricks-scripts, jquery-core, or Woo variation scripts. Exclude them and retest in DevTools Console.

Why is my mobile menu dead after optimization?
Usually delayed JS. Disable delay, confirm it works, then exclude Bricks frontend scripts one by one.

Is the DOM really lighter than Elementor?
Mostly yes. Still, if you nest containers like a maniac, Bricks – Visual website builder for WordPress won’t save you from yourself.

Where do I fix global fonts properly?
Use Edit with Bricks -> Theme Styles -> Typography. For custom files, use Bricks -> Settings -> Custom Fonts, not random CSS pasted into six places.