Hello, today I updated WordPress to 5.3 and tragically found out that it completely messes up any dates in “date_picker” fields inside a repeater, by shifting them all one day earlier: i.e. “20191114” becomes “20191113”. Some additional info I gathered through some debug on my local server:
– it happens only to dates inside a repeater field;
– the value is stored correctly inside the database; i.e. if I do a get_post_meta($post->ID, ‘repeatername_0_datepickername’, true) it returns 20191114 but with a while( have_rows(‘repeatername’) ): the_row() followed by a get_sub_field(‘datepickername’) it returns 20191113;
– the issue seems to happen during the filtering via the ‘acf_format_value’ function: I tried editing it by removing the line $value = apply_filters( “acf/format_value”, $value, $post_id, $field ); and it returns the correct value (of course that’s not a solution, I just tried doing that on my development machine to try and understand);
– this started happening an hour ago right after I updated to WP 5.3, nothing else was changed and I’m running the latest version of ACF Pro (5.8.7).
I also opened a ticket because this is a really urgent problem impacting on a lot of websites I made (right now I’m using a temporary solution which simply adds a day to the date in my script but of course it’s not optimal).
It’s NOT the same issue as https://support.advancedcustomfields.com/forums/topic/date-picker-control-not-working/ , my control works perfectly in the backend.
Hi I’m facing the same issue. WordPress 5.3, reverting ACF to 5.8.3 had no effect.
I have the same issue.
I just found out that the culprit seems to be I’m using the following instructions in another part of my script BEFORE running the while loop on the repeater field:
The point is that I’m in that timezone and I NEED to set it and the appropriate locale in order for other parts of my theme to work correctly and I don’t see why that should impact on ACF. Any clues?
Thank goodness for that, I though I was going mad. Exactly the same issue. All dates presented on front end a day behind but OK in back-end. Upgraded ACF and WordPress to latest versions so I don’t know which has caused this problem.
This is a football results website so is date crucial. Added dates to day and they are OK, it seems to be dates that were created prior to the upgrades. Re-saving doesn’t seem to solve it.
Update: I did some more research and found out that, after all, I’m not supposed to use date_default_timezone_set() with WordPress 5.3. As stated here https://make.wordpress.org/core/2019/09/23/date-time-improvements-wp-5-3/ :
“don’t change PHP time zone with date_default_timezone_set() (this one is hard requirement for correct core operation!)”
So I’m currently working on modifying my functions to work the proper way, by getting the ‘gmt_offset’ option and calculating it to process the current timestamp instead of changing the default timezone. That way ACF seems to work properly, too.
P.S. for a quick albeit unelegant fix, you can restore the timezone to UTC AFTER you do your stuff with your functions that use your specific timezone. So that’ll be
date_default_timezone_set( get_option(‘timezone_string’) );
…do your stuff…
I received this from support:
“The new wordpress update has brought some changes to date_i18n()
I believe the issue you are experiencing is due to a change in the
date_i18n() function causing values to be modified via the timezone setting.
This issue does not effect the value saved into the DB, but occurs when loading and “formatting” the value.
We have a few similar bug reports at this time, and will investigate this shortly.
For now, can you please try the following fix: Edit the file “includes/api/api-helpers.php” on line 4117 and change from:
return date_i18n($format, $unixtimestamp);
return wp_date($format, $unixtimestamp);”
Elliot here – ACF dev.
Thanks for the bug report. I am currently reviewing similar tickets both on our helpdesk and the WordPress trac. This issue looks to be related to the use of
date_default_timezone_set() within WordPress 5.3, and is not specific to ACF, but will also affect other parts of WP such as “scheduled posts’.
Please read this reply from one of the WordPress moderators: https://wordpress.org/support/topic/read-this-first-wordpress-5-3-master-list/#post-12124062
If my prediction is correct, the values saved into the DB (from our date related field types) should be correct. The problem occurs only when loading the value via
get_field() which will “format” the value via the
date_i18n() function, triggering the issue caused by the use of
Please let me know if you are able to resolve this issue by removing the
date_default_timezone_set() function from your theme / plugin. This will provide helpful feedback to myself and the WP team 🙂
date_default_timezone_set() fixed it!
As I said before, I had realized that date_default_timezone_set() was the culprit.
I removed every occurrence of it in my themes/plugins and made a function instead which takes a timestamp or a Ymd as an argument and returns several different date/time formats (also passed via an argument) taking into account the timezone offset from WP. Now I’m using my function instead of date() or strftime() in all my WP projects. Everything seems to run smoothly, including ACF Pro.
We don’t use
date_default_timezone_set() in our themes and are experiencing this issue.
When I try to set a date to 2nd May 2020 it saves the value correctly in the database, but displays it incorrectly (a day behind) in both the admin screen and the front end of the site as per Elliot’s explanation.
@geniusdivision – Thanks for the reply.
Can you please test out the following code in one of your theme template files and report back with the date displayed?
// Arbitrary date-time value. $time = strtotime('2019-11-18 08:30:00'); // Display date. echo date_i18n('F j, Y g:i a', $time);
November 18, 2019 8:30 am
@geniusdivision – Great. This is the correct value expected to be displayed. This same code is used in the ACF date, time and date-time fields to “format” the loaded value.
Can you please try the issue once more making sure to clear any cached data that could interfere with the results?
If the problem persists, I would like to take a look myself and debug the PHP on your site. To do this, please open up a new support ticket with all the relevant information: https://www.advancedcustomfields.com/contact/
@elliot — unfortunately this hasn’t fixed it.
I can replicate the issue with this process:
Here’s a quick video: https://www.dropbox.com/s/n7d3b1iyhyc7scd/1.%20Setting%20Date.mov?dl=0
It may help to know that we use https://roots.io/bedrock/ as a boilerplate for a better WordPress structure, but all our WordPress themes are built from scratch.
I tried changing the WordPress theme to a default one and I still experienced the same issue.
Happy to open up a new support ticket if this doesn’t help!
Just to further update — I will figure this out 😃
@elliot — I think I’ve narrowed the issue down to something to do with Bedrock.
A default install of WordPress with the default theme displays the date correctly from the datepicker field.
I’m now going to install a default version of Bedrock with a default theme and see what this returns.
Is this really solved for everybody ? I’m still getting the issue with only ACF as activated plugin. I noticed the problem happens when I use the classic WP editor, but not when I use Gutenberg.
I’m 99.99% sure the problem you are facing will be due to a
date_default_timezone_set() call in your theme, or other website filed (perhaps wp-config.php).
Please be sure to read this reply from one of the WordPress moderators: https://wordpress.org/support/topic/read-this-first-wordpress-5-3-master-list/#post-12124062
I had looked everywhere… except in wp-config.php !
There was indeed a
Thanks a lot !
So I’ve removed
date_default_timezone_set('America/New_York'); from my function.php page but now all my times for my webinar events have shifted to display a 5hr time difference from the intended start time.
I’m (and I’m sure a few others) are a bit confused on exactly how to fix this issue.
Is this new behaviour to be worked around in the ACF plugin, so we should wait to for an update to ACF is released?
Or is there something we should be fixing? We don’t have anything in the functions file (our issue is on a bog-standard WP install)
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
So excited to see how well ACF @wp_acf and WP Gutenberg blocks work together! Coded my own custom Gutenberg block for a book list page with book image, author and description fields! SO easy to add on and update with new books now! #wordpress #momswhocode #blacktechtwitter— Maeling Murphy, Ph.D. (@maelingmurphy) December 27, 2019
© 2020 Advanced Custom Fields. Subscribe