Dave
Forum Replies Created
-
Forum: Plugins
In reply to: [W3 Total Cache] Expires and Cache-Control headers overwritten or not sentThanks for your help with this. I understand it much better but I’m still having a problem.
I am using disk caching.
I tried to purge the cache using server cron and calling w3tc_flush_url($url). But that does not always work because the WordPress cron implementation only executes when a request comes into WordPress, and there may be no requests except those intercepted by the cache. The operating system does not run the job, WordPress does. But W3TC may intercept all incoming requests and return cached pages, in which case WordPress does not run and neither does the cron job.
I need the site to operate properly all the time, even when there is no admin logged in, nobody editing posts etc. or otherwise accessing WordPress and causing the cron job to run or the cache to be purged based on policies. The only activity may be non-logged in users accessing cached pages. But the cached event page still must expire when the event begins. Policies don’t work and cron doesn’t work in the general case.
The only solution I can think of is to add a link to refresh the event page with a url that includes a query string like “?refresh”. That will bypass the cache and give WordPress a chance to run the cron job and purge the cache. It’s not a great solution but I think it works based on my testing so far.
It would be nice if W3TC had a way to establish an Expires date/time for a cached page. It seems to me there could be a setting and then simply use the Expires header if one exists. Or alternatively, a setting to allow incoming requests to always trigger the WordPress cron system to execute. The latter is more complicated and would slow down the system slightly so the former would be better.
Is either possible?
Thanks again!
Forum: Plugins
In reply to: [W3 Total Cache] Expires and Cache-Control headers overwritten or not sentYes, that helps. I looked at my .htaccess file and I can see that W3TC modifies it when “Set cache control header” is turned ON. So it makes sense that if I want to assign any headers programmatically then I need to turn that setting OFF.
But I’m left with a question: How can I signal W3TC that a cached page should be considered stale at a certain point in time? I had hoped that using either an expires header, or max-age inside a cache-control header would cause W3TC to discard the cached page after that point. I know that those headers pertain to the browser cache but I was hoping that W3TC would look at and respect those settings for the page. But that does not seem to be the case. I feel like I must be missing something. Is there some other way that I can tell W3TC to automatically purge a cached page after a specific time?
What I’ve done is set up a scheduled event inside WordPress to purge the cached page at the right time. But the scheduled event will only run when WordPress receives an external request, and that doesn’t happen because W3TC is intercepting those requests and returning the cached pages! What I need is for W3TC to recognize that the requested page becomes stale at a specific time and automatically purge the page. How can I do that?
Also, can you tell me why W3TC does not resend those headers (expires and cache-control) when it sends a cached copy of the page? Is it because W3TC relies entirely on .htaccess to set those headers and never adds headers programmatically? But wouldn’t it be considered a W3TC bug if the cached page is not an exact copy of the original in all respects including its headers? It would be possible for W3TC to add those headers programmatically, whether .htaccess does or doesn’t overwrite them. Either way the result would be identical to the original page. I believe this may also solve my problem because if the browser has the expires information then a subsequent browser request should inform the cache that the page has expired. Does that make sense or am I missing something?
Thanks for your help!