I generate pages programmatically through the 2.4 abilities: my tooling writes semantic HTML and CSS, and bricks/commit-html-css-page-import converts it to a native Bricks element tree. Table and iframe elements convert to a code element, and that makes the entire import fail:
bricks_conflict_code_sensitive_import_blocked
The converted source contains code-sensitive elements that this user cannot persist.
elementKinds: [{ "id": "…", "name": "code", "sensitiveKinds": ["code"] }]
Environment: Bricks 2.4-rc2, WordPress 7.1, PHP 8.3.30, through the Abilities API.
To reproduce, import any page whose HTML contains a table or an iframe. In my case a seventeen-element page was discarded because of one comparison table.
I understand why code elements are restricted through abilities. What surprised me is that it applies to administrators too — I tested the same import as a real administrator and got the identical block, because the restriction reads as “cannot be persisted through Bricks abilities” rather than as a capability check. So there’s no user who can push it through.
There’s also no way to work around it in the call itself. options.custom_css_policy only offers allow and forbid, and forbid just rejects earlier rather than doing anything different with the offending elements.
What would help: either a mode that skips code-sensitive elements and reports which ones were skipped, or a per-element fallback to an empty native container. Either way one unsupported tag wouldn’t discard an otherwise valid page. At the moment the only workaround is to know in advance which tags to strip from the source.
Since this reads as a complaint otherwise, I want to add that the converter is genuinely good and most of my assumptions about its limits turned out to be wrong. On the HTML side, headings, paragraphs, lists including nested markup inside list items, article, span, strong, links, buttons, blockquote and forms with inputs all map to native elements. Inline SVG works too, which I didn’t expect.
On the CSS side I couldn’t find anything at all that falls back to custom code. Descendant and child combinators, compound selectors, clamp(), calc(), min(), grid with grid-template-columns, flex with gap and flex-wrap, aspect-ratio, gradients, transitions, box-shadow, :root custom properties (which become global variables), media queries, ::before with content, and :hover all came through as native settings or global classes. That’s a far wider net than I assumed when I started, and it means there’s no reason to simplify CSS before importing.