Suggestion: max! performance and continued operation during update/maintenance

(Separating this idea from Creating Files Best practice)

I learned that with the asset collections you already allow for scriptless (webserver-only) server operation.
If you move the full page cache files into the webroot you may maximize the public site performance and allow the site to remain mostly available during updates or maintenance.

For full support of scriptless serving, the CMS would have to warm the webroot directory with the cached pages (files) and allow to schedule cache expiration events (cron, runwhen, or own daemon process) to update the page cache periodically, or better yet, on the time necessary (e.g. publish and unpublish dates).

The Zena CMS, for example, does not do scheduled cache refreshes, but the CMS does only do a quick check for cache status and then hands over to webserver if the file is still up to date.
When I experimented with completely disabling the CMS for public access to existing files, and only manually deleting the cached files after occasional page updates, I found it is important to expire the cache only selectively, because Apaches response to browsers asking for their browser cache status seems to work based on file modification date. When I deleted a file that hasn’t changed, the identically re-created files were transfered again instead of just confirming the validity of the browser cache.

Another aspect of scriptless serving is the format and language selection. Apache supports this by its “mulitviews” completion.

Automaitic completion works nicely for URIs that end in: .format.language-code

The automatic completion may be disabled in the .htaccess for URIs starting with special language code directories ( /en/, /de/ etc.). See for “multilingual site without PHP”.

Overall URI pattern:
domain.tld/{optional lang code}/path/filename{~optional timestamp to fetch specific version}.{auto completed format}.{autocompleted lang}?{timestamp used to force browsers to reload updated asset files that have long default cache periods that have not passed yet}

The CMS would default to render the links without the optional and autocompleted parts, and maintains a corresponding symlink that points to the current version. However, the user may also also choose to link to a specific version in the asset list content element.

Interesting idea although currently our cache is not browser deliverable without script. We plan for something like you suggest but that will need some more adjustments. Also this would only work for requests that can be fully cached…

I have to think more about other pros/cons of this.

Maybe the module from @radmiraal can help here:

And with the redirect stuff I’m working on, this should solve most issues, see