Do not use select list for setting "cache maximum age" option

Here is a reroll for 10.2.

Created a MR re rolled with 11.x.

Rebased and added a test.

Lets update the issue summary as this will be a UX change. That should help the sub-maintainer/framework manager make the decision.

I added a basic description of user interface changes.

> 2 . The maximal allowed value is 1 day. Why is that? Drupal 8 has got tag-based cache system which is supposed to cache never-changing content forever.

The internal page cache is forever, this setting does not affect this.

You can use tags to invalidate content through a supported CDN such as Fastly or Cloudflare (with an expensive plan). But you can _not_ invalidate caches stored directly in browsers, which is what this setting does as well. That's why for example Fastly supports its own cache control key which core doesn't set where you set a low cache max age on the regular header and a longer one just for Fastly.

In short, it quickly gets more complicated and it's pretty dangerous to set this value higher and you should only do that if you have the appropriate infrastructure.

Having to set a value in seconds is arguably also not great UX but it's also not rocket science to calculate that. Could be dealt with with a few examples.

see also my comments in 💬 Page cache isn't invalidated Needs review

Not sure if it's a good idea for core, but in the HTTP Cache Control module → we added an Expert mode toggle to the Performance config form that toggles maxage inputs between selects with readable presets and number inputs.

I was not aware of that module but good to know! So I would almost be a +1 for closing this as work as designed. If changing to a number field adds a layer of complexity meant for advanced users then maybe it doesn't belong in core.

There is a use case for using a high value when the site is behind a reverse proxy that uses this value and then removes the header to prevent the browser from getting this high max age.
But I think ✨ Allow different cache maximum age for browser and proxy Active would be a better solution to this.

So should we close? Saving credit if we do

Sorry if wrong status but seemed more correct.

I just noticed that the purge module now adds more options to the form: https://git.drupalcode.org/project/purge/-/blob/e5ca166bff3c0573f2c84cab...
This covers our use case of needing to set a large value when using a reverse proxy (and I think most websites using a reverse proxy will use the purge module).

So I would be OK with closing as wontfix.