ACF Chat Fridays: ACF 6.2.5 Security Release – Round 2

ACF Chat Fridays are one of the best ways to ask questions and share your feedback with members of the ACF development team. Sessions are held every two weeks.

The February 2nd session of ACF Chat Fridays again brought the focus to user questions surrounding ACF 6.2.5.

Co-hosted by Iain Poulson, Matt Shaw, Liam Gladdy, Anthony Burchell, and Brian Hardie.

Sign up for the next session →

Session Recording

You can see the entire session in the player below, or catch the highlights in the session summary.

Session Summary

Liam Gladdy started the session by noting that ACF 6.2.5 and upcoming security releases would form the main topic for discussion.

ACF 6.2.5 introduced escaping via wp_kses for ACF fields output using the ACF shortcode, as well as adding notices to alert users similar changes for the_field() and the_sub_field() functions coming in ACF 6.2.7.

Q&A

The questions at the latest session continued to dive into the details of ACF 6.2.5. We’ve included some of the questions and answers from the latest session below, with minor edits made for clarity and style.

Q: I inherited a site built by someone else, and one issue I ran into was that they used a WYSIWYG field, and used the_field() to display it, but when I tried to put in a Gravity Forms shortcode, it kind of blew up! Using wp_kses here shows the raw data, rather than the form. How do I deal with shortcodes, especially Gravity Forms? It seems like there are two enormously popular plugins that seem to be butting heads.

A: The good news is you don’t need to do anything in this case except turn off the warning. We escape the WYSIWYG slightly differently from the way Gravity Forms does it. We escape it before we let shortcodes pass. In this case, you can just leave it as the_field() and turn the warning off with a filter:

add_filter( 'acf/admin/prevent_escaped_html_notice', '__return_true' );

When you’re running wp_kses, it strips out the script tags, which is why you’re seeing the raw data that would normally be embedded in the script tag.

Q: I’m not sure why I’m getting the warning on some sites but not on others. I don’t understand why certain fields are being called out when they’re all identical. I use ACF the same on all my sites: I build a form, have people plug things in, and then I can design the page. The fields are mostly text. I might have a True/False in there, but by and large they’re pretty simple. I’m not sure why the warning would show up on just a few sites, and not on the others.

A: This is another case where you can likely just ignore the warnings. One of the reasons that the warning shows is because it’s showing you things like an ampersand or quote symbol will become encoded to what it’s supposed to be for output to HTML without it being read as HTML. It’s essentially just a warning to say “something’s changed.” We needed to show that because if you were outputting that directly into something like JavaScript or an attribute, it could be a breaking change.

You can check each of your sites by installing the update, switching it on to see if anything breaks, and then switch it off again. Alternatively, if you really want to dive and check the values that are being saved, you can use the ACF Escaping Debug Plugin. That will store more detailed errors of the previous and new values of those fields, so you can see exactly what’s changing.

Q: A lot of what I am running into with the notices and I am finding it that the inline CSS is updated. So…

<span style=“color: #000; text-align: center;”>

Becomes…

<span style=“color: #000;text-align: center”>

This is just a removal of the space between properties and the “;” at the end. Everything still displays correctly.

A: That’s specifically to do with the TinyMCE that WordPress ships with and we use for the WYSIWYG field. If you put styles in, the way TinyMCE builds that is to put a trailing semicolon on the end of your style attribute. WordPress removes it when it does the escaping, so ACF detects that as a change. You can safely ignore these kinds of warnings.

Q: I inherited a site and I’m not super familiar with Advanced Custom Fields, but one of the errors that comes up for me is saying that using the_sub_field() isn’t going to work. In the release post, you talk about using echo get_field() to output unsafe HTML to make sure it’s not filtered.

Should I be using echo get_sub_field() to show those properly? We have a lot of iframes, scripts, YouTube embeds and so on.

A: You can use echo get_sub_field(), but it’s worth checking first to see what kind of content is being output on the page and the field type that was reported. If an embed is in a WYSIWYG field and it’s the YouTube URL, and we let oEmbed take care of putting the YouTube video in, then that would continue to work, but it sounds like you’re going to need to take a closer look just to make sure that it isn’t literally an iframe tag saved to a Text Area or WYSIWYG field.

Using echo get_sub_field() basically turns off escaping for the field. This comes with some risk, as whatever gets put in that field will be output to the frontend of the site. As long as you’re positive your users are locked down with secure passwords and similar, you should be okay.

Q: Are you saying that if the fields only contain text, the update will work properly?

A: Yes, but if those text fields contain script tags, that’s what is going to be rendered on the frontend. Your site won’t crash or anything like that, but it will render whatever is saved in that content instead of outputting what you would expect, like an iframe or similar.

Q: Is there a backup or way to rollback the plugin after enabling the new behavior?

A: It’s possible to disable the new behavior for certain fields. Alternatively, as one of the forum participants pointed out, if you’re using Composer with ACF, you can lock a version or go back a version, and then go back to the point where it wasn’t breaking and give yourself some time to make any necessary fixes.

Q: I tried disabling the new function, as I’m the only editor/admin/owner on the site. I added it to my functions.php file and received an error. Are there variables that need to be replaced in the below?

add_filter( ‘acf/shortcode/allow_unsafe_html’, function($allowed, $atts) { return true;}, 10, 2);

add_filter( ‘acf/the_field/allow_unsafe_html’, function($allowed, $atts) { return true;}, 10, 2);

A: You can use the shortened version below:

add_filter( 'acf/shortcode/allow_unsafe_html’, '__return_true' );`

add_filter( 'acf/the_field/allow_unsafe_html’, '__return_true' );`

The filter to allow the_field works for both the_field() and the_sub_field(). We would still advise against doing this, even if you are the sole user/editor/admin. These filters are basically saying “any ACF field can contain any HTML,” but it’s impossible to predict what vulnerabilities will arise in other plugins or even WordPress itself. You could wind up with postmeta being updated with malformed or malicious data, so we wouldn’t recommend just turning it off globally.

It’s probably better to put it in a custom plugin rather than changing functions.php, as a theme update could wipe out that change.

Resources & Links

We share relevant resources during the call. We’ll sum them up here and try to provide a bit of context:

• The WP Minute: Big Changes Coming to ACF
• ACF 6.2.5 Release Post
• ACF Escaping Debug Plugin
• ACF Enable Escaping & Disable Notification Plugin
• ACF Emails and News
• Sign up for ACF Beta News
• ACF’s Feedback Page

Coming Up on ACF Chat Fridays

Join us on March 1st, 2024 at 3pm UTC for the next session of ACF Chat Fridays. This session will include more discussion of ACF 6.2.5, but feel free to bring questions about other topics, successful use cases, and anything else you’d like to discuss with the development team.

What do you think we should cover throughout 2024? Let us know on Twitter.

Sign up for the next session of ACF Chat Fridays here:

https://wpeng.in/acf-chat-fridays/

The list of upcoming sessions is below.

• March 1, 2024
• March 15, 2024
• March 29, 2024
• April 12, 2024

Tag or DM us on Twitter to let us know you’ll be there. Suggest new topics, let us know what you’d like to see, and send us feedback with #ACFChatFridays on Twitter.

About the Author

For plugin support, please contact our support team directly, as comments aren't actively monitored.