Closed mpchadwick closed 7 years ago
Thanks for the PR. I appreciate your frustration with the FPC not managing the expiry in a sane way.. I would be open to a PR with a few changes:
/^(?!.*REQEST)/
in your case.The above isn't set in stone, but it would be meeting your needs I think while providing a generally useful feature. It technically should be a Zend_Cache_Frontend feature but that is obviously never going to happen. :)
Closing as #111 was merged.
Hi @colinmollenhour -
Apologies in advance for the long-winded issue (feature request).
EnterprisePageCache uses a pretty awful strategy for managing the cache.
It works like this...
There are many problems with this approach...
This is a topic I cover in both a blog post and a talk.
There is a closed issue that is related to this where it was incorrectly assumed that Magento was defaulting to false (it defaults to NULL).
It would be possible to handle this the application as suggested then by subclassing Enterprise_PageCache_Model_Processor, redefining processRequestResponse and using the child class as the request processor, however I feel like it would be nice to not have to do that by adding the ability to work around this limitation (bug?) of Magento directly in the module that is actually responsible for saving to the cache.
We have in fact already done this at Something Digital by subclassing this module, but I'd like to see if you would accept it upstream. The idea is to introduce 2 additional configuration values (currently called
sd_expire
andsd_refresh_on_load
) although we can rename them for upstream.The strategy is to use the
sd_expire
configuration value to set the TTL (if it hasn't already been set) and refresh the TTL on access (assumingsd_refresh_on_load
is set). This idea behind this strategy is to keep the cache primed with the responses that are accessed frequently and expire out the things that aren't.I've included the code I have in use at SD below. Are you open to including this?