This issue might be similar to #2653 and #2559.
Occurred in Chrome version 47.0.2526.80 (64-bit)
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
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.
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.
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.
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.
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.
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…
pub/static/_requirejs/*/*/*/*/requirejs-config.js files presentbin/magento setup:static-content:deployMagento 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.
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.
Not actual any more. Reviewed on 2.0 (c946f29dd89ddc45337ea2a1b0d8f79e59b4bab6) and develop (798a8420e5738ceb5f2dcb332a59c7ee60b83444) branches.
Now baseUrl parameter exists in page source code. So for any particular _Store view_ it could be changed on the fly. Only flush caches is needed.
@guz-anton Thanks for the update! Seems your team fixed it in MAGETWO-47054 which went out in the 2.0.1 release:
dalger:10:17 AM:/sites/m2.dev (develop) $ git checkout -q 2.0.0
dalger:10:18 AM:/sites/m2.dev ((2.0.0)) $ rm -rf var/{cache,di,generation,page_cache} pub/static/_requirejs/*/*/*/*/requirejs-config.js
dalger:10:19 AM:/sites/m2.dev ((2.0.0)) $ magento -q setup:static-content:deploy
dalger:10:20 AM:/sites/m2.dev ((2.0.0)) $ grep baseUrl pub/static/_requirejs/*/*/*/*/requirejs-config.js
pub/static/_requirejs/adminhtml/Magento/backend/en_US/requirejs-config.js:require.config({"baseUrl":"http://m2.dev/pub/static/adminhtml/Magento/backend/en_US"});
pub/static/_requirejs/frontend/Magento/blank/en_US/requirejs-config.js:require.config({"baseUrl":"http://m2.dev/pub/static/frontend/Magento/blank/en_US"});
pub/static/_requirejs/frontend/Magento/luma/en_US/requirejs-config.js:require.config({"baseUrl":"http://m2.dev/pub/static/frontend/Magento/luma/en_US"});
dalger:10:20 AM:/sites/m2.dev ((2.0.0)) $ git checkout -q 2.0.1
dalger:10:21 AM:/sites/m2.dev ((2.0.1)) $ rm -rf var/{cache,di,generation,page_cache} pub/static/_requirejs/*/*/*/*/requirejs-config.js
dalger:10:21 AM:/sites/m2.dev ((2.0.1)) $ magento -q setup:static-content:deploy
dalger:10:22 AM:/sites/m2.dev ((2.0.1)) $ grep baseUrl pub/static/_requirejs/*/*/*/*/requirejs-config.js
dalger:10:22 AM:/sites/m2.dev ((2.0.1)) $
P.S. It would be awesome if you guys could find the ticket number that resolved a "no longer broken" issue on GitHub and post it vs just a generic "no longer reproducible message" — it would be helpful to all of us, especially when tracking or trying to correlate fixed issues (via search on GitHub)! :)
@davidalger agreed. Will keep in mind next time.
Most helpful comment
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 atpub/static/_requirejs/*/*/*/*/requirejs-config.jsend up generated with/pub/included in thebaseUrlvalue, 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 aspubis included in the generated css files (background-url values).A workaround…
pub/static/_requirejs/*/*/*/*/requirejs-config.jsfiles presentbin/magento setup:static-content:deployMagento 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:
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.