Bricks Builder

Bricks remains first-class

WPChangeSync grew out of BricksSync, and Bricks still has deep coverage. WPChangeSync includes handlers for Bricks templates, components, settings, global classes, global elements, global queries, theme styles, colors, typography, breakpoints, variables, custom code, custom CSS, custom fonts, custom icons, icon fonts, sidebars, element defaults, element manager, style manager, pseudo classes, and Adobe fonts.

Optional dependency

Bricks is no longer required for the plugin to run, and Bricks integrations only appear when the relevant Bricks data exists on the site. In a builder-agnostic install the WordPress and third-party integrations behave exactly the same.

When Bricks is active, these extras become available:

• Templates, including headers, footers, sections, and content templates.
• Components, the saved element groups you reuse across templates.
• Bricks Settings and Global Styles: global CSS classes, the colour palette, and theme styles.
• Template version history, with rollback.
• Element-level batching, for very large templates.
• A builder panel inside Bricks itself.

Template and component moves

Use the Library to export selected templates and components, push them to a remote, or include them in a workflow. Every Library section shows the site item and its storage file side by side, so you can see what would change before you move anything.

Versioning and rollback. WPChangeSync snapshots a template at the moments that matter: when you save it in Bricks, before an import overwrites it, and when you export it. Open the version history from the clock icon next to a template name, then Restore any entry. Your current state is snapshotted before the restore runs, so restoring is itself reversible.

Global styles. Classes and theme styles can move on their own from the Global Styles section, or ride along with a template import by ticking the option to include global styles. When a class already exists on the target you can skip it, overwrite it, or merge, and merging is the usual choice when the target has site-specific colour overrides worth keeping.

Media, logos and fonts. When you push templates from a local site, or with Include media ticked, the images they use travel with them and are reconnected on the destination. That covers Image, Logo (including the inverse logo), SVG, Audio and Video elements, background images, galleries, image masks and map markers. Custom fonts sync as part of Global Styles, including the font files themselves. On a WPML or Polylang site, each translated template is synced and linked as its own language version.

SVGs. The receiving site must allow SVG uploads for the user your remote connection signs in as (in Bricks: Settings, SVG uploads for that role). Imported SVGs are cleaned by Bricks' SVG sanitizer, exactly like an upload. If the receiving site doesn't allow SVGs, the push notice lists the files that were refused.

Deploying a rebuild onto a live site. Rebuilt a site in Bricks on staging? Use the Deploy a Bricks rebuild workflow template, or tick Bricks layout only when pushing pages. Pages that already exist on the live site keep their own title, text, status, terms and custom fields and only take the new Bricks layout; pages the live site doesn't have are created in full. Products, orders and customers are never touched. Check the preview first, and use Undo last push if anything looks wrong.

Reference checklist

Bricks-oriented automation can be driven entirely from WP-CLI: listing, exporting, and importing templates and components, plus the versioning and restore flows. That makes a Bricks release reproducible from a deploy script rather than clicked by hand.