Old page content since updating to 7.4.3

Hello @klishb,

We did not make any changes to the way our caching works in the last update.

When you update a post, the cache will be automatically purged if the option Automatic Purge option is turned on in Speed Optimiser >> Caching. This option is turned on by default and purges the cache when a new post is made, or an existing one is updated.

Please see if this option is turned on for your site. If the problem persists after that, it would be better to submit a ticket to us through your User Area so we can investigate, recreate, and see what is causing this on your end.

I only have memcache enabled in the multisite settings. I do not see the setting you are referring to when setting only the global settings in multisite. I see that setting on other sites that aren’t multisite, but not with multisite. Maybe I would have to enable the options for “SITE ADMIN PERMISSIONS” so I could see that setting at the subsite level? Not sure. I’ll open a ticket in the User Area. Thank you.

These are the Global settings and per-site defaults. As your pages are getting cached, the dynamic cache for them is turned on for these sites. Otherwise, if you turn it off from the plugin, the content of your site is no longer cached.

You can enable the first setting in SG-Optimiser for each site:

SuperCacher Settings? –> turn on

This will allow you to access the cache settings for each sub-site and from their dashboard. You just need to toggle Automatic purge for the sites you are encountering the issue and that should resolve the problem.

After opening a ticket with support we were not able to determine why these pages started caching. I can’t find any change made on the site configuration and the last changes to caching behavior in SG-Optimiser were from July. Prior to me updating the plugin it was already past that – it was on version 7.4.2 released last month.

I’m not sure why it’s necessary, but I’m now having to exclude these pages from caching. Prior to this I didn’t even have the Dynamic Cache or SuperCacher settings enabled. I had to enable SuperCacher just so I could exclude pages.

• This reply was modified 1 year, 1 month ago by klishb. Reason: clarifying post

The feature in question provides you with the ability to manage specific settings for each individual sub-site. Previously, these settings were likely configured to automatically purge upon update, which remains the default setting. Unfortunately I can’t tell you why this problem occurred for you after the update.

When a post is updated, the page cache will be automatically purged. However, once the updated page is cached again, it will be served from the cache more swiftly than a non-cached page.

Thanks for that information Pavel. I was aware of everything you mentioned though. The interesting thing is the pages on this particular site are very dynamic. No one is directly changing the post/page content therefore I’m not sure how the plugin would ever know to do a purge. The page content is completely driven by shortcodes that look at current date/time for a given dining menu.

For example, the page that displays the Grill menu always has this page content:

[eweekly_menu station=”grill” meal=”current” message=”Closed at this time”]

It never changes. Behind the scenes their is a menu management plugin at play that determines actual page content. For that reason I wasn’t sure caching would ever work as expected so I had it mostly off until I could do more testing. Magically the behavior changed as if I enabled caching, but I didn’t.

I guess when the shortcode is evaluated by WordPress it’s changing the page content even though a user didn’t change the post content. Maybe that type of change will also trigger a purge? I’m not sure how it detects that change to call a purge action hook. Either way, something weird changed the behavior.

Hello @klishb,

The Automatic Purge feature looks for specific WordPress hooks, and based on the triggered hook, it will perform full cache purge or a smart flush.

While I’m not familiar with the inner workings of the menu management plugin, but I suspect that it’s most likely not utilizing the standard hooks when updating the menu, thus the Automatic purge is not triggered.

By default, Dynamic cache is enabled and operational on all SiteGround servers. If the application sends the appropriate headers to permit caching, the system will cache the content accordingly. You have the option to completely disable the server-side cache for your WordPress website using our plugin or .htaccess rules. More details can be found here.

I believe that at some point, the affected pages of your website began returning different headers, which instructed the system to cache the page. It’s possible that updated configuration of some website components led to this change.

Best Regards,

Tsvetan Mitev