Cache Refresh Interval is not working

Can you post your system reports? Try running through this: https://docs.simplecalendar.io/troubleshooting-theme-plugin-widget-conflicts/

It works for me so something on your site/server has to be conflicting and we just need to figure out what it is. Are you using a caching plugin or some kind of caching on your host? What host are you using?

OK I’ll have a go at some troubleshooting using the suggested methods, but it will take a long time becuase I need to wait several days to be sure it is not working each time. And I can’t afford to change the theme, remove plugins on my primary site, so can only try it in my sandbox which seems to behave differently anyway, perhpas becuase it gets almost no traffic.

The primary site is hosted on hostgator, while my sandbox is run in WAMP server on my windows machine. The only difference is that I do NOT have backup buddy enabled on the sandbox config, and the php config may not be identical.

I am using ZENcache on both, but the page that holds the calendar shortcode is disabled from caching. I could try temporarily disabling zencache site wide to see if that made any difference.

Here is a system snapshot of my primary system

### Begin System Info ###

** WORDPRESS DATA **
Multisite: No
SITE_URL: https://www.standrewsoxshott.org.uk
HOME_URL: https://www.standrewsoxshott.org.uk
WP Version: 4.4.1
Permalink: /%category%/%postname%/
Cur Theme: St Andrew’s Church Oxshott 0.1
Post Types: post, page, attachment, revision, nav_menu_item, location, event, event-recurring, calendar, wpcf7_contact_form, ecn, wpfc_sermon, staff-member
Post Stati: publish, future, draft, pending, private, trash, auto-draft, inherit
User Count: 6

** WORDPRESS CONFIG **
WP_DEBUG: Disabled
WP Memory Limit: 40MB
Table Prefix: REDACTED
Prefix Length: Acceptable (10 characters)
Show On Front: page
Page On Front: Home (ID# 5)
Page For Posts: (ID# 0)

** BROWSER DATA **
Platform: Windows
Browser Name Firefox
Browser Version: 43.0
Browser User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0

** SERVER DATA **
jQuery Version 1.11.3
PHP Version: 5.4.45
MySQL Version: 5.5.40-36.1
Server Software: Apache

** PHP CONFIGURATION **
Safe Mode: No
Memory Limit: 256M
Upload Max: 64M
Post Max: 64M
Time Limit: 60
Max Input Vars: 1000
Display Errors: On
Sessions: Enabled
Session Name: PHPSESSID
Cookie Path: /
Save Path: /tmp
Use Cookies: On
Use Only Cookies: On
FSOCKOPEN: Your server supports fsockopen.
cURL: Your server supports cURL.
SOAP Client: Your server has the SOAP Client enabled.
SUHOSIN: Your server does not have SUHOSIN installed.
OpenSSL: Your server has OpenSSL installed.

** PLUGIN INFORMATION **
Active Plugins: (36)
– All In One SEO Pack 2.2.7.5
– Antispam Bee 2.6.8
– BackupBuddy 6.5.0.0
– bib.ly – Bible reference shortener 0.8.6
– Camera slideshow 1.4.0.1
– Contact Form 7 4.3.1
– Effortless Google Maps 0.66
– Email Encoder Bundle – Protect Email Address 1.4.3
– Event Calendar Newsletter 2.0.3
– Event Calendar Newsletter Pro 2.0
– Events Manager 5.6.2
– FeedPress 1.7.1
– Get Custom Field Values 3.6.1
– Global Content Blocks 2.1.5
– Google XML Sitemaps 4.0.8
– iThemes Security 5.2.0
– List category posts 0.67.1
– Multiple content blocks 3.2.2
– Optimize Database after Deleting Revisions 4.1.1
– Post Templates by Category R1.3
– Redirection 2.4.3
– Sermon Manager for WordPress 1.9.2
– Sermon Manager write ID3tags addon 1.0.1
– Simple Calendar 3.0.12
– Simple Image Widget 4.3.0
– Simple Page Ordering 2.2.4
– Simple Staff List 1.19
– System Snapshot Report 1.0.1
– TinyMCE Spellcheck 1.3
– WordPress Category Archive 1.3.0
– WordPress Custom Post Type Archive 1.0
– WP-PageNavi 2.89.1
– WP Edit 3.7
– WP No Category Base 1.1.1
– WP to Twitter 3.1.9
– ZenCache 151107

Inactive Plugins: (2)
– Akismet 3.1.7
– Stout Google Calendar 1.2.3

### End System Info ###

I am hosting with eHosts.

### WordPress Installation ###

Site Name: Buffalo Range Shooting Park
Home URL: https://buffalorangeshootingpark.com
Site URL: https://buffalorangeshootingpark.com
Version: 4.4.1
Locale: en_US
Timezone: America/Chicago
Multisite: No
Permalinks: /%postname%/
WP Memory Limit: 40 MB
WP Debug Mode: No
Script Debug: No

### Active Theme ###

Theme: BUFFALO RANGE SHOOTING PARK – 1.0
Child Theme: Yes
Parent Theme: Divi – 2.5.9

### Active Plugins ###

Simple Calendar: 3.0.12
iThemes Security Pro: 2.1.2
Monarch Plugin: 1.2.6
BackupBuddy: 6.5.0.3
Elegant Themes Updater: 1.1
Divi Children: 2.0.8

### Server Environment ###

Web Server: Apache Phusion_Passenger/4.0.59 mod_bwlimited/1.4
PHP Version: 5.4.45
MySQL Version: 5.5.42-37.1
Server Timezone: UTC
Display Errors: Yes
Safe Mode: No
Memory Limit: 256M
Upload Max Filesize: 64M
Post Max Size: 64M
Max Execution Time: 30
Max Input Vars: 1000
fsockopen: Yes
cURL: Yes
SOAP: Yes
SUHOSIN: No
WP Remote POST: Yes
WP Remote GET: Yes

Here are some potentially interesting data points.

The calendar uses a search term to filter out relevant events. All the filtered events are repeating events (some weekly, some monthly) but there are non-repeating events in the base calendar that are not delected by the filter. The cache time of the calendar is et to zero and the page on which it resides is disabled from caching by Zen cache. The calendar list current day plus 8 days.

On saturday I looked at the calendar and it was NOT showing a repeating event for saturday for the following saturday.

I inserted a non-repeating event on thursday which should have been selected by the filter. It did not show up.

I refreshed the calendar cache and both the thursday and saturday events showed up.

I deleted the thursday event, and it disappeared without clearing the cache.

I re-inserted it at a different time and it showed up without clearing the cache.

delted… went away.

I could repeate this multiple times and it always worked.

I left it alone until sunday morning, when the 3 monthly repeating events for next sunday showed up without clearing the cache!

So it appears to be working at the mome4nt after that initial cache clearing. I’ll have to wait until wednesday for the next repeating event to potentially show up.

Any ideas on this front?

Marty did you run through this? https://docs.simplecalendar.io/troubleshooting-theme-plugin-widget-conflicts/

It is difficult to do all those tests because the calendar works fine for basically 24 hours and will update everything instantly… the problem occurs after hours or days later it suddenly stops updating unless I clear the Cache manually.. then it suddenly works perfectly for a day again.

Because of the length of time before it bugs out, I cannot change the Theme or Disable Plugins… because it takes 24 hours or more for the bug to appear. I can’t leave the Website in a broken state for multiple hours or days to wait for the bug to crop up..

I am not using any Widgets (other than standard WP Text Widgets) and I am not using any Caching Plugins.

Is there a way to tell the plugin to not Cache at all and just pull the info Real Time every time the page is loaded?

Is there a way to tell the plugin to not Cache at all and just pull the info Real Time every time the page is loaded?

You can set the cache setting to 0.

You can set the cache setting to 0.

As I reported earlier, I tried that and it had no effect. i.e. it still didn’t refresh. And as Marty reports above, I also found that once I have manually refreshed the cache, I can add and remove calendar entries and they will update instantly (when cache is set to zero), but if I leave it for 24 hours or so, it will again stop updating and needs a manual refresh to start it working again.

This may be a complete coincidence, but I disabled backup buddy on Saturday and on sunday everything worked fine. I notice that marty is also using backup buddy. However, if that IS the problem I don’t think I can do without backup buddy.

Backup buddy runs a nightly database backup. I guess I could change that to weekly, or at most twice weekly and see if that helps. Is there some way that running a database backup would cause a problem to simple calendar? Or some cron interaction?

BUT it MAY just be a coincidence!

I’ll report back in a few days to see if this behaviour persists.

OK, the finger is continuing to point to BackupBuddy. I disabled Backupbuddy on my production platform and enabled it on my sandbox. Both have the simple calendar set to zero cache time, the page on which is on is NOT cached by zencache and the calendar uses a search term to locate the relevant entries.

I inserted a test (non-repeating as it happens) event in the google calendar and it appeared immedeately in BOTH the production and sandbox versions. I deleted it and it went from both.

Then I waited 24 hours (until nightly backups had run?) and repeated the experiment. The inserted event appeared immediately in the production version but NOT in the sandbox version. This is the opposite behaviour that I had previously observed when backcupbuddy was enabled on the production platform and disabled on the sandbox. i.e it then appeared in the sandbox, but not in the production.

Backupbuddy, in both case, is running a nightly database only backup.

Not yet CONCLUSIVE evidence, since there could be so many other variables like traffic levels etc. , but I’m beginning to think Backupbuddy is implicated. The question now is WHY, and what can we do to fix it?

Mike that is an interesting development. Backup Buddy is an extremely popular and required plugin…. Hope this can be resolved.

Less conclusive evidence today. Two repeating events scheduled on Wednesdays came into view in the 8 day look ahead of my calendar. Both appeared in BOTH the production (with BackupBuddy disabled) AND the sandbox (with BAckup Buddy enabled) without a cache refresh.

However, previous experience is that it does sometimes work, and I haven’t been able to determine what the criteria are.

I guess the good news is that it DID work on the production platform.

I’ll leave everything as it is, and see what happens tomorrow.

Aha! And today the production (without backup buddy) worked, but the sandbox (WITH backupbuddy) didn’t.

But I just checked the backup buddy logs on the sandbox, and noted that yesterday the “nightly” backup hadn’t run until AFTER I had checked the calendar page! So that probably explains that anomaly.

It seems that something that happens when the database backup runs then prevents simple calendar from reading the google calendar properly. Note that it DOES still trim past events from the display. It just doesn’t add any new events, either those which should now be visibale according to the look ahead, or those which have subsequently been inserted into the google calendar.

I’m now going to swap back to production running backup buddy and sandbox not, and check that it switches the behaviour back again.

Hmmm. Curiouser. I reactivated backup buddy on the production system and ran a manual database backup. I then added a new event to the google calendar, and it DID appear!

So perhaps it is not the actual running of the database backup that causes the problem, but something to do with the cron entry that triggers it? Who knows?