Browser displays cached version of page

Hello

The Woody plugin does not affect caching. Perhaps caching is configured on your server. Check with your hosting.
What does your snippet do that doesn’t work on a cached page?

PHP snippet simply contains:

date_default_timezone_set('Australia/Perth');
echo 'As at ' . date(DATE_RFC2822);

It runs near the top of the page (it appears with text asking the visitor to click on refresh if the date/time are old). The symptom is as follows:

When displaying the page the first time, the display shows the correct (current) time. However when displaying the page later using the same browser, the cached page is displayed (showing the old date/time).

I have tried various header changes and removed all .htaccess caching commands. I’m using SiteGround.com as my host. They claim that they are not doing any special kind of caching. I have checked that “Cloudfare” is Inactive, SuperCacher is “off”.

I’ve removed all caching from .htaccess and there is no caching plugin installed. The installation is running on NGINX. I’ve checked the URL with redbot.org and it shows that the cached page is usable for 180 days despite my meta tags in the head section as follows:

<meta http-equiv="expires" content="Sun, 01 Jan 2014 00:00:00 GMT"/>
<meta http-equiv="pragma" content="no-cache" />

I have tried other combinations of meta tags with no success.

I have used PHP snippets on several other pages. They only run the first time the page is accessed. After that, they only run if I click on Refresh (<F5> or circular arrow on browser). Any help you can supply would be most welcome.

The Woody plugin is not to blame for this. I tried creating the same snippet on my site, and it updates every time the page opens.

In any case, these are the caching settings.
htaccess does not work in Nginx. Maybe something in the NGINX settings?

You won’t believe this. Siteground.com has moved from Linux to Nginx. I’ve only just become aware of it. No doubt it was buried behind some changes to T&C that I did not read.

Under Linux they recommended the use of a plugin called SG Optimizer that controlled the caching. I purposely had never implemented it. Then I started having problems with Woody Snippets not being executed on each load. I knew right away that it was caused by caching. So I decided to try SG Optimizer to see if I could manage caching a bit better. But it did not help. The problem persisted.

So I deleted SG Optimizer thinking that I had returned to my previous situation. Little did I know that SG Optimizer added dozens of rules to the .htaccess file to control caching. When I deleted SG Optimizer, it left those rules in the .htaccess file. I never noticed.

My guess is that Siteground automated their move from Linux to Nginx. To do that, they would have had to automate the conversion of the .htaccess file rules to nginx.conf. If they did that transfer for my website when I had SG Optimizer installed, they would have copied all those caching rules left behind by their plugin! Siteground don’t permit clients to view or modify their nginx.conf file. Frustrating.

Ok. Here’s the messy bit that’s probably causing the problem. Siteground have decided to implement something called “Static Cache to NGINX Direct Delivery”. You can read it here: https://www.siteground.com/blog/nginx-direct-delivery/

My reading of this feature is that Nginx is deciding if a page can be served from cache by looking at its contents after processing by the CDN (WordPress). If it considering just the final HTML and Javascript, it would treat pages as cacheable even when they contained a PHP snippet. I’m sure you can see that this assessment would be wrong. It would completely ignore the dynamic nature introduced by the execution of that PHP. And Nginx delivers its own headers (like the rules in the .htaccess file overriding any headers in the HTML). In other words, there is nothing I can do to “force” the page to be treated as uncacheable since I can only do so in the HTML header. So frustrating.

I’ve got a ticket outstanding with Siteground and have explained that I either need Nginx Direct Delivery turned off on my website or they need to supply me with a trick to defeat Nginx assessment and force it to treat my pages with snippets as dynamic contents and, therefore, uncacheable.

An update/correction by Siteground to my ticket has clarified the situation.

1- Apparently my account has always been on Nginx. It has never been on Linux. My bad.
2- They claim that Nginx Direct Delivery has not been turned on yet on my account. So this cannot be the cause of the misbehaviour of my PHP snippets.
3- They claim that they are still using Apache so my .htaccess file is still in play. They also confirmed that the SG Optimizer rules have not been copied to the nginx.conf file.
4- They have disabled some kind of caching that is a default feature for all their clients. I’ve tested my pages with snippets and, so far, they are now all behaving correctly (running the PHP snippet each time). I want to conduct additional tests tomorrow but so far it looks good. If they continue to work this way, I will turn off the default caching (it can be done by editing the php.ini file) on all my websites that use Woody Snippets.

• This reply was modified 4 years, 10 months ago by dccharron.