Closed heymarkreeves closed 2 years ago
Isn't
_addHash
just adding a querystring param? Does the file actually need to be loaded from its URL?
The CSS file must be loaded, because a unique hash is generated based on the content of the file. So the cache won't get busted until the file contents change.
In rare edge cases, this seems to cause problems, which is why we added the cacheBusting
config option. You may be right about single-threaded PHP, I never quite figured out what was causing the system to hang.
Which of these warning messages is showing up in your logs?
Ah, gotcha. Changed contents = new hash vs old hash. You don't want it on every load.
It's the line 87 message. It's definitely the single threaded timeout. I've run into the same sort of issue with Twigpack, when it's trying to fetch the manifest from the same URL it's running on.
Sounds similar. Do you have a workaround for Twigpack? Or do you just disable this type of behavior?
I gave up on ./craft serve
and installed Laravel Valet :)
Ha, sounds good to me. 😄
CP CSS is installed in a site I've taken over, where the setting for CSS file contains:
Using
./craft serve
, I get the following:I can fix that by setting
'cacheBusting' => false
. The file exists, and if I disable cache busting, I can see it applied in the control panel. But I can't use the control panel because every screen takes 2 minutes to try to load that.I'm guessing this is because the built-in PHP server is single-threaded, and it times out waiting for
file_get_contents
to respond.Isn't
_addHash
just adding a querystring param? Does the file actually need to be loaded from its URL?