Plugin Contributor
iSaumya
(@isaumya)
Hi @prestonwordsworth,
That’s a great idea and though I truly love the idea and want to implement it, there is just one problem. The wp_date() was introduced in WP v5.3 and as this plugin supports WP v4.9+, so anyone using the older version of the WordPress system or if anyone is using the ClassicPress system, the plugin will not work properly.
Now I know, I can add checks to see if the function exists and if so use that or else use date, but I really don’t think adding the extra code and execution time just to support log date time will bring any positive value compared to the code execution cost.
Thread Starter
p15h
(@prestonwordsworth)
Many thanks for walking me through the options you’ve already considered @isaumya!
How about using instead get_option( ‘gmt_offset’ ) or perhaps DateTimeImmutable::getOffset?
Plugin Contributor
iSaumya
(@isaumya)
Well, we can’t use get_option( ‘gmt_offset’ ) as it will not help in any way as PHP date_default_timezone_set() expects the $timezoneId to be a timezone string like America/Los_Angeles.
Now you might say that we can use get_option('timezone_string') but the problem with that are:
- We don’t know how WP handles the spaces. So,
Los Angeles can be Los_Angeles or Los Angeles or Los-Angeles.
- What if someone doesn’t select a named timezone? In that case not sure what WP will return.
Thread Starter
p15h
(@prestonwordsworth)
I agree date_default_timezone_set() is probably not a route we want to go down, especially given it’s discouraged by Core for the sake of correct operation.
Could we just replace PHP’s date() with WP’s current_time(), which calls get_option( ‘gmt_offset’ ) from within itself?
Plugin Contributor
iSaumya
(@isaumya)
Hi @prestonwordsworth,
That’s a good idea. I’ve already implemented the changes in the code. Can you please test this build of the plugin and confirm if the Log is now showing the correct date and time based on your selected timezone inside WordPress admin?
Thread Starter
p15h
(@prestonwordsworth)
Dear @isaumya
As $gmt of current_time only uses the offset when set to the default false, I find it necessary to adjust the code to current_time( 'Y-m-d H:i:s' ) (without the second arg) to get it to show the correct time. Hope this helps!
Just to add that we’ve tested Elementor with line 227 from /wp-content/plugins/wp-cloudflare-super-page-cache/libs/cache_controller.class.php commented out for quite some time with no side effect. Perhaps the fix could be considered for the next release too?
Plugin Contributor
iSaumya
(@isaumya)
Hi @prestonwordsworth,
Unfortunately the seconds are super important and cannot be removed as on a high volume environment the second is very much needed. In that case we have to shift back to using date() or add more code to add support for wp_date() if available.
Thread Starter
p15h
(@prestonwordsworth)
@isaumya current_time( ‘Y-m-d H:i:s’ ) doesn’t remove seconds (which is ‘s’). What I found necessary to remove is the 2nd argument of the function: $gmt. Omitting it just makes it default to false.
Plugin Contributor
iSaumya
(@isaumya)
Hi @prestonwordsworth,
I’m really sorry. I totally misunderstood your previous message. I’ve pushed the fix. Please try this plugin zip now and let me know. This also includes the fix for elementor ajax requests.
Do note that, only the date & time shown inside the log will use the current_time() so only those date & time will show the data based on your site settings. In other parts of the plugin the date() is still in use and they cannot be changed as those uses the TTL argument as well. But this patch will fix your log date & time issues.
Let me know.
Thread Starter
p15h
(@prestonwordsworth)
Dear @isaumya
Many thanks for this. I can confirm both patches work as intended. I’m glad we’ve managed to get localised time at least into the log, while still preserving backward compatibility.
