LolaCore for Bricks

You: The class btn-blue is used all over the site. Rename it to btn-primary without breaking the CSS.

Lola: btn-blue is on 34 elements across 12 pages, plus the header template and the card-cta component. I’ll rename it and update every reference. Here is the list. Proceed?

She named the pages. Not “34 places somewhere on your site.” She knows where that class lives because she maps your global classes, variables, theme styles, components, and templates before she writes anything.

Building a Bricks site once is the fun part. Keeping it consistent afterwards is what wears you down. A rename that touches twelve pages. A hero that has to repeat across twenty service pages with different copy in each. An inherited site full of classes nobody applies, variables nobody references, and theme styles whose conditions overlap. None of that is visible from the canvas, and none of it gets fixed by dragging. That grind has a name: admin fatigue.

LolaCore for Bricks gives Lola your Bricks site. You describe the change in plain language, she shows you which pages it touches, and she writes only after you confirm.

Same Bricks site. Same classes and pages. You stopped hopping between builder panels and started asking.

This is an addon. It needs LolaCore and the Bricks theme (2.0 or newer) on the same site. Walkthroughs and demos: lolacore.com/lolacore-for-bricks.

Third-party addon, not affiliated with Bricks

Bricks is developed by Bricks Builder. LolaCore for Bricks is an independent addon built by LolaCore. It is not affiliated with, endorsed by, or sponsored by Bricks Builder. You install and license Bricks separately.

She writes in the vocabulary your site already uses

If your buttons run on btn-primary, that is the class Lola applies. If your spacing runs on variables, those are the values she reaches for. She can tell when existing class names look like BEM, Tailwind-style utilities, or Bootstrap, and she works inside the convention you save — or your own pattern.

Tell her the convention once and she saves it, then reports what share of your current classes already follows it. From that point she creates classes that fit, and she tells you when a name you asked for would break the pattern. If you want that name anyway, she still writes it.

65 abilities, 69 when WooCommerce is active

• Knowing the system (13). Bricks version, CSS loading mode, and how much of the site she has mapped. Global classes with categories and trash state. Where each class is applied, page by page. Variables and which elements reference them. Theme styles with their conditions. Components with instance counts. Which template wins on a given page, and why. Element control contracts, the operating guide, and rebuilding the map in batches until coverage is complete.
• Governing the library (5). Classes no element applies. Pairs that do the same job under two names. Variables defined and never referenced. Components without a single instance. Theme styles whose conditions overlap. Every answer reports how complete her map is.
• Writing the design system (11). Create, update, rename, merge, trash, and restore global classes. Create and update variables in batch, so a brand palette lands in one confirmation. Update palettes and theme styles, conditions included. Save the site naming convention.
• Pages and elements (17). Read a page tree, then insert, move, duplicate, or remove elements. Apply the shared style controls at any breakpoint or state. Attach and detach global classes. Update element settings with live validation, so an unknown key comes back with the valid ones and the closest match first. Shortcuts for section, container, div, heading, text, image, and button.
• Templates (5). Create headers, footers, content templates, and archives with conditions. Preview which pages a condition would cover, listed by name, before it saves. Duplicate a template with new element IDs, or move it to the trash.
• Components (6). Turn a selection into a component and leave an instance in its place. Set properties, insert instances, update props and overrides, or detach an instance back into regular elements.
• Page behavior (5). Page settings, element conditions, native Bricks interactions (click, hover, viewport, scroll, WooCommerce events, and actions such as off-canvas), plus the dynamic-data tags she finds on your site, ACF included when ACF is active.
• The same change on many pages (3). Clone a section onto several pages with new IDs and different copy on each. Update text, images, or links across a list of pages, matched by class, element name, or position. Add or remove global classes on those matches.
• Shop layouts (4, when WooCommerce is active). Inspect which store templates exist and which the shop still needs. Create product, archive, cart, checkout, and account templates. Add product elements by name. Browse a catalog of 47 insertable WooCommerce elements.

Lola styles and configures any Bricks element. The count lands at 65 because Bricks styling controls are shared: _padding is _padding on every element, so she works through that grammar instead of needing one ability per widget.

Every write shows you the page names

Reads run straight through. Listing classes, tracing a variable, resolving which template wins on a page: none of that changes anything, so none of it waits.

On writes she stops for your confirmation, and what she shows you is specific. A rename lists the page titles it would touch. A merge tells you how many elements move. A template condition lists the pages it will cover. A bulk operation names every destination page before the first one is written. When a class change hits pages that store CSS in files, she regenerates those files on save.

She also declares how much of the site she has mapped. If her map is 40% complete she says so before answering a question that depends on it, because looking for unused classes against a partial map would flag classes that are very much in use. Ask her to rebuild the map in batches until it is done.

The next session does not start from zero

Lola keeps a picture of your Bricks site and refreshes it daily: how many global classes exist and how many go unused, which variables are defined, the naming convention you agreed on, the framework she detected, component and template counts, and how far she has mapped the site. It lives in your own WordPress database, alongside everything else she remembers.

Open a client site you have not touched in six weeks and that context is already there. You describe the change instead of re-learning the site first.

The addon also registers the lolacore-bricks-system-architect skill and two playbooks: one that walks a blank site from naming convention to tokens, header, footer, templates, and first pages, and one that orients her inside a site somebody else built.

Lola’s lane on Bricks

The same principle as the core: narrow on purpose.

• Custom CSS on global classes and theme styles is saved after a safety check. Bricks code-execution settings stay out of her hands by design, and so do custom JavaScript interactions. She wires the native Bricks interactions instead.
• Images come from your media library, so what she inserts is already yours.
• Bricks is where design decisions get made by hand. Lola takes the work that is long to click and short to say, and the builder stays one click away for the rest.

For agencies and freelancers

Every client site is its own free install with its own memory, its own naming convention, and its own map. One client’s context never reaches another’s.

The 65 abilities register through the WordPress Abilities API, so they are available wherever LolaCore already puts Lola. A designer can work in the WordPress panel while a developer drives the same abilities from an editor, on the same site, with the same memory underneath.

Don’t know what to say? Start here.

“Show me the global classes nothing uses, and which ones do the same job under two names.”

“Rename card-title to card-heading everywhere. Show me the pages first.”

“Clone the hero from /services/branding onto these twenty pages and swap the heading on each.”