@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?
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: https://www.dropbox.com/t/gTRoawP1TRGUgXT3
@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: https://gist.github.com/elliotcondon/9d3f3f94b51581150b434e3cd7c566cd
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.
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.
Hope this helps.
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 🙂
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?
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.
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.
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
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:
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 (https://www.advancedcustomfields.com/contact/) 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.
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
Hi @zethzethdk. The article you are looking for is this one: Adding fields to a taxonomy term – https://www.advancedcustomfields.com/resources/adding-fields-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: https://www.advancedcustomfields.com/contact/
@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);
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 🙂
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!
© 2021 Advanced Custom Fields. Subscribe