Exporting an HTML card to WordPress > Bricks Builder (export_mode: elements) always fails when the source HTML contains an <img> tag, regardless of whether the image is an external URL or already hosted on the target WordPress site's own media library. The server-side conversion appears to generate an internal placeholder settings key (_importImage) meant to be resolved into a real Bricks 'image' setting (with a WP attachment id/url) before the element tree is persisted via the Bricks Abilities API, but that resolution step never happens — the raw placeholder key is sent straight to the Bricks save call, which rejects it as an unregistered setting for the image element.
Steps to reproduce
1. Create/open an HTML card containing a <section> with a background <img src="…"> plus other markup.
2. Configure a WordPress site with Bricks 2.4+, Abilities API enabled, Bricks AI setting on, live export available (confirmed via POST /api/bricks/sites/{site_id}/probe → liveExport: true).
3. Export the card via POST /api/bricks/export with export_mode: "elements", targeting an existing page.
4. Reproduced twice: once with the <img> pointing at an external (non-WordPress) URL, once after re-hosting the exact same image in the target site's own WP media library and updating the HTML to reference that local WP URL. Both attempts fail identically.
Expected
The image import placeholder should be resolved server-side (upload/attach the image to the WordPress media library and rewrite the element's settings to the real Bricks 'image' object with id/url) before the element tree is persisted, so the export succeeds and the image element renders correctly in Bricks.
Actual
POST /api/bricks/export (export_mode: elements) returns HTTP 500 with a Bricks Abilities API validation error rejecting the unresolved placeholder key, both for an external image URL and for an image already hosted on the target site's own media library.
Error output
{"detail":"Invalid value for "settings._importImage". Expected a registered setting for the 'image' element. | data: {"code":"bricks_invalid_param","param":"settings._importImage","expected":"a registered setting for the 'image' element","received":"_importImage"}"}
Context
Feature area: HTML card export to WordPress/Bricks Builder (POST /api/bricks/export, export_mode: elements). Element type: image (background <img> inside a hero section). Workaround found: POST /api/bricks/generate-file (plugin-free fallback) does not hit this bug — for the same HTML it falls back to a single Code element template (with a warning that native element conversion needs a connected Bricks site), which imports fine manually via Bricks > Templates > Import. The export_mode: "code_block" path via POST /api/bricks/export was also tried as an alternative but is separately blocked by a (correct, unrelated) permission check: bricks_code_sensitive_write_forbidden, since the site does not have unfiltered_html/Execute Code authorized for Abilities API writes.
Environment
App version: 10.5.5
Platform: Windows 11 (AMD64)
Response