Bricks Builder Review: The WordPress Theme That Replaced My Page Builder

I’ve been building WordPress sites for clients since the days when "page builder" meant Visual Composer shortcodes and a prayer. I’ve cycled through Elementor, Divi, Beaver Builder, Oxygen, and a handful of weird experiments along the way. So when I tell you Bricks Builder is the first one I’ve actually wanted to keep using on every new project, you should know that statement comes with some baggage.

Bricks is different from the others in one important way: it’s not a plugin. It’s a WordPress theme with the visual editor baked in. One install gives you the theme, the builder, the WooCommerce templates, the header/footer system, the popup engine, and the query loop. There’s no "install builder, then install starter theme, then install addon pack for the things the builder doesn’t do" loop. That’s the entire pitch in one paragraph, but it’s the kind of structural change that quietly fixes a dozen problems you stopped noticing.

Table of Contents

• What Bricks actually is
• Key features (and why each one matters)
• Walking through the builder
• Installation and setup
• The query loop builder
• Dynamic data and conditions
• WooCommerce in Bricks
• Real-world use cases
• Developer reference
• Performance, output quality, and gotchas
• Pricing and licensing
• FAQ
• Final thoughts

What Bricks actually is

Bricks is a visual website builder for WordPress, distributed as a theme. The team behind it (a small studio also called Bricks) released it in 2021 with a fairly opinionated take: most builders generate too much markup, too much CSS, and too many divs, so what if we just don’t.

The result is a builder that produces clean, semantic HTML. There’s no jQuery dependency. The runtime JavaScript is small. Every element renders the tag you tell it to render. When you drop in a "container", the output is a single <div>, not a <div> wrapping a <div> wrapping a <section> with seventeen utility classes. If you’ve spent any time fighting bloated builder output with PageSpeed Insights, you’ll notice the difference immediately.

The other piece of the pitch is that Bricks treats devs as first-class users. There are 219 apply_filters hooks in the codebase, 27 do_action hooks, a full REST API at /wp-json/bricks/v1/, and a Code element that lets you write actual PHP in the builder (gated by capability, with a disallow list, so it’s not as crazy as it sounds). I’ll get into the code element later because it’s the single thing that has saved me the most hours.

Key features (and why each one matters)

I’m going to skip the marketing-page bullet list and tell you what’s actually useful when you’re three months into a real project.

• Visual builder with a real left panel. The element library lives on the left (Layout, Basic, General, Media, Forms, WooCommerce, etc.). Searching is fast. You can drag or click to add. Nothing fights you. After Elementor, this feels like turning the lights on.
• 86 native elements + 48 WooCommerce elements. That’s not marketing puffery; I counted in the source. The 48 WC elements cover the full storefront (product page, cart, checkout, my account, mini-cart, filter, variation swatches) which means you almost never need an Elementor-style "addon pack" to finish a shop.
• Components. Save any element (or group of elements) as a component, edit the master, and every instance on every page updates. This is the Figma model, and once you build a real site with it you stop wanting to live without it.
• Global classes. Tailwind-style reusable utility classes, but defined visually. Make a .card-pad class once with 32px padding and a 1px border, then reuse it on 40 elements. Change it once, change them all.
• Global variables. Real CSS custom properties, managed from a UI. Spacing scales, colors, font sizes, all centralized, all swappable site-wide.
• Query loop builder. Any element can be a loop. Wrap a "container" around a heading + image + button, attach a query, and you’ve got a card grid pulling whatever post type, taxonomy, ACF field, or custom query you point it at. This is the feature that ate my custom WP_Query templates.
• Dynamic data. A {post_title}, {acf:my_field}, {post_meta:_price} token system that works anywhere you can type text. Drops into headings, link URLs, image sources, button text, attribute values. It even runs filters: {post_excerpt:30} truncates.
• Conditions. Per-element visibility rules. Show this section only for logged-in users. Hide this button if the post has no thumbnail. Run a PHP callback. No "register two layouts and use template parts" gymnastics.
• Interactions. Per-element triggers: on click toggle a class, on scroll fire a JS event, on hover open a popup. Most stuff that used to need a custom JS file is just two dropdowns now.
• Templates system. Headers, footers, popups, single-post layouts, archive layouts, search results, 404. All built in the visual editor and attached via conditions (post type X, taxonomy Y, URL pattern Z). You can have three different header templates triggered by URL pattern without writing PHP.
• Built-in popups. Modals with triggers (scroll depth, exit intent, time on page, click, custom event). No need for a separate popup plugin.
• Built-in form builder. Inline validation, multi-step, conditional fields, email + webhook + custom action handlers. Solid enough that I haven’t installed WPForms on a Bricks site yet.
• Frontend filters. A complete facet/filter system (checkbox, radio, range slider, datepicker, search) for any query loop. Replaces FacetWP for most needs.
• No jQuery. Vanilla JS runtime. Fewer kilobytes shipped, fewer compatibility headaches with other vanilla scripts.

That’s the short list. Each one of those bullets is its own afternoon if you really want to dig in, but those are the features that make me reach for Bricks before reaching for the alternatives.

Walking through the builder

Let me describe what you actually see when you click "Edit With Bricks" on a page.

The toolbar across the top has a brand logo (yellow square with a "b") on the far left, then a row of icons: undo/redo, copy-paste, page settings, command palette, an "add new element" plus. The middle of the toolbar shows viewport switches (desktop, laptop, tablet, mobile, plus custom breakpoints you’ve defined) and the current canvas width/height. The right side has more icons: revisions, view on frontend, preview as logged-out, save.

The left panel is the element library. By default it’s grouped: Layout (Section, Container, Block, Div, Slot), Basic (Heading, Basic Text, Rich Text, Text Link, Button, Icon, Image, Video), General (Nav Nestable, Dropdown, Offcanvas, Tabs, Accordion, Slider, Carousel, Pricing Tables, Testimonials, Team Members, Counter, Pie Chart, Progress Bar, Countdown, Animated Typing, Alert, Map, Social Icons, Sharing, SVG, Audio, Code, HTML, Shortcode, Form, List, Logo, Rating, Toggle, Toggle Mode), Single (post-content, post-title, post-meta, post-excerpt, post-author, post-comments, post-navigation, post-taxonomy, post-toc, post-sharing, post-reading-time, post-reading-progress-bar, related-posts), WooCommerce (the full 48 WC elements). There’s a tab next to Elements for Components, which are your reusable building blocks.

The right panel holds the structure tree. When you select an element, it switches to that element’s settings (Content / Style / Settings tabs). The Style tab is where you spend most of your life: layout, typography, background, border, shadow, transform, transition, position, custom CSS, custom JS. Every property supports the viewport switcher in the toolbar, so "this padding is 80px on desktop, 40px on mobile" is two clicks.

The middle is the canvas. Click anywhere to select. Right-click for a context menu (duplicate, delete, save as component, copy styles, paste styles, wrap in container, change tag). The breadcrumb at the bottom shows your current selection’s parent chain so you can climb up the DOM without hunting.

It’s hard to convey through screenshots how fast it feels. Bricks doesn’t reload the iframe when you change a setting; it patches in place. Typing into a font-size input updates the canvas character by character. That’s not a small thing when you’re tweaking layouts for two hours straight.

Installation and setup

This is where Bricks is a little different from a plugin. You’re installing a theme, so the flow is:

1. Upload the theme. Go to Appearance → Themes → Add New → Upload Theme, pick the Bricks zip, install, then click Activate.
2. Optionally install the child theme. If you’re going to add custom PHP via functions.php or override templates, install the Bricks Child Theme zip the same way and activate that instead. (You can do this later.)
3. Activate your license at Bricks → License.
4. Enable Bricks for the post types you care about. Go to Bricks → Settings → General → Post types and toggle on Page, Post, and any custom post types where you want the visual editor. This is important: until you enable a post type, the "Edit With Bricks" button won’t appear in the WordPress editor.
5. Set builder access per role. Go to Bricks → Settings → Builder Access. Out of the box, only Administrator can use the builder. If you want editors or a custom role to have access, set their capability here.
6. (Optional) Set theme styles. Go to Bricks → Theme Styles and define default H1-H6 sizes, link colors, button styles. Anything not overridden in the builder inherits from here. This is your one-time "set the brand defaults" step.
7. Build a header and footer template. This trips up most people on day one because Bricks doesn’t ship with a default header. Go to Bricks → Templates → Add New, pick "Header" as the type, set the condition to "Entire Website", and design it. Same for the footer. From now on, every page on the site uses that header/footer.

The "no default header" thing is intentional. Bricks doesn’t want to make styling decisions for you. But if you’re new to the theme it can feel jarring. Your homepage will literally have no header until you build one. The good news is that the upstream team and community ship dozens of free remote templates you can import in one click (Bricks → Templates → Import).

The query loop builder

This is the feature I’d defend in a knife fight. If you’ve ever built a custom card grid pulling posts in WordPress, you know the pattern: register_post_type, custom template, new WP_Query, while ($q->have_posts()), manually mark up the card, escape everything, queue some CSS. Maybe an hour for a simple grid, longer if you want filters or AJAX pagination.

In Bricks, the same job is roughly:

1. Drop a Container on the page.
2. In the Container’s Settings tab, toggle "Use as query loop".
3. Pick your query: post type "product", category "running shoes", orderby "rand", posts per page 8.
4. Inside the container, drop a Heading (set its content to {post_title}), an Image (set its source to {featured_image}), a Basic Text (set to {post_excerpt:25}), and a Button (set its URL to {post_url}).
5. Style the container as a CSS grid. Done.

That’s 60 seconds of work and you’ve got a filterable, dynamic, AJAX-paginatable grid. You can wrap any element in a query loop, not just containers. Even a single image element can loop, which is great for client logo strips or category icon rows.

For more complex queries the UI exposes basically every WP_Query argument: meta query, tax query, date query, exclude IDs, include IDs, parent post, search term, ignore sticky, post status. For the cases the UI doesn’t cover, there’s the bricks/query/run filter where you return your own array of objects and Bricks happily loops over them.

That last bit is underrated. Want to loop over rows from a non-WP table? Or items returned from a remote API? Or a hardcoded array of testimonials? Same UI, you just feed Bricks a different data source through one filter. The builder doesn’t care that the source isn’t a real WP_Post.

Dynamic data and conditions

Dynamic data tags work anywhere you can type text. They’re rendered server-side at output time, so what you put in the builder is what the visitor sees.

The base set ({post_title}, {post_excerpt}, {post_author}, {post_meta:_price}, {user_name}, {site_name}, {archive_title}, {post_url}, {featured_image}, etc.) covers ~80% of normal use. Then there are built-in integrations with ACF, Meta Box, JetEngine, Pods, Toolset, and CMB2, so {acf:hero_image}, {mb:my_metabox_field}, {jetengine:my_field} all work out of the box. The list of supported tags is huge; pick whatever metadata framework you already use and there’s a provider for it.

The clever bit is filter modifiers. Append : and an argument to most tags: {post_excerpt:30} truncates to 30 words. {post_title:upper} uppercases. You can chain them. For one-off transforms it beats reaching for PHP.

Conditions are the visibility layer on top of dynamic data. Every element gets a Conditions tab where you can stack rules like "user is logged in", "post has thumbnail", "URL contains /sale", "ACF field is not empty", "current language is French", "date is between X and Y", or "custom PHP returns true". Multiple conditions per element, AND or OR logic, with a UI that doesn’t make you feel stupid. This single feature has eliminated more "I need to conditionally show this for X users" support tickets from my queue than anything else.

WooCommerce in Bricks

Bricks ships its own WooCommerce templates and 48 store-specific elements, all editable in the builder. That means you don’t override single-product.php to change the product page layout; you visually build a "Single Product" template, attach it to your product post type, and ship it.

You also get the things that usually require an extension: variation swatches (color, image, button, label), quick add to cart, custom add-to-cart text per product type, product gallery layouts (single, slider, lightbox), and a product loop element that’s a proper Bricks query loop, so you can mix-and-match cards however you want.

The checkout is fully buildable. You can rearrange the form fields, change billing/shipping layout, add upsells in the order review, hide the coupon field, conditionally show payment methods. Same for My Account. Same for Cart. If you’ve ever spent a day overriding WC templates with template parts and wc_get_template_part, the Bricks WC editor is going to feel like cheating.

There are still cases where you’ll want a dedicated WC extension (subscriptions, bookings, custom product types), but for storefront layout work, Bricks covers it natively.

If you want to pair Bricks with a complete WooCommerce setup, you can grab WooCommerce Subscriptions or WooCommerce Memberships from GPL Times and the Bricks WC elements will render those product types correctly out of the box.

Real-world use cases

I’m going to give you five scenarios from actual projects so you can match them against what you’re trying to build.

1. Marketing site for a SaaS. Bricks is overpowered for this and that’s fine. You’ll use the Header template + Footer template + Single template for blog posts, build a custom homepage section by section, and lean on global classes for buttons + cards. Total build time for a 12-page site: about a day if you have all the copy.

2. WooCommerce store with custom product cards. This is where Bricks really shines. Use the Products element as a query loop, design your card once, drop in dynamic data for the price + stock + rating, add a "quick view" interaction. Pair with WP-Optimize Premium for caching and you’ve got a fast, custom-feeling shop that doesn’t depend on a builder addon for the storefront.

3. ACF-heavy content site (real estate, recipes, directory). Build the single-listing template visually, dropping ACF fields into headings and images via dynamic data. The query loop builder handles the archive. Conditions handle "show only if this field exists". If you also use the filter elements, you’ve got a full listing site without writing a WP_Query, and you can interlink it with JetEngine if you need more complex relationship logic.

4. Membership / LMS site. Use the conditions system to gate sections by user role or capability. Use a "Login" form built in Bricks as the gate. Pair with LearnDash for the courses themselves; Bricks handles the marketing pages, the post-login dashboard, and the upsell layouts.

5. Multilingual landing page rotator. Bricks has WPML and Polylang integration baked in. Build the page once, translate the content via the strings UI, and the conditions system can pick different headers or popups per language. I’ve done this for a client who runs the same product across four countries; the Bricks side took half a day, the rest was translation.

Developer reference

This section is for you if you want to know what you can hook into. If you’re a non-developer reading along, you can safely skip to the next section, since none of this is required to use the theme.

Bricks exposes 219 apply_filters hooks and 27 do_action hooks. The most useful ones in practice:

Register a custom element

add_action( 'init', function () {
 if (! class_exists( 'BricksElement' ) ) { return; }
 require_once get_stylesheet_directory(). '/bricks/elements/my-element.php';
 BricksElements::register_element( get_stylesheet_directory(). '/bricks/elements/my-element.php' );
}, 11 );

Your element extends BricksElement, declares its name + label + category + controls, and implements a render() method that echoes HTML. Bricks handles the panel UI, the responsive controls, and the asset CSS generation for you.

Register a custom dynamic data tag

add_filter( 'bricks/dynamic_data/tags_registered', function ( $tags ) {
 $tags[] = [
 'name' => '{my_app_id}',
 'label' => 'Current App ID',
 'group' => 'Custom',
 ];
 return $tags;
} );

add_filter( 'bricks/dynamic_data/tag_value', function ( $value, $tag, $post, $context ) {
 if ( $tag === 'my_app_id' ) {
 return get_query_var( 'app_id' );
 }
 return $value;
}, 10, 4 );

Now {my_app_id} is available everywhere in the builder: headings, image URLs, link targets, attribute values.

Replace a query loop’s data source

add_filter( 'bricks/query/run', function ( $results, $query ) {
 if ( $query->element_id!== 'my-element-id' ) { return $results; }
 $api_response = wp_remote_get( 'https://api.example.com/items' );
 if ( is_wp_error( $api_response ) ) { return $results; }
 $items = json_decode( wp_remote_retrieve_body( $api_response ) );
 return is_array( $items )? $items : $results;
}, 10, 2 );

The builder still shows the loop visually; the data just comes from your API. $loop_object in the loop is whatever you returned (in this case, the decoded JSON items), and dynamic data can reach into it via bricks/dynamic_data/tag_value.

Allowlist a function for the Code element

add_filter( 'bricks/code/echo_function_names', function ( $functions ) {
 $functions[] = 'my_custom_render_function';
 return $functions;
} );

The Code element is gated by capability and by an explicit allowlist of functions you can call with the {echo:function_name} token. This is how you let trusted users run custom PHP in the builder without giving them the keys to the whole site.

Bypass SVG sanitization for trusted sources

add_filter( 'bricks/svg/bypass_sanitization', function ( $bypass, $svg, $context ) {
 if ( $context === 'my_trusted_icon_set' ) { return true; }
 return $bypass;
}, 10, 3 );

Default behavior sanitizes SVGs to prevent XSS via <script> or onload. If you maintain your own icon set you trust, you can opt out per source.

Custom condition group

add_filter( 'bricks/conditions/groups', function ( $groups ) {
 $groups['my_app'] = [
 'label' => 'My App',
 'options' => [
 'is_premium_user' => 'Is premium user',
 'has_pending_orders' => 'Has pending orders',
 ],
 ];
 return $groups;
} );

add_filter( 'bricks/conditions/result', function ( $result, $key, $condition ) {
 if ( $key === 'is_premium_user' ) {
 return user_can( get_current_user_id(), 'premium_member' );
 }
 return $result;
}, 10, 3 );

Now your custom conditions show up in the Conditions tab of every element, alongside the built-in ones.

Custom form action

add_action( 'bricks/form/custom_action', function ( $form ) {
 $fields = $form->get_fields();
 $email = $fields['form-field-email']?? '';
 // your logic: send to CRM, write to log, fire webhook
 $form->set_result( [
 'action' => 'custom_action',
 'type' => 'success',
 'message' => 'Thanks, we got it.',
 ] );
} );

In the Bricks form builder, you add "Custom" to the Actions list, and this handler fires on submit. Cleaner than wp_mail parsing inside init.

REST API surface

The Bricks REST namespace is bricks/v1. Endpoints include /get-templates-data/, /get-templates/, /get-template-authors/, /get-template-bundles/, /get-template-tags/, and /get-global-classes-site-usage. These are mostly used by the builder UI itself but they’re a useful way to query template metadata from external tools. They require user authentication and the bricks_full_access capability by default.

Performance, output quality, and gotchas

The output quality piece is what made me a Bricks convert. A built page in Bricks is a regular WordPress page with tight markup: containers render as a single <div> (or whatever tag you pick: section, article, aside, etc.), there are no wrapper-of-wrapper-of-wrapper layouts unless you explicitly nest them, and the CSS is per-element and generated once to a file (you can see it in wp-content/uploads/bricks/css/).

There’s no jQuery. The runtime JS Bricks ships is small and vanilla. If you don’t use elements that need JS (animations, sliders, accordion), the page ships almost no JS at all.

You still need a caching plugin for production. The Bricks team explicitly recommends one and it pairs well with WP-Optimize Premium or Perfmatters. The "generate CSS files" setting in Bricks → Settings → Performance is where you control whether per-page CSS is inlined or written to disk; default it to disk for caching to be useful.

Now the gotchas, because no review is honest without them.

The learning curve is real. Bricks is more like Webflow than like Elementor. If you’ve never touched flexbox or CSS grid, you’ll spend the first week confused about why your three columns stack on mobile. The builder doesn’t hand-hold; it gives you direct access to layout, padding, gap, justify-content, align-items, and assumes you know what those do. You’ll come out the other side a better web dev, but the first project will be slower than it would be in Elementor.

There’s no "import demo site" wizard. Other themes ship a one-click demo importer. Bricks does too, sort of (the Templates → Import flow imports remote templates), but it’s element-by-element, not "full site". For a quickstart, head to the community remote templates and import a homepage you like as a starting point.

Header/footer are required setup. Out of the box your site has no header. You have to build one as a template. This is the most common day-one confusion. The fix is 10 minutes of work.

The Code element is powerful and dangerous. If you enable it for non-admin roles without thinking about it, you’ve handed those users PHP execution on your server. Read the capability + disallowlist docs before flipping the switch. Default-off is the right setting.

Custom CSS in the Style tab is per-element. That’s beautiful for scoping but it means you can’t easily share rules across elements unless you use Global Classes. Once you internalize "use Global Classes for shared styling", this becomes natural.

No drag-and-drop for adding elements. You click to add, then drag inside the structure tree or canvas to reorder. Some users love this (more deliberate), some hate it (slower for layouts). I’ve ended up preferring it but it’s a real friction point on day one.

Builder access and permissions

The capability system deserves its own paragraph. Bricks lets you create named capabilities ("Full access", "Edit content", "No access" are the defaults) and assign each one to a WordPress role. So you can give editors access to edit page content but not change templates, or give a client role the ability to view templates but not modify global classes.

This matters when you’re handing off a site. You don’t want the client accidentally deleting the header template; you do want them to be able to update the homepage hero text. Bricks lets you draw exactly that line.

The settings live at Bricks → Settings → Builder Access, and you can extend the system with bricks/capabilities/permissions to add your own granular capabilities.

Pricing and licensing

Bricks is sold by the upstream team as a single product (the theme + builder + child theme + all integrations) with annual or lifetime tiers, licensed per number of sites. The Standard tier covers a single site; the Pro tier covers up to three; the Ultimate tier is unlimited; and there’s a Lifetime option that does what the name says. Pricing changes from time to time, so check bricksbuilder.io for the current numbers if you’re buying directly.

That’s the build I use on staging environments and client work.

The license you get from GPL Times is for the theme files only; you don’t get access to the upstream Bricks Academy or the official support forum. For production sites where you want vendor support, buy a direct license.

FAQ

Is Bricks a theme or a plugin?
It’s a theme. You activate it like any WordPress theme. The builder and all the features live inside the theme.

Can I use Bricks with my existing theme?
No. Bricks replaces your theme entirely. That’s by design. Having both the builder and the theme controlled by the same code is what lets Bricks output such clean markup and avoid double-rendering.

Will Bricks work with Elementor pages I already built?
Not directly. Bricks doesn’t read Elementor’s stored data. If you switch, you’ll rebuild those pages in Bricks. The Bricks team has shipped a Block Editor → Bricks data converter, but no Elementor importer. Plan accordingly when migrating.

Does Bricks slow down WordPress admin?
No, the admin overhead is minimal. The heavy lifting is in the builder iframe, which you only load when you click "Edit With Bricks". Regular admin pages (post list, settings, etc.) are not affected.

Can I use Bricks without writing CSS?
Yes, for 90% of work. The Style tab covers spacing, typography, layout, colors, backgrounds, borders, shadows, transforms, transitions, position. You’ll only reach for the custom CSS field for niche selectors or hover-state tricks. The other 10%, usually weird third-party widget styling, does need CSS.

Is the query loop builder really a WP_Query replacement?
Yes. It exposes every WP_Query argument plus tax/meta/date queries, supports custom post types, exposes hooks for non-WP data sources, and handles pagination and AJAX pagination out of the box. I’ve stopped writing WP_Query templates for new projects.

How does Bricks compare to Oxygen?
Same philosophy (clean output, no wrappers, dev-friendly), different execution. Oxygen feels more like a code-editor-with-buttons; Bricks feels more like Webflow. Personal preference. Bricks has more active development right now. If you want a third option in the same lane, Breakdance Pro sits between Bricks and Elementor and is worth a look.

How does Bricks compare to Elementor?
Bricks is faster, cleaner-output, more dev-friendly. Elementor has more third-party addons and a bigger community of free templates. For new builds I pick Bricks; for "I need to ship this in three hours with 50 stock sections", Elementor still wins.

Can I use Bricks with WooCommerce?
Yes, deeply. 48 WooCommerce elements, full template builder for single-product, cart, checkout, and my-account pages, native variation swatches, custom product loops. It’s the strongest WC builder I’ve used.

Final thoughts

Bricks is the first WordPress builder I’ve used where I felt like the trade-off had finally tilted the right way. You’re trading some hand-holding for cleaner output, faster pages, and a far better developer experience. If you’re comfortable with flexbox and CSS basics, that’s an obvious trade.

It’s not for everyone. If you’re building one site a year and you want a library of pre-made templates to drag and drop, Elementor is still the easier on-ramp. But if you’re building sites professionally, or you maintain a site you care about long-term, or you’ve been frustrated by "why does my page builder make the markup look like this", Bricks deserves a real afternoon of your time.

Install it, build a small landing page, and you’ll know in about an hour whether the builder fits your brain. For me it did, and I haven’t looked back.