Plugin Author
anmari
(@anmari)
Hi,
the left hand time is UTC time (WP actually runs it’s stuff in UTC time) and then the right hand side comments are in user time (ie the websites wp timezone setting).
What’s weird is that it normally only refuses to reschedule a new run if it thinks one is ready to run soon (within a minute, not eight hours!). You should note though IF there is NO traffic on the website then the run won’t happen – until there is actually traffic. It may be getting in a knot if you testing on a local site with no traffic, and you trigger a manual request but there’s an old ‘scheduled’ one waiting. If you then also delete the wp-cron, then wp loses the scheduled jobs, and again the job won’t run.
NOte: The log is a ‘past’ log – it is NOT showing when it will run, it is logging that at a time in the past, a request was received and a run scheduled.
You’d need a cron manager to see what’s in the cron and maybe force the cron to run straight away. (mine: https://wpusersplugin.com/downloads/amr-cron-manager/ – there are others)
A quick check on my site with timezone logic, all seems okay, as per
https://wpusersplugin.com/3458/cacheing-amr-users/
So one must ask – what is different on your site, or what sequence of actions is ‘foxing’ it?
What is your 1) server timezone (s/b UTC), 2) wordpress settings timezone (sounds like LA – is that same as pacific?)
plugin cache settings?
I have two WP instances that use AMR Users–production and test. The production site has plenty of traffic. The two behave exactly the same way with regard to cacheing.
One potential difference is that all of my sites are running under Docker, although it shouldn’t make any difference with regard to time. Within each container, the “server” runs UTC time (which is correct) and localtime is Pacific (which is the same as America/Los_Angeles). The file /etc/timezone is mounted from the overlying server, and PHP is set correctly to use Pacific time.
I have tried all combination of cache settings, and nothing works.
One more thing–
Did you figure out that when the log says that a cache is already scheduled, the time it gives is always in the past, but with a positive interval? For example:
2016-06-01 12:17:09 – All reports: Cache already scheduled for June 1, 2016 5:14 AM America/Los_Angeles, in 3 mins time
2016-06-01 12:17:09 – Received background cache request for 1 reports
It thinks the cache is scheduled in 3 minutes, but the actual scheduled time is 3 minutes in the past.
Here is an example of a background cache rebuild that I just requested. Note the times. I don’t think this can be any sort of system configuration error. I submitted the request at 2016-06-03 17:23:54 Pacific time. The system logs are correctly showing the localtime.
2016-06-04 00:23:54 – All reports: Cache already scheduled for May 31, 2016 9:33 AM America/Los_Angeles, in 3 days time
2016-06-04 00:23:54 – Received background cache request for 1 reports
Plugin Author
anmari
(@anmari)
HI tb
you said above that the server is ‘correctly’ set to Pacific. This may be causing the problem/difference to my setup.
http://yellerapp.com/posts/2015-01-12-the-worst-server-setup-you-can-make.html
My understanding is that WP expects that the server be in UTC and certainly hardcodes the default timezone to UTC. THen for post dates etc, it will use the timezone setting in the options. Doing otherwise could be messing with the timestamps which could be why you see a problem but I’m not. Since learning that WP wants UTC as default, my test servers are all set to UTC.
I’ve also come across plugins (way back one of mine did this too, shamefully!) that don’t know that wp basically works in UTC, and sometimes they set the default timezone themselves, which can cause problems. That can then mess with other plugins and wp too – we got some weird erros then.
https://weston.ruter.net/2013/04/02/do-not-change-the-default-timezone-from-utc-in-wordpress/
From http://wordpress.stackexchange.com/a/207752/3569
The downside of this is that WordPress assumes PHP is set to UTC when making mysql timestamps,
http://stackoverflow.com/questions/2532729/daylight-saving-time-and-time-zone-best-practices.
In the longer term I intend redoing the whole plugin to NOT use the cacheing – not easy as some features become hard to achieve without the ‘cacheing’. The question I have for myself now is do I spend precious time recreating your setup to assess whether the plugin should cope with that situation and whether it actually does (maybe something else in your setup is interfering?), particularly since you’re the first person to raise this in several years,
OR
is this something you can/should investigate (either change server to UTC if you can and/or find out if something else is interfering by deactivating other plugins ) – or maybe you just use another user listing solution?
Be wary of what you read on the web wrt to setting php timezones: I have done a LOT of work with timezones & daylight saving for events and have come to see that a lot of people don’t know what they are talking about, and dish out timezone advice without thinking of the risks of time mismatches.
If you do find out something, please do post back and let me know. This will be on my list in case I have spare time to ‘play’.
Plugin Author
anmari
(@anmari)
HI I had a quick play with server timezones and still cannot create the problem you describe.
There are two types of jobs – one is the control job and the others are one per userlist.
The main control job runs as frequently as you have specified and sets up the ‘per userlist’ jobs ‘amr_reportcacheing’
NOW amr_reportcacheing always gets scheduled using ‘wp_schedule_single_event’ for the current UTC time plus 5 seconds from now. So it should NEVER be scheduled for hours in the future UNLESS something is messing with your timestamps. And isn’t LA time about 8 hours behind UTC ? so if say at some stage, wp when scheduling using proper UTC, and then perhaps at another time if it now has a LA type timestamp, it would think that the first timestamp was 8 hours ahead.
The plugin checks if amr_reportcacheing for a user list is scheduled
using wordpress function wp_next_scheduled. It doesn’t do a time comparison, because they should always be running pretty much immediately IF they are in the schedule. It’s only the main job that should always show in the cron schedule.
SOOO Anyway if it were my site I would do one or both the following:
1) on my local test server, I would make sure I had a copy of all the plugins and I would run a global search on all the plugin files for the string ‘date_default_timezone_set’.
You should NOT find it (except for bbpress setting to UTC themselves – lol).
If you do find it, deactivate the plugin with it and rerequest the jobs, remembering to ‘trigger’ the cron to get the main job to run.
2) If that doesn’t work try:
http://webdesign.anmari.com/2932/debugging-a-possible-clash-between-plugins-andor-a-theme/
Thanks for your thoughtful responses, and all the time you put into it. Here is some additional info:
1. This WP instance is running under Docker, and that may be unusual, but I can’t be the only one, and I don’t see how that could be causing the problem. The Docker kernel is a limited view of the system kernel, and the system kernel is running UTC. The Docker container is “correctly configured” to use Pacific time because both /etc/localtime and /etc/timezone are symlinked to the host’s /usr/share/zoneinfo/America/Los_Angeles. The time and timezone info in the container is exactly as it should be. The timezone is correctly configured in WP.
2. I disabled all of the plugins except AMR users, and the problem doesn’t change. The theme is twenty fourteen, a default theme.
I really like AMR Users, and don’t want to switch to a different plugin. I like the configuration screen, and the format and appearance of the user list. It’s better than anything else available. I do like your proposal of eliminating the cache, and I totally agree it’s better to spend your time on that. It will be a lot cleaner without the cache.
I am not allowing users to sign up for my site. They are added and updated programmatically. I will just add a wget to run the “Rebuild Cache Now” from the list configuration page every time I make a change to user data.
