Skip to content
cwp

Bricks integration

shipped 1.0.0

The cycle these commands sit in is the build loop; this page is what is different about it on a Bricks project.

On a Bricks project, cwp db pull runs three best-effort steps after the import. A failure warns; it does not abort the pull.

  • Regenerate code signatures. Bricks signs code elements per site, so imported content stays blocked until it is re-signed. There is no official WP-CLI command for this yet, so cwp checks whether one exists and otherwise tells you to regenerate under Bricks → Settings → Custom Code → Code signatures.
  • Regenerate CSS, when the site uses external CSS files.
  • Report the licence state. Bricks is licensed per site and your local install may need its own activation. cwp reports it; it does not try to fix it.

The child theme is yours to pick

cwp’s author wrote it against SNN-BRX, and cwp has no opinion about it. The integration is with Bricks. The child theme is a preference, and any child of Bricks works: your own, somebody else’s, or none at all with Bricks active directly.

Two places it shows up:

  • cwp init detects it by reading Template: bricks out of the style.css headers under wp-content/themes, records it as builder.options.child_theme, and names that theme in the CLAUDE.md and site-plugin README it generates. With no child theme installed it names none and states the grandchild-theme rule on its own, the part that is true regardless.
  • The scrub’s log post types are SNN-BRX’s: that list came off a running install. A project without SNN-BRX gets an empty list rather than eight names that mean nothing on its stack.

cwp doctor warns when builder.options.child_theme and the theme on disk disagree. That catches a child theme somebody installed and never activated.

Bricks 2.4 and the abilities

From Bricks 2.4, cwp drives Bricks’ own documented abilities rather than reading its database. cwp bricks is that surface: the design-system round trip, the MCP client wiring and the builder-enabled post types.

Three things about it that are not obvious:

  • The MCP Adapter plugin is not required for cwp. Bricks registers its abilities on WordPress core’s Abilities API, so WP-CLI reaches all of them with nothing installed beyond Bricks. The adapter is what exposes them over HTTP to an AI client, so only cwp mcp needs it.

  • Ability calls run as a WordPress user: builder.options.wp_user in the configuration reference.

  • BRICKS_DISABLE_MCP pins the AI surface off per environment, from wp-config.php, and there is deliberately no force-on counterpart. cwp reports it as state, never a fault.

    What it does warn about is the inverse: an environment you marked protected whose Bricks AI surface is still on. In that combination an AI client can write to production. Nobody notices it, because everything works.

Two constants Bricks 2.4 adds are worth knowing and belong only in a local wp-config.php: BRICKS_DANGEROUSLY_AUTO_SIGN_CODE_ON_BUILDER_SAVE and its ..._ON_BUILDER_RERENDER counterpart remove the code re-signing chore locally. The name is a warning. define( 'BRICKS_LICENSE_KEY', … ) makes licensing a deployment concern rather than a per-install click.

Custom post types belong in the site plugin

Register them in code, under plugins/<name>-site/inc/post-types/ on init. Not with a post-type UI plugin, not with the child theme’s post-type manager, not with custom-field post types.

The reason is the one the whole tool rests on: the database only ever flows downward. A post type defined in the database lives in wp_options or wp_posts, and there is no upward path for a whole database. A post type is structure, and structure travels with your code, via cwp deploy.

cwp.yml is not the place either. It configures cwp, not your site. Its one post-type setting, pull.truncate_post_types, is about deleting log entries.

You do not need to write the registration boilerplate by hand:

cwp wp -- scaffold post-type buch --plugin=example-site --label="Bücher"

To see which post types a site registers, read the definitive answer from a live install rather than from your code:

cwp wp --env prod -- post-type list --format=json

And remember cwp bricks post-types: a registered post type still will not open in the builder until it is in Bricks’ own list, with nothing anywhere saying why.

Code signatures and the salts

Bricks signs every code element, component property and global query with wp_hash. WordPress keys that hash with the AUTH_KEY and AUTH_SALT of the install. Two environments with the same two salts accept each other’s code on arrival. Two with different salts do not: after a push, every signed piece of code on the target stays unsigned until somebody regenerates the signatures under Bricks → Settings → Custom Code → Code signatures. No command does it; cwp pull prints the instruction after the import.

A local DDEV site gets its own salts from wp-config.php. The regeneration is therefore part of every pull that brings code down. On two hosts you control, sharing the two salts is a deployment choice that removes the step.