Support

Account

Register Login

Home › Forums › Bug Reports › Date Picker fields in Repeaters gone wrong after WP 5.3 update

Solving

Date Picker fields in Repeaters gone wrong after WP 5.3 update

  • 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:

    date_default_timezone_set(‘Europe/Rome’);
    setlocale(LC_TIME,’it_IT’);

    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.

    HELP!

  • 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…

    date_default_timezone_set(‘UTC’);

  • 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);
    to:
    return wp_date($format, $unixtimestamp);”

  • Hi all,

    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 date_default_timezone_set().

    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 🙂

  • Removing 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);

  • It displays: 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:

    1. Save a date in the backend of 2nd May 2020.
    2. Save the post.
    3. When the date is reviewed in the backend and the frontend the date is now displaying May 1st 2020.
    4. When I reviewed the data in the database it’s saved correctly as May 1st 2020.

      5. 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.

  • After all of this, I found a rogue instance of date_default_timezone_set("Europe/London"); in one of our plugin files.

    When I have removed this everything is back to normal. Thanks for your help @elliot, this can be considered closed for me now.

  • 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.

  • Hi @mikemwm-webdesign-com

    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 date_default_timezone_set() there.

    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)

  • Same behaviour here. If I use get_post_meta() instead of get_field(), it returns the correct value.

  • Hi all,

    It’s been some time since the WordPress 5.3 release, but it appears this timezone issue is still affecting ACF users. I sympathize for you, and hope the following info can help.

    Unfortunately, this issue is not an ACF bug that can be fixed from our end.

    The issue stems from a change in WordPress 5.3 that alters the behavior of the date_i18() function. This function is used in ACF to “format” the saved value based on the field’s settings.

    Since the update, WordPress now expects the default timezone to be UTC, which is causing a widespread incompatibility with the date_default_timezone_set() function.
    Please read this comment: https://wordpress.org/support/topic/read-this-first-wordpress-5-3-master-list/#post-12124062

    The only known solution is to remove any occurrence of the date_default_timezone_set( ) function from your site. This should first be tested, as each website is different and may require additional changes to avoid timezone related date problems.

    You may also find some useful info on this announcement here:
    https://make.wordpress.org/core/2019/09/23/date-time-improvements-wp-5-3/

    Thanks
    Elliot

Viewing 25 posts - 1 through 25 (of 27 total)
1 2

The topic ‘Date Picker fields in Repeaters gone wrong after WP 5.3 update’ is closed to new replies.