Shopify / cli

Build apps, themes, and hydrogen storefronts for Shopify
https://shopify.dev
MIT License
433 stars 130 forks source link

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

Closed twilson90 closed 1 year ago

twilson90 commented 1 year ago

Please confirm that you have:

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: https://github.com/Shopify/liquid/issues/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 commented 1 year ago

cc @Shopify/theme-developer-tools

mgmanzella commented 1 year ago

@Shopify/theme-code-tools

Arkham commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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[bot] commented 1 year ago

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 commented 1 year ago

Is this still not fixed?

evilzebra-labs commented 1 year ago

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 commented 1 year ago

Hi @hedgehog90 @evilzebra-labs,

I've tried to reproduce this issue on CLI 3.46.0 (released 2 days ago, which includes https://github.com/Shopify/cli/pull/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 commented 1 year ago

@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:

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 commented 1 year ago

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 commented 1 year ago

any news about this?

karreiro commented 1 year ago

Thank you, @evilzebra-labs, for reporting this issue. It has been fixed by https://github.com/Shopify/cli/pull/2105 and will be included in the upcoming CLI release.

jay-aptimized commented 8 months ago

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 commented 4 months ago

Still not fixed.

gi4no commented 2 weeks ago

I have the same issue

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

karreiro commented 1 week ago

👋 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!