setup:static-content:deploy does not create all the required static assets

[keithbentrup]

Steps to reproduce

1. install m2
2. set base_static_url
3. deploy static assets
4. search pub/static for the file "requirejs-min-resolver.min.js"

I created a docker image to reproduce this issue. All the details and a test image can be found here:
https://github.com/esepublic/docker-m2-install-tests/tree/missing-static-files

Once the image is up, you can access the storefront at your BASE_URL, but before you do,
search /magento2/pub/static for 'requirejs-min-resolver.min.js'. It will not exist
but is required by the storefront.

Visiting the storefront will create the url, but this does not help when the static files
are remotely deployed.

[mazhalai]

@keithbentrup thank you, we have created MAGETWO-50847 to investigate and fix.

[maderlock]

Any progress on this? We've been clearing pub/static before deploying static content because there does not seem to be any guarantee otherwise that all files will be correctly recreated. However, sometimes we are missing requirejs resolver files. How and when are these supposed to be created? Should we be avoiding deleting them?

[veloraven]

This issue should have been fixed already in develop branch.
@keithbentrup what version was this issue created for?
@maderlock what version do you use?

[maderlock]

I'm using 2.1.0. I've started adding the environment variable https=on before my calls, which helps.

[kamleshyaduwanshi]

I am facing similar issue, any update on this?

[sshymko]

Suffering the same issue. The static content deployment command does NOT create the file pub/static/adminhtml/Magento/backend/en_US/secure/requirejs-min-resolver.min.js. Instead, it's being created in run-time upon requests to the admin panel.

[kamleshyaduwanshi]

Run the following commands:-

php bin/magento setup:upgrade
php bin/magento setup:di:compile
sudo chmod -R 777 var pub
php bin/magento setup:static-content:deploy

I hope the issue will be resolved.

[sshymko]

@kamleshyaduwanshi,
No, the issue is reproducible after running the provided commands (ordinary deployment sequence).

The workaround above by @maderlock works perfectly:

export HTTPS=on
php bin/magento setup:static-content:deploy

[hostep]

Possible duplicate for @sshymko's issue: #4961
Not sure if this is the same issue as reported by @keithbentrup though.

[siliconalchemy]

@kamleshyaduwanshi Please, don't ever advise people in public to chmod 777.

@maderlock @sshymko Thanks very much, your 'export HTTPS=on' workaround works perfectly.

@veloraven Has this issue been fixed in the developer branch, yet a year on still hasn't made it to a public release? It's really incredible how many major, fundamental problems are in Magento that are fixed yet spend months and months and months waiting for the fixes to actually reach a release. Is this a deliberate policy, perhaps, to make the free/opensource versions buggy?

[korostii]

Is this a deliberate policy, perhaps, to make the free/opensource versions buggy?

As Hanlon's razor states, "Never attribute to malice that which is adequately explained by stupidity". May I assure that to the best of my knowledge, the source code of EE version is just as buggy (at the very least, the parts shared have identical sources in corresponding versions).

However, there seems to be an internal policy which forces developers to fix issues on 2.2.0 branch first and backport the fixes only if requested by community. Which means that a lot of the fixes aren't released for 2.1.x and 2.0.x at all, for months straight.

I would then speculate that this is done deliberately in order to provide the "carrot" that will force the merchants to invest the workforce into migrating to 2.2.0 shortly after its release. I don't see any other sane (read: "rational") reason to deliver fixes in this manner.

But then again, it might be some plain old bureaucracy slowing down the process without aiming to do so.

[siliconalchemy]

As Hanlon's razor states, "Never attribute to malice that which is adequately explained by stupidity". May I assure that to the best of my knowledge, the source code of EE version is just as buggy (at the very least, the parts shared have identical sources in corresponding versions).

However, there seems to be an internal policy which forces developers to fix issues on 2.2.0 branch first and backport the fixes only if requested by community. Which means that a lot of the fixes aren't released for 2.1.x and 2.0.x at all, for months straight.

I would then speculate that this is done deliberately in order to provide the "carrot" that will force the merchants to invest the workforce into migrating to 2.2.0 shortly after its release. I don't see any other sane (read: "rational") reason to deliver fixes in this manner.

Eloquently put :) If that's the case, it's a spectacularly stupid policy given the evident timescales involved and the magnitude of the bugs - it just makes Magento appear to be a heap of bugs that are never resolved. Fixing them all in the next major release is all very well, but that release will no doubt have it's own round of bugs from new features which will take a while before it's stable enough to use in production, not to mention the lead time for extensions to be upgraded etc. Seeing as some of these major bugs have sat effectively unfixed for a year (and I've come across several of them while trying to develop a new site), you're likely talking about 18-24 months from a bug being reported to being available in a stable, bug-fixed new release. These are not 'nice to have' bug fixes, these are critical failings in the current stable releases. That's the whole point of reporting bugs and producing point releases. There is obviously a major failing in the policy/process if it requires a critical mass of joe public complaining before a fix gets put into place.

[korostii]

it just makes Magento appear to be a heap of bugs that are never resolved

that release will no doubt have it's own round of bugs from new features

My thoughts exactly.

In addition, a Magento employee publicly stated that they are "focusing majority [of] our workforce on upcoming 2.2 release" and that they "want to backport only issues which community voted most.".

That also means that 2.1 branch might be switched to "security patches only" mode shortly after the release of 2.2. I can almost see their hands scratching to add a "could not reproduce on 2.2.0" comment to all those issues reported on 2.1.x.

[Leland]

Any chance of this getting fixed?

[mengbo123456]

# now i know why can't linking style ,but i don't know why this?
because install path no version1499055289 folder ,and i add it style work



but i don't know why it can't add version1499055289 folder itself in During the installation process

[ericrisler]

exporting https=on also worked for us. We sometimes get seemingly random files missing from the dpeloyment.

[sshymko]

@mengbo123456
Path /static/version<timestamp>/ in URLs of static files is the feature of Signing Static Files. It forces browsers to discard cached static files as their URLs change with every deployment.

The version directory intentionally does not exist in the file system. Instead, it's handled by URL rewrite rules implemented in .htaccess and nginx.conf of Apache and Nginx web-servers respectively.