Bricks bug — page save fails with Cannot access private property Bricks\Assets::$google_fonts_by_family
Hey all, I’m building a site locally using the Local app (by Flywheel/WP Engine), working with Claude (Anthropic’s AI assistant, via an MCP server connected to my WordPress/Bricks site) — and we’re stuck on a bug that blocks saving any page content in Bricks. This happens via the REST API/MCP path, but I’d expect it to affect the builder directly too:
The error repeats identically every time, regardless of content or install — looks like a regression in Bricks itself (version 2.4-beta) in the Bricks\Assets class, likely a visibility change on $google_fonts_by_family to private that some other code path is still accessing directly on every save.
Has anyone else run into this? Is there a fix in a newer build, or is downgrading to the latest stable release the way to go?
We tested a clean save flow with a new page containing Section > Container > H1 and a Google Font applied to the H1, but we could not reproduce the error. The page saved correctly, and the generated CSS also contained the expected Google font output.
This specific fatal error usually means some PHP code is trying to access an internal Bricks property directly:
\Bricks\Assets::$google_fonts_by_family
That property is private, so the next useful detail is the full fatal error stack trace from the server/PHP error log. It should show the exact plugin, theme file, or custom snippet line that is trying to access it.
Please send the full stack trace from wp-content/debug.log or your hosting PHP error log. Also test once with only Bricks active and custom snippets/plugins disabled, if possible, to rule out external code running during save/CSS generation.
Thanks for looking into this — with some help from Claude AI, I dug a bit deeper and found something that should narrow it down.
I enabled WP_DEBUG_LOG and reproduced the error again, then checked debug.log directly. The fatal never shows up there — no “PHP Fatal error: Uncaught Error…” entry, no stack trace, nothing new at all despite the error firing twice.
That tells me this isn’t reaching PHP’s actual fatal-error handler. It’s being caught in a try/catch somewhere and reformatted into the clean error message I’m seeing, before WordPress’s own error logging ever sees it as an uncaught error.
Given that you couldn’t reproduce it through a normal builder save, and that this is only happening through my MCP integration (a WordPress Abilities API adapter that exposes Bricks functionality as callable “abilities” for an AI agent), it looks like the code sits in that adapter layer — something there is probably reaching into Bricks\Assets::$google_fonts_by_family directly (reflection or similar) instead of going through a proper public accessor, and that access fails before the request ever reaches Bricks’ normal save/CSS-generation path.
So this looks like it’s not a Bricks core bug after all — sorry for the noise. I’ll chase it from the adapter side instead. Thanks for confirming the clean flow works on your end, that was the piece I needed.
i just came across this same issue also when testing MCP abilities.
It seems to only happen when certain abilities are called, (Site Changeset, Agent File, Site Edit Plan) which use render_candidate() which is where this fails as it loops though all the Assets including google_fonts_by_family.
It’s not reproducible through a normal Builder UI save, or through the other common abilities like add-element or update-element, as they don’t use the render_candidate.
