Bricks Add-Ons vs Plugins

There are often different types of plugins available that can be used to add similar functionality, each having a different end result, workflow & performance considerations. Here we’ll go over some of the key differences to consider when using Bricks-specific plugins (commonly known as ‘add-ons’) and more general WP plugins when building with Bricks.

Configuration / Workflow

With a general WP plugin – With a general WP plugin, changes to the configuration/behaviour is commonly done from a WP dashboard settings page or a custom UI from the plugin outside of Bricks. The functionality is often added to pages/templates by using shortcodes, the configuration from the settings is usually applied sitewide. For block plugins, it’ll be configured per block inside the Gutenberg editor.

With a Bricks Addon – the configuration will be done within the Bricks builder, inside the Bricks UI. There may be some plugin settings outside of Bricks, but that’ll mostly be for enabling/disabling specific modules. Any configuration will be specific to that particular element or applied only to that specific page/template.


With a general WP plugin – A lot of the time, the plugin assets (CSS & Javascript) are loaded on every page as the plugin doesn’t know in advance where the functionality is needed across the site. This is ‘bloat’ ie code being added where it’s not being used. It’s different for every plugin, you’d need to check what is being loaded after activating.

With a Bricks Addon – Any Bricks addon that is built off of the Bricks API, is going to be making use of Bricks’ built-in conditional loading. This means any CSS/JS that is needed will only be added in the specific places where it’s used. (for eg, with BricksExtras, even if every feature is active in the settings, nothing will be added unless you actually use it on a page).


With a general WP plugin – These plugins need their styling to work with any WP theme. This can sometimes mean very specific selectors in the CSS or heavy use of ‘!important’ that are difficult to override. Or sometimes it’s the opposite way and allows the theme to take care of all of the styling, which is a lightweight approach but often means needing to add a lot of custom CSS to get what you need. Any style settings will be outside of Bricks.

With a Bricks Addon – All styling is done inside Bricks, meaning it’s all styled visually. Only Bricks-specific skeletal styling is needed as default because Bricks is the only theme that could be active (and Bricks has very little default CSS).

Updates / Support

With a general WP plugin – This will obviously differ heavily between plugins, but the plugin developers are likely not following Bricks updates closely. So any potential future incompatibility is not likely to be solved during Bricks’ beta phase unless it’s specifically reported beforehand. The support team may not be familiar with Bricks.

With a Bricks Addon – Built specifically for Bricks, the updates will be followed more rigorously with testing of every beta/RC release. Very little chance of things breaking with future Bricks updates, as the functionality will be running off the same API as native Bricks. The support team will know Bricks inside out.

Use a General WP Plugin or Addon?

For some things, a more general WP plugin will make more sense;

  • Building an e-commerce or membership site. If you wish to switch themes in the future, it’s not a good idea to have to rebuild the entire shop or any core functionality of the site when you only want to change the theme/builder.
  • You’re currently building sites with multiple different builders that need common functionality such as an LMS integration, a specific form workflow/integration or similar performance enhancements (caching etc). In this case, using a separate plugin for every builder and trying to recreate separately may not make sense. You may prefer subscribing to one solution to build the exact same thing across all similar projects at once.

For other things, a Bricks-specific plugin will make more sense;

  • You’re primarily building sites with Bricks and want to stick to a Bricks workflow, avoid having to learn a new UI for every feature being added.
  • Being able to create everything visually inside the builder is a high priority.
  • Being able to hook into Bricks’ dynamic data / and use with query loops is a high priority.
  • Maintaining the same level of control over styles/accessibility is a high priority.
  • Conditional loading of assets specific to Bricks’ page/templates is a high priority.


In most cases, our users are using a mix of both. But it’s important to think it through when you next need to add some functionality.. what the priorities are and what type of workflow is going to help you build it more quickly when using Bricks.

Generally speaking..

If it’s related to theming/templating – eg. adding features/design/layouts to this specific build, adding elements to Bricks-built pages/templates that you want to style/configure visually.. then doing everything through the Bricks UI could be the best workflow. If so, a Bricks-specific plugin that extends Bricks’ current capabilities to include that functionality may be best suited for that task and be more optimal (for both workflow and performance).

If you’re adding core functionality to the site – eg. adding e-commerce functionality, setting up an LMS, creating a forum.. (things that aren’t specific to this version/pages of the site) then a more general WP plugin may be more suited for those tasks (and using Bricks UI only for templating / styling).