Applying Smart Fixes safely

Smart Fixes let you resolve many findings with one click. They’re built to be safe to run on real client sites, nothing changes without a way back.

What happens when you apply a fix

Every Smart Fix follows the same four steps:

1. Snapshot, the affected page’s Bricks data is saved before anything changes.
2. Apply, only the elements you chose are modified. Nothing else on the page is touched. By default that is every element the finding names, and the preview lets you narrow it.
3. Verify, the plugin reads the data back to confirm the change landed as intended.
4. Undo (any time), every fix is reversible from the history panel, which restores the snapshot exactly.

Applying to only some elements

The preview lists the elements a fix would change, each with its own tick box, plus a select all and a select none. Untick anything you would rather leave alone and it is not changed.

The finding then stays open for the elements you left, because there is still work outstanding on it. Nothing drops out of your report as though it had been handled.

Fix types

• Safe auto, low-risk, mechanical changes (for example, swapping a hardcoded color for the matching variable). Safe to apply directly.
• Review, changes where you’ll want to make a choice first (for example, naming a new global class before it’s created). You confirm the details in a preview before it runs.

How risky is this fix?

Some fixes rewrite one element; others delete things or change styling shared across the whole site. The preview says which, in colour, before you commit:

• No banner, an ordinary change, contained to the elements in the finding.
• “May affect your design system” (amber), merging duplicate classes or variables, or extracting a shared global class. These touch things used across many pages, so a wrong call ripples.
• “Potentially destructive” (red), the fixes that delete: unused variables, unused classes, empty wrappers, missing elements. These require you to tick an acknowledgement (“I’ve reviewed these N items and want to remove them”) before the button will run.

Two labels can appear together, and the combination is the honest one to watch for: a fix can be marked “no visual change” and “potentially destructive”. Deleting 27 unused variables changes nothing you can see, and is still permanent. “Unused” is judged from your Bricks content, which can’t see CSS or JavaScript in a child theme or a snippet, so skim the list before applying.

Read-only by default

A new install starts with writing off. You can scan, score and review everything; nothing is written until you decide it should be. The first time you apply a fix, the dialog shows the preview with a “Writing is off” panel and a single Enable writing and continue button, which turns writing on and applies that fix in one action. Existing installs keep writing enabled when they update; the default is for new installs.

The kill-switch

In Settings, the “Allow fixes to modify Bricks data” toggle is the same switch as a hard global control. Turn it off and no fix can write anything, no matter what, useful on production sites where you only want to scan and review.

Version safety

When a new Bricks version is released that the plugin hasn’t been verified against yet, Smart Fixes automatically switch to read-only until we confirm the update is safe. Scans keep working; your data is never modified by an unverified version.

Good practice

• Work on a staging copy for the first pass on any important site.
• Keep independent backups, Smart Fixes snapshot Bricks data, but they aren’t a replacement for a full site backup.