RequireJS using incorrect baseUrl in pre-generated assets when pub is web-root

[miketull]

1. Log into the admin.
2. The buttons in the left side menu do nothing when clicked.
3. Reload the page into the browser.
4. Click on a left side button like Products.
5. Now the page will load.
6. Now click on Customers.
7. The loading indicator will spin indefinitely.
8. Reload the page into the browser.
9. Now the page will load.

This issue might be similar to #2653 and #2559.

Occurred in Chrome version 47.0.2526.80 (64-bit)

[CNanninga]

More clarification on this issue: The crux of this problem is that Magento generates incorrect URLs for the JavaScript files being fetched in certain circumstances.

To reproduce, the environment setup must be such that /pub is being used as the web root directory, and the Magento base URL must be a sub-directory rather than the domain root (e.g., mysite.org/magento).

With this setup, when loading pages in the admin, the URLs generated for JavaScript files persistently include "pub", which is inaccurate. (e.g., http://www.mysite.org/magento/pub/static/adminhtml/Magento/backend/en_US/jquery.js)

Consistently, refreshing the page corrects this, and the JavaScript URLs are correct on the refreshed page load. (e.g., http://www.mysite.org/magento/static/adminhtml/Magento/backend/en_US/jquery.js

[CNanninga]

Clarification on the setup: Using pub as the web root, yet making the base URL a sub-directory, requires soft-linking this sub-directory to pub.

[CNanninga]

Confirmed that this issue actually does occur on sites that are NOT set up with a sub-directory as the Magento root. Production mode seems to be the common factor.

[CNanninga]

The root cause seems to be a moving target, as this is now exhibiting in a site in Default mode as well. I'll update this issue if it is ever evident in Developer mode.

[CNanninga]

Another piece of info of note about the environment in which this is occurring: The setup is PHP-FPM, with Apache running under an "apache" user and the PHP process running under a different user.

[mttjohnson]

Do you have a Base URL for Static View Files set in the database?

Admin -> Store -> Configuration -> General -> Web -> Base URLs -> Base URL for Static View Files

If you don't have one set, you may be able to set the URL path to the static view files to override whatever is causing the /pub/ to be included in URLs. That might be a workaround for the problem.

[davidalger]

Turns out (as I just discovered and passed along to @mttjohnson ;) ) the issue is that when the CLI tool runs to generate static content files, it does not "know" whether or not they will be loaded from / or /pub/ — something which is configured in the index.php file which loads the site. All files at pub/static/_requirejs/*/*/*/*/requirejs-config.js end up generated with /pub/ included in the baseUrl value, resulting in (seemingly) sporadic 404s due to it's inclusion in the URIs which RequireJS uses to load the files. This is also an issue with the built-in documentation system as pub is included in the generated css files (background-url values).

A workaround…

1. Set Base URL for Static View Files to "{{unsecure_base_url}}static/"
2. Remove all pub/static/_requirejs/*/*/*/*/requirejs-config.js files present
3. Re-generate the requirejs-config.js files by running bin/magento setup:static-content:deploy
4. Flush Magento cache, browser cache and varnish cache (if present).

Magento team: There is no way that I can find to tell the deployment tools what the base URI of a site is when generating these. These require.config() calls setting the baseUrl need to be removed from the static config files. On most (all?) pages, one can find this near the top of the DOM:

<script type="text/javascript">
    require.config({"baseUrl":"http://m2.demo/static/frontend/Magento/luma/en_US"});
</script>

Based on a quick debugging session, it (normally at least) runs after the require.config() call in the requirejs-config.js version of the call is executed, overwriting the incorrect config value, allowing everything to work correctly. It would seem that the issue results when this script in the DOM either ends up running first and/or does not exist in some contexts.

[davidalger]

One other note: this issue will not surface in developer mode because the requirejs-config.js files are always regenerated when running in developer mode, resulting in the correct base URL always being there since the version the browser gets is one generated when bootstrapped from the pub/index.php file.