It’s just after 23:00 CET… I’m afraid it still reset to a new “Today” and 0 visitors.
Did you clear the browser cache? I just tried with a website that was having the same problem. After clearing the cache the problem was gone.
You can do a hard refresh in Chrome by right clicking and click inspect. Then you can hold the refresh button and it gives you an option to do a hard reload. That should help hopefully.
Yeah I did that, with the earlier patch I saw the console logging was removed as it was in git, and yesterday that console logging was added as it was in git. (It was late so I didn’t look more carefully at the output.)
I have a feeling it’s just the date_start and date_end in the ajax call, and the backend is working correctly. So between 23:00 and 0:00 it doesn’t really start a new day but the date_start and date_end are a day ahead and the counter will stay at zero. But I didn’t check that, will check it tonight.
P.S. I just checked the code TodayBlock.js.
It uses gmt_offset. In my database gmt_offset is present but has no value, but timezone_string has (it’s set to Europe/Amsterdam). This is from the Worpress setting in admin.
Maybe the answer lies in there somewhere. I briefly searched for it and I’m just copying this from the Internet:
gmt_offset is actually a bit of a strange setting; it can either be set (the manual timezone offsets in the timezone dropdown), or derived from the actual timezone. Likely, the settings endpoint should expose the raw value (either unset or the manual timezone offset), and the site info can expose the derived value (which will always have a value).
The unfortunate situation is that there are indeed two different options:
- Newer
timezone_string, which saves PHP–style time zone.
- Older
gmt_offset, which saves numeric float offset in hours.
But in newer environments timezone_string actually overrides gmt_offset, the value returned by the latter will be based on the former. However the opposite isn’t true — gmt_offset might be valid, while timezone_string is empty.
WordPress 5.3 had shipped wp_timezone() function, that abstracts this and returns a valid DateTimeZone object, regardless of underlying WP settings.
I see in git there were some changes in TodayBlock.js from the version when this problem started.
Maybe it’s not gmt_offset, but this. In the old working version, it uses javascript Date(), in the new version it does this:
// get currentDate
const currentDate = new Date();
// get current unix timestamp
const currentUnix = Math.floor(currentDate.getTime() / 1000);
// add burst_settings.gmt_offset x hour in seconds to currentUnix
const currentUnixWithOffset = currentUnix + (burst_settings.gmt_offset * 3600);
If gmt_offset is somehow working and has a value of 1, it seems an unnecessary hour is added, and it will be midnight one hour too soon. Because new Date() already gives the browsers timezone and local time, not UTC.
Anyway, I’ll leave you to it.
Forget all that (possibly). I noticed at the WordPress installed plugins page that Burst was listed twice, one activated one deactivated. I renamed the old burst-statistics directory to burst-statistics-old earlier when I uploaded your first fix, and for some reason WordPress picked up on that renamed directory and picked up the javascript from there after I uploaded the second fix. I.e. the javascript came from burst-statistics-old/.
I deactivated the old plugin and activated the new one, and it picks up on the right javascript now. Hope that works, WordPress seems to be confused by me having just uploaded a new version directly instead of properly updating the plugin, and doesn’t know which is what. I still don’t entirely trust it, I added a console log to a script in the 2nd fix but I don’t see it.
Hi @webwitnl,
Thanks a lot for your deep dive into the code. I think I misunderstood what was going wrong. You were talking about the Today block. I was thinking about the DateRange Today in the Statistics tab. So sorry about that.
There was also an issue with the DateRange for Today. The issue is actually the same, so I made a new fix.
We want Burst to show statistics for the WordPress timezone. So not the browser or the server timezone. Hence why the timezone stuff is quite complicated.
Here is the fix: https://github.com/Really-Simple-Plugins/burst/tree/1.3.4_23_00_timezone_fix
I sincerely hope this issue is finally fixed, both for you and me 🙂
Kind regards,
Hessel
Looks fixed! It was 2023-02-03 23:10 CET and without the patch it made calls to the backend like this:
/wp-json/burst/v1/data/today?date_start=2023-02-04&date_end=2023-02-04&date_range=etc.
After it it is like this and it works properly:
/wp-json/burst/v1/data/today?date_start=2023-02-03&date_end=2023-02-03&date_range=etc.
Great to hear. Thanks a lot for helping us figure out what was wrong and your patience! I’ll set this thread to resolved now.
