When using Claude Code for editing a Bricks website it reordered the contents on several pages, leaving the pages’ contents restructured on the wrong sequence. Post titles, dates and buttons all moved. Across a 9-page site, every page written through MCP was affected.
Here are the details:
MCP writes silently reorder a page: children is rebuilt from flat array order on save
Environment
| Bricks | 2.4-beta2 |
| WordPress | 7.0.2 |
| MCP Adapter | 0.5.0 |
| Client | @automattic/mcp-wordpress-remote |
Summary
Saving through any Bricks MCP write ability rewrites each element’s children array to match the order in which elements appear in the flat _bricks_page_content_2 array. In builder-authored data those two orders routinely disagree — the flat array reflects creation/edit history, while children holds the real layout order. When they disagree, the save discards the correct order and the page silently re-renders in the wrong sequence.
The damage is not limited to the element being written. A single bricks/update-element call changing one text string reorders every container on the page whose children order differs from flat order.
This is silent data corruption on existing sites. Nothing in the response indicates the tree was restructured.
Evidence
Real page, before any MCP write. Revision 711 stored:
{ "id": "uzinov", "children": ["srbwyp", "pqkveh", "qvszzs"] }
but in the same revision, the flat array listed qvszzs at index 5 and srbwyp / pqkveh at indices 28 / 29 — because the description element was created first and the image added later. The frontend correctly rendered image → footnote → description, following children.
A bricks/batch-update-elements call was then made. It touched only settings.text on unrelated elements, plus query.objectType on uzinov. Afterwards:
{ "id": "uzinov", "children": ["qvszzs", "srbwyp", "pqkveh"] }
children now equals flat order, and the frontend renders description → image → footnote. The artwork caption moved above the artwork.
On the same page the same save also reordered:
| Container | Before | After |
|---|---|---|
uharti |
losfiw, eitpdv, nqhzdm, latcnp |
eitpdv, latcnp, nqhzdm, losfiw |
nqhzdm |
fbjecc, hqywma |
hqywma, fbjecc |
juqnqj |
yjegum, mtdvbq |
mtdvbq, yjegum |
Post titles, dates and buttons all moved. Across a 9-page site, every page written through MCP was affected.
There is a hint in the dry-run response, but it is easy to miss and does not say what changed or that it is destructive:
"normalization": { "uzinov": { "changed": true, "changedFields": ["children"] } }
Steps to reproduce
- In the builder, create a container with element A inside it.
- Add element B, then drag B above A in the structure panel. Save.
The flat array is now[A, B]whilechildrenis["B", "A"]. The frontend correctly shows B then A. - Through the MCP server, call
bricks/update-elementon any element of that page — for example change a heading’stext. Do not touch the container. - Reload the frontend.
Expected
Only the requested setting changes. Layout order is untouched.
Actual
The container’s children is rewritten to ["A", "B"] and the frontend now renders A then B. The change is permanent and silent.
Why it is hard to notice
bricks/get-page-structure builds its tree using flat-array position rather than the stored children array. Before the write it therefore already reports the wrong order, and after the write it reports the same thing — so reading the structure before and after a save shows no difference, while the rendered page has in fact changed. Verifying a write with that ability cannot detect this bug.
bricks/get-page-elements returns the true children arrays, and bricks/get-revision can be used to recover the pre-write order.
Suggested fix
Treat children as the source of truth for order, and rebuild the flat array from it — not the other way round. If a normalization pass must run, it should reorder the flat array to match children, which is lossless.
Until then, it would help a great deal if normalization.changedFields containing children produced an explicit warning in the response, naming the containers whose order changed.
Workaround
bricks/set-page-elements, passing every element in correct depth-first order and with correct children arrays, restores the layout. Once flat order and children agree, subsequent MCP writes are harmless. Saving the page once from the builder has the same effect, since the builder writes both consistently.