- Issue created by @mikelutz
The max-age form input on the system performance form is constrained to an unusual set of values. The history as to why is shown below. The config value itself is constrained only to be an integer between 0 and 31536000 and the form should have an input element to match that.
Since the UX of having a list of humab readable timeframes is nice, we should convert this to a 'select or custom' type element with a predefined list of values (1 day, 1 year, etc tbd) and a 'custom' option allowing the input of any number of allowable seconds
determine what the pre-determined list of values should be.
System Performance form input will change
none
none
From comments on 📌 Add validation constraints to system.performance Needs review :
Been digging through the history of the form, and why those particular values are the only acceptable ones, as they really make no sense for the max-age header. You would think if we were going to provide user friendly options there, it would be more like 1 minute, 1 hour, 1 day. 1 week, 1 month, 6 months, 1 year.. It's fascinating, if you are a fan of Drupal history. The list of options was originally introduced here: https://www.drupal.org/node/29274 → to set a Minimum cache lifetime on the internal page cache, to prevent caches from being cleared constantly. At some point we started using the value for the cache control max age header. At some point someone realized it made no sense to have those two be the same thing, so they were split here https://www.drupal.org/node/730046 → . Still, the same option list was kept for both. Eventually, the cache system matured, and the internal page cache was split off into its own module and just cached everything permanently as tags and contexts were mature enough to handle cache invalidation. Still, the max-age setting continues to be locked to those legacy internal page cache minimum options created all those years ago.
So, the cache control max age header, which is all this option is used for now, accepts any integer value greater than or equal to zero, although 1 year (31536000) is often considered a reasonable maximum. We should also not set the config validation more loosely than the form, or you could set a value there that is not one of the form options and be unable to save the form without changing your max-age value.
For this issue, the validation should be set to an integer greater than zero, and possible with a max of 31536000. The form should be converted to a number field, min 0, step 1, possibly max 31536000 to match the config validation and acceptable values for the header.
We should consider a followup to restore an improved UI to the form, with a dropdown of sane defaults, and a custom option to allow any arbitrary valid integer, but those options should probably be more along the lines of the ones I described above, rather than the limit options available now that max out at a day, and were never created with the cache control max age header in mind.