[Bug]: Images don't load with new CDN URL in theme dev environment (shopify theme dev)

[twilson90]

Please confirm that you have:

• Searched existing issues to see if your issue is a duplicate. (If you’ve found a duplicate issue, feel free to add additional information in a comment on it.)
• Reproduced the issue in the latest CLI version.

In which of these areas are you experiencing a problem?

Theme

Expected behavior

New CDN URLs are being implemented for some Shopify stores it seems.

All images and asset URLs generated by the appropriate liquid filter used to have a prefix like:
//cdn.shopify.com/s/files/.../products/
But now, for some stores, they're like this:
/cdn/shop/products/

This brings with it additional problems which are already affecting many stores I've checked. I've detailed them in a separate issue in the Shopify Liquid repo, which gets little to no attention it seems:
Shopify/liquid#1708
If someone could get the attention of someone who can help, please link them to this issue.

However, this issue is specifically regarding the image assets loaded in shopify-cli dev.
A new CDN image URL looks like this:
/cdn/shop/files/the-name-of-your-image.jpg
Which the browser resolves to:
http://127.0.0.1:9292/cdn/shop/files/the-name-of-your-image.jpg
It would appear localhost will serve a 200 response but invalid image data so no image loads.
I've confirmed that some other theme devs have started experiencing this within the last 1-2 days.
However other assets like JavaScript and stylesheets and the like are served correctly through the new CDN URLs.
The only way to fix it currently is to prepend every image_url output with shop.url

Actual behavior

Images don't load.

Verbose output

-

Reproduction steps

You need to have a Shopify store that uses the new CDN URLs. It seems most stores are still using the old CDN URLs as mentioned earlier.

Operating System

Windows 11

Shopify CLI version (check your project's package.json if you're not sure)

3.45.1

Shell

No response

Node version (run node -v if you're not sure)

No response

What language and version are you using in your application?

No response

[amcaplan]

cc @Shopify/theme-developer-tools

[mgmanzella]

@Shopify/theme-code-tools

[Arkham]

hey @hedgehog90 thanks for reporting this, we have a team working on this. They've identified the root cause of the problem and are working on a fix.

[twilson90]

@Arkham Not sure if this is related to the bug, but if I try and load a section containing images with a ?sections=... AJAX call, all the images come back as //cdn.shopify still.
It's been 2 days since I first noticed the bug, is the AJAX call returning a cached response? If so, why is the cache not getting cleared after a sufficient time? Or is this also a bug?

[evilzebra-labs]

Hey @hedgehog90 thanks for reporting this, we have a team working on this. They've identified the root cause of the problem and are working on a fix.

btw, this affects all CDN files, including google fonts, etc.

[github-actions]

This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action.
→ If there's no activity within a week, then a bot will automatically close this.
Thanks for helping to improve Shopify's dev tooling and experience.

P.S. You can learn more about why we stale issues here.

[twilson90]

Is this still not fixed?

[evilzebra-labs]

Is this still not fixed?

@hedgehog90 no it isn't. I am still waiting for this solution so that I can continue with some changes to my project, as this is affecting the loading of some dependencies in the local environment.

@Arkham any update on this? you said the dev team was working on this, almost a month ago.

[karreiro]

Hi @hedgehog90 @evilzebra-labs,

I've tried to reproduce this issue on CLI 3.46.0 (released 2 days ago, which includes #1862) and can no longer reproduce the problem.

If you're still facing this issue on 3.46.0, could you please run shopify theme dev --verbose and share any request_id that appears? (with that information, I can get extra details about the issue).

Thank you for reporting this.

[evilzebra-labs]

@karreiro thanks for the fast response...
I've no time to make a thorough test right now, as I'm working on several projects, and only one is having this odd behavior.

but I've made this:

• Upgraded Shopify CLI to version 3.46.0,
• run shopify theme pull --store={store-name} (for the store that is not working properly on the local environment)
• run shopify theme dev --verbose

and received the following request ids in the console:

request_id: 1ab99189-6d5f-4e2b-9e7c-22ebb6e6b918
request_id: 7f785cbd-5c05-40d7-9e29-b6102c65e3bf
request_id: a73aaf93-b305-4eb2-b8f2-8ab6ec9f3614
request_id: e22f43aa-1f96-4689-bdc6-d75dda4d770e
request_id: 0b23b20d-20e4-4198-abdb-87804e8ecaf3
request_id: e1b5f763-9e76-4bba-844e-03971d39e0b3
request_id: aff5df63-c837-4e04-8003-dfb39e2673b2
request_id: e3776da6-63d8-4c17-be11-55263857f99c
request_id: 5bc02198-3dff-48c7-bce5-e01c49c20558
request_id: 57aa18b1-98d6-4a17-abd7-7cac4dca66b4
request_id: 9a9c79ee-91d8-47d9-9416-d1d8398ae869
request_id: 9f0dedc6-b67c-4f94-9659-23cdb166af69

Besides that.... loading the dev site on the browser, only throw a bunch of
net::ERR_ABORTED 404 for any file in the /assets/ folder
net::ERR_FAILED 401 for files in /cdn/fonts folder

this store is using the Dawn theme.

all the network requests to these assets.. have the following URL format:
http://{my-store-url.com}/assets/theme-styles.css?v=xxxxx
you can notice there is no /s/files/xxx in the urls

---

I've made a test on another store, which uses a custom-made theme...
and all the assets files are coming from URLs like:
http://cdn.shopify.com/s/files/1/0406/5548/7128/t/24/assets/theme-styles-responsive.css?v=35571516464545666981684416532

and they are working just fine

Not sure if this information will help you find the root cause...

Later today, I'll try to clear the repo and start fresh.. to check is not a problem with the file structure

[evilzebra-labs]

quick update, I've deleted the complete folder.. and made a new "theme pull" for the store that is not working..
and the behavior is exactly the same

[evilzebra-labs]

any news about this?

[karreiro]

Thank you, @evilzebra-labs, for reporting this issue. It has been fixed by #2105 and will be included in the upcoming CLI release.

[jay-aptimized]

We've encountered a significant increase in 404 errors correlating directly with the appearance of /file/ in the URL paths across our Shopify site. Initially, our logs indicated a minor number of 404s, but following recent changes, these have escalated dramatically, specifically after /file/ was introduced into the URL structure. While Shopify CDN URLs containing /file/ are resolving as expected, any attempt to access URLs with /file/ on our actual site results in a 404 error.

This issue suggests there might be a routing or path resolution problem within the Shopify environment when /file/ is included in the URL path. It's unclear whether this is due to a recent update or a change in the way Shopify handles static assets or URL routing. We have verified our theme and asset configurations to ensure no unintentional changes have been made that could contribute to this issue.

Any insights or suggestions on how to resolve these unexpected 404 errors would be greatly appreciated. Is there a known issue with the handling of /file/ in URLs, or could there be a specific configuration required to support this path structure without resulting in 404s?

[gecevicius]

Still not fixed.

[gi4no]

I have the same issue

@karreiro x-request-id: 9539ca8a-2a23-4a91-98ad-bb2ddad282ac

[karreiro]

👋 Hello everyone,

Thank you for reporting.

If you still facing this issue in the latest version of Shopify CLI (3.69.3). Please, report a new issue including your --verbose output.

The legacy image proxy component has been replaced in September (after this issue was closed), so if you're still experiencing a similar scenario today, it's different problem than the one originally reported as we're not relying on the same implementation today, so sharing your --verbose output is really important.

Thanks again for reporting!