Venia does not use store configuration base URLs

[ericerway]

Configuration of media directories can vary between installations of Magento, but the Venia Concept storefront is strongly opinionated that you're using /pub as your document root. We should instead infer media urls from the below GraphQL query, and update venia-upward.yml and util/makeUrl.js to be more flexible when detecting and proxying media requests.

query {
  storeConfig {
    secure_base_media_url
  }
}

This issue is for the following packages:

• [x] venia-concept
• [ ] pwa-buildpack
• [ ] peregrine
• [ ] pwa-devdocs
• [ ] upward-js
• [ ] upward-spec

This issue is a:

• [x] Bug
• [ ] Feature suggestion
• [ ] Documentation issue
• [ ] Other (Please Specify)

Expected result:

Only changing the MAGENTO_BACKEND_URL environment variable, Venia should support serving media from Magento instances using /pub or / as their document root. This can also be customized via the admin, so we should also support custom values, ie. {{secure_base_url}}my/media/path/ entered in Secure Base URL for User Media Files.

[milanstojanov90]

Hello, as a reporter of this bug on Twitter, I'm glad to provide more details on this.

Environment

OS: Mac OS X Mojave NodeJS version: v8.12.0 npm version: 6.4.1

Installation

In my local web root /usr/local/var/www/magento23 I have 2 folders:

• pwa-studio v1.1 (cloned from https://github.com/magento-research/pwa-studio.git)
• pwa-studio-backend (Magento 2.3.0 installed through composer + Venia sample data), available on http://dev.pwastudio.com

In my /usr/local/var/www/magento23/pwa-studio/packages/venia-concept/.env file I have updated only this: MAGENTO_BACKEND_URL="http://dev.pwastudio.com/"

Run the server

CMS Page (note the port is 10000, the same is if I change URL and type 8049)

Category Page

Product Page

Checkout

Note how the error is not displayed on the frontend. It's shown in the developer tools though. Whatever I type here, I can't see the "Save" button enabled. It always stays disabled.

[deepanshu27193]

Same Here.

Only thing I changed is: MAGENTO_BACKEND_URL="http://127.0.0.1/magento23pwa/"

[ericerway]

Thanks for all the great details. I'll defer the troubleshooting to @zetlen -- but had one question, does this happen with the example M2.3.0 cloud instance in .env.dist as well or just the updated MAGENTO_BACKEND_URL?

[milanstojanov90]

Yes, it does! Because it took me a long time to figure out the installation process, at some point I tried with the default MAGENTO_BACKEND_URL, but the results were the same.

[ericerway]

Got it. Thanks for clarifying, we'll take a look. 👍

[deepanshu27193]

At my end, It's working perfect with the default cloud URL. Only changing the MAGENTO_BACKEND_URL to local codebase gives the problem.

I have found the code which is expecting Magento to be hosted from the pub directory rather than from the root directory. Issue is at: https://github.com/magento-research/pwa-studio/blob/release/2.0/packages/venia-concept/src/util/makeMediaPath.js#L19

Solution: Create a virtual host and point it to the pub directory instead of the root directory.

Now no more 404 on category and product images. Everything seems to be working now.

[tjwiebell]

@zetlen

There are two problems here that I think can be easily resolved.

1) venia-upward.yml assumes requests for media/ should just proxy to env.MAGENTO_BACKEND_URL, which breaks if your instance is not using /pub as your document root. As @deepanshu27193 pointed out, updating M2 server config resolved their problem. I think we can just document how to configure Venia to match your M2 configuration; split out that response rule and proxy to a mediaProxy target instead (env.MAGENTO_BACKEND_URL + /pub).

2) Validation for state field in shipping form doesn't bubble up to the user. Depending if we have UX mockups for validation, I think we just need to better indicate form validation errors, or better yet; just change the input type.

If there's a preferred path to resolution here, please update the ticket, and I'm available to resolve if you want to re-assign.

[tonai]

I got the same problem when trying to use my local instance of Magento.

I updated the venia-upward.yml and updated the pattern for the proxy with ^/(graphql|rest|media|pub/).

And I added in my .env file:

MAGENTO_BACKEND_MEDIA_PATH_PRODUCT="/pub/media/catalog/product"
MAGENTO_BACKEND_MEDIA_PATH_CATALOG="/pub/media/catalog/category"

[Nastradoomus]

So this is the problem:

.env file default: MAGENTO_BACKEND_PRODUCT_MEDIA_PATH="/media/catalog/product" MAGENTO_BACKEND_CATEGORY_MEDIA_PATH="/media/catalog/category"

Should be: MAGENTO_BACKEND_MEDIA_PATH_PRODUCT="/pub/media/catalog/product" MAGENTO_BACKEND_MEDIA_PATH_CATALOG="/pub/media/catalog/category"

[zetlen]

Long overdue, but:

• Thank you @mageclass for reporting this, to @deepanshu27193 @tonai and @Nastradoomus for validating and researching it, and to @tjwiebell for accurately identifying the issue.
• @tjwiebell It's already a known best practice to configure /pub as document root, so we could easily document that by linking to it.
• I think we can avoid hardcoding the media path altogether, by using the storeConfig GraphQL query in the server side render. Correct me if I'm wrong, but Magento should detect when its document root isn't pub, and should prepend pub to all its URLs. That should also be reflected in the GraphQL prefix!

Suggestion: Let's rename this issue "Venia does not use store configuration base URLs" and welcome efforts from our community members to integrate a storeConfig query into the UPWARD server-side render.