# Will the fixed image import sideload into the media library, or should I keep chaining upload-media?

**URL:** <https://forum.bricksbuilder.io/t/will-the-fixed-image-import-sideload-into-the-media-library-or-should-i-keep-chaining-upload-media/40295>\
**Category:** How To\
**Created:** [September 15, 2026, 11:35am UTC](https://forum.bricksbuilder.io/t/will-the-fixed-image-import-sideload-into-the-media-library-or-should-i-keep-chaining-upload-media/40295 "2026-09-15T11:35:23Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![roundedhexagon](https://forum.bricksbuilder.io/user_avatar/forum.bricksbuilder.io/roundedhexagon/32/3136_2.png) [@roundedhexagon](https://forum.bricksbuilder.io/u/roundedhexagon)\
**Post date:** [September 15, 2026, 11:35am UTC](https://forum.bricksbuilder.io/t/will-the-fixed-image-import-sideload-into-the-media-library-or-should-i-keep-chaining-upload-media/40295/1 "2026-09-15T11:35:24Z")

</div>

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:

```php
$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!