Support

Account

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.

    • splet

    • November 16, 2019 at 12:41 am

    Hi I’m facing the same issue. WordPress 5.3, reverting ACF to 5.8.3 had no effect.

    • A.Mason

    • November 16, 2019 at 10:54 am

    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);”

    • Elliot

    • November 19, 2019 at 2:08 pm

    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 πŸ™‚

    • Tim

    • November 20, 2019 at 3:52 am

    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.

    • Elliot

    • November 20, 2019 at 10:21 am

    @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

    • Elliot

    • November 21, 2019 at 9:39 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.

Viewing 18 posts - 1 through 18 (of 18 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.