strarsis

@jasperf: Yes, this would be great because then I can sync back directly from production to staging.

disorderfs (also fuse based) encountered the same issue, it seemed to be resolved by changing some flags: http://osdir.com/ml/general/2015-09/msg32851.html

A cache adapter that can be inserted? This would have the additional advantage of reusing existing cache implementations.

Concerning collisions: You can now use the [prefixIds plugin](https://github.com/svg/svgo/issues/651) in svgo.

@swalkinshaw: Ideally the `X-Cache` HTTP header is also checked in WordPress, but until this is added, `X-Cache-Enabled` appears to be the least intrusive HTTP header. Yes, constraining the header to...

@swalkinshaw: Alternative proposal: Add the `X-Cache` header name (with check callback) to the checked headers by using the [`site_status_page_cache_supported_cache_headers`](https://developer.wordpress.org/reference/hooks/site_status_page_cache_supported_cache_headers/) filter, as in a Bedrock site mu-plugin. Related WordPress trac issue...

Side note: The already added [`Fastcgi-Cache` header](https://github.com/roots/trellis/blob/v1.21.0/roles/wordpress-setup/templates/wordpress-site.conf.j2#L20) is not added with `proxy_set_header` because it can be useful to the outside, e.g. reverse proxy frontends?

> proxy_set_header After some experimentation I noticed that WordPress does not check for the upstream HTTP header, but rather does [a loopback HTTP request](https://github.com/WordPress/WordPress/blob/6.6.1/wp-admin/includes/class-wp-site-health.php#L3391) and [checks the HTTP headers from...

@swalkinshaw: It was not as trivial as I thought first, but now the configuration only adds the `X-Cache-Enabled` header for loopback-requests. Checking for localhost origin (`127.0.0.1` or `::1`) did not...

Revisting this issue: Such a feature would be awesome as it completely avoids code/style deduplication.