Hi guys!
A question rather than a report — I’d like to know which way to build my tooling, so I don’t write a workaround you’re about to make redundant.
Context: 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 into a native Bricks tree. I reported separately that any image tag currently fails the import because map_image_element() writes an unregistered _importImage setting, and I understand that’s being fixed.
My question is about what happens after the fix.
Reading includes/html-to-bricks/element-mapper.php around line 1236, the mapper writes two things for an image:
$bricks_element['settings']['_importImage'] = [ 'url' => $src, 'alt' => $alt ];
$bricks_element['settings']['image'] = [ 'url' => $src, 'isPlaceholder' => true ];
The name _importImage and the isPlaceholder flag both read to me like a planned media-library import step — as if the intent is that the importer downloads the source image into the media library and then replaces the placeholder with a real attachment. Is that the direction?
I ask because the machinery already exists elsewhere in 2.4. bricks/upload-media accepts a remote URL and sideloads it, and includes/abilities/content.php has sideload_from_url() with validate_sideload_url() in front of it. I tested bricks/upload-media with an external URL and it works cleanly — it returns an attachment id, generated sizes, and the file lands in the media library.
So today I can get a proper media-library image in two calls: upload the file first, then write the image element with {"image":{"id":<attachment id>,"url":…,"size":"full"}}. That renders as a native image element with a correct srcset.
The reason I care about the difference: an image element written with an external URL and "external": true renders without any srcset. So on a site built purely through the import, every image would be a single unresponsive file served from wherever the source HTML pointed. For client work that’s not something I’d ship, which is why I currently do the upload separately.
What I’d like to know:
Is the plan for commit-html-css-page-import to sideload images itself once the _importImage bug is fixed? If so I’ll simply pass source URLs in the HTML and let it handle them.
If not, or if it’s further out, would you consider an opt-in flag on the import — something like options.sideload_images: true — that runs each img source through the same sideload_from_url() path and writes an attachment id instead of an external URL? That would make “design in, finished page out” a genuinely single call for pages that have images, which is most of them.
Either answer is fine, I’d just rather build against the intended direction than around it. Happy to test whatever lands.
Thank you!