Forum Replies Created

  • Hi all πŸ‘‹. ACF PRO v5.9.5 is now available and includes the above mentioned fix πŸŽ‰

  • @mrrrlou Fantastic!

  • @mrrrlou Thanks for the reply. Would it be possible to gain access to a staging version of your site for us to debug? Our local tests and showing this patch works, so I’m very interested in diagnosing the issue in your environment.

    One thing that did come to mind is perhaps you had copied the updated JS file into the /assets/js/ folder instead of the /pro/assets/js/ folder? Can you confirm that WP is definitely loading in this updated file?

  • @mrrrlou Can you confirm your browser is not loading cached assets? Please perform a hard-refresh or try a unique browser. Thanks πŸ™

  • Hi all πŸ‘‹. Thank you for your patience whilst we tested and debugged the issue.

    We have successfully identified this issue as a regression in ACF PRO 5.9.4 which caused ACF Blocks to be registered *after* the WP editor instance was initialized. This explains why new blocks could be added whilst existing blocks did not appear on page load.

    Whilst we continue testing of the fix, please find an updated JS file to copy and paste into the pro/assets/js/ folder within ACF PRO. This file contains the related patch and should solve the problem 100% – please comment bellow with your results. The quicker we can get positive feedback from you, the quicker we can release an update πŸ™Œ.

    Dropbox link will be available for 7 days:

  • Thanks @figureone – Glad to have you confirming the fix!

  • @figureone You are absolutely spot-on! Thanks mate.

    I’ve reviewed, tested and implemented a fix to the meta functions which you can find in the following Gist:

    Can you please copy and replace the contents of this Gist into the “includes/acf-meta-functions.php” file and retest the revisions issue?

    Hoping to hear back from you shortly. I’ll continue testing on our end, and can confirm positive results so far.

  • Hi @figureone

    Thanks so much for digging into this. This looks like a major oversight on our behalf! Please allow me to review the source code in detail and I’ll be in touch shortly.

  • Thanks @figureone!

  • Hi all,

    This issue has been fixed in ACF version 5.9.

    Please update when next possible and enjoy the extra features too!

  • Hi all,

    We have released a 5.8.14 update to take care of this bug – thanks again for your help!​​

  • Hi @kuraga

    Thanks for the email,
    Elliot here – ACF dev​​​.

    The PHP filters “the_content”, “the_excerpt” and “term_decription” are run during the output of these values in the theme front-end. They are PHP filters, which won’t affect the WYSIWG field.

    The WYSIWYG field uses a similar, but unique filter, named “acf_the_content”. Using this filter will allow you to customize the WYSIWYG output in your theme.

    The “tiny_mce_before_init” filter is used to cusotmize the tinymce settings. These will affect how the editor saves the value into the DB. In theory, ACF should inherit these settings, but to be extra sure, please checkout the ACF JS filter:

    Hope this helps.


  • Hi @jm_design

    Thanks for the topic.

    Can you please post the PHP used to register your block type?
    I’ll use this to setup a local version of your block and get to work on diagnosing the issue πŸ™‚

  • Hi @herrschuessler

    Thanks for the comment.

    Would you mind opening a support ticket via the following link, with a full explanation of how to replicate the issue? I suspect that there will be a few “variables” at play which will need to align in order to replicate the exact issue πŸ™‚

    * Please ask for me “Elliot” in the ticket πŸ™‚

  • Hi all,

    Just wanted to mention that the Gallery field does indeed support all types of attachments including video files πŸ™‚

  • Hi @dreiqbik

    If you are experiencing preview / draft issues with the classic editor, this is unexpected behavior. Can you please submit a full bug report to our support team?

  • Hi all,

    Unfortunately, we do not yet have a solution for adding classic metabox preview compatibility with the Gutenberg block editor.

    This new editor does not currently save classic metabox data during the preview request, meaning the preview will fail to load preview data and will most likely appear blank – or in some cases, revert to the last saved draft.

  • Hi @gldixon

    This error suggests an “infinite loop”. It is most likely that your callback is triggering the filter which in turn triggers the callback, etc, etc.

    There are many solutions to avoid infinite loops. Using more specific filters, a global variable as a “is doing marker” or even unhooking the filter during callback.

    Wishing you all the best.

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

    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:


  • Hi @mboesken

    Thanks for the comment.

    It is possible that we may need to implement a different strategy for large scale multisites like the one that you are hosting. Would you mind opening a new private support ticket via this link ( and ask for me, Elliot.

    To determine why the page is taking so long to load, we will need to perform some debugging. If possible, please install the Query Monitor plugin and take a look at the Database Queries that are run during this 45s admin page.


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

  • Hi @zethzethdk. The article you are looking for is this one: Adding fields to a taxonomy term –

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

  • @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);
  • 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:

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

Viewing 25 posts - 1 through 25 (of 5,173 total)

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.