Static caching fallback for long query strings

[arthurperton]

I've been following #3210 and #3860.

This PR adds a fallback for requests with long query strings by hashing them.

The retrieval of the related responses from the cache will be slower than for regular requests, because Statamic needs to be fired up. I guess the performance is comparable to half measure static caching. Still beats not caching the response at all though.

I also made max_filename_length configurable for those who know what they're doing and want to tweak things to the max.

[jasonvarga]

This is great. Definitely better to have something than nothing.

[jasonvarga]

I tweaked this implementation a bit.

• Removed the "could not write file" log, since it would never be reached as you always write the file now.
• Removed the max_filename_length from the manager class and just put it as a fallback in the method
• Gave the filenames a _lqs_ (long query string) identifier in it, so we can continue to just show the "your server rewrites arent set up properly" log when necessary. You won't see it just because of a long url.
• Tweaked the file path building logic so there's less repeating.
• Updated the tests to make sure we don't accidentally check the whole path against the max length, instead of just the basename. (Which I noticed I did - not you - at one point during the refactor)

[arthurperton]

Great tweaks!

Careful here though:

• Removed the "could not write file" log, since it would never be reached as you always write the file now.

Even with a hashed query string the entire filename could still be too long (and wreak 500 havoc). That would only happen with very long slugs and/or short max_filename_length's of course.

I left this check in place on purpose for this unlikely but possible scenario.

[jasonvarga]

Fair enough. Thanks. 👍

[arthurperton]

np

[arthurperton]

@jasonvarga Is it your intention to put it back in, or do you want me to create a PR?