Held biweekly, ACF Chat Fridays are our open office hours, a forum for users to bring questions, share best practices and use cases, and get tips directly from the development team.
The January 19th edition of ACF Chat Fridays focused on user questions regarding ACF 6.2.5, an important security release that adds escaping to the ACF shortcode when it’s used to output a field.
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
Iain Poulson kicked off the session with an outline of the recent release of ACF 6.2.5, noting it patched a security vulnerability, but doing so meant changes had to be made to the ACF shortcode, with further changes likely coming in ACF 6.2.7.
In brief, from ACF 6.2.5, using the ACF shortcode to output an ACF field will be escaped by the WordPress HTML escaping function wp_kses. ACF 6.2.7 will introduce similar changes for the_field() and the_sub_field() functions. Notices have been added to ACF 6.2.5 to alert you that your WordPress site is outputting HTML that will be altered by the escaping that will be introduced in 6.2.7.
Prior to ACF 6.2.5, it is possible for a user with a role of contributor or higher to manually set the value of a custom meta item outside of ACF to contain malicious HTML, and then use the ACF shortcode to output the HTML in an unsafe manner. ACF 6.2.5 detects when unsafe HTML has been removed from a field value output by the ACF shortcode. ACF then shows a message in the WordPress admin, listing the fields affected by the change.
Two plugins have been released that can be used to help debug changes:
ACF Escaping Debug Plugin: For performance reasons, the warning notices generated by ACF 6.2.5 are limited to the name of the field, the selector used to output the value, and the function called. This plugin extends that default logging to output a more detailed version whenever it is detected. The output is sent to the PHP error log via
error_log. This plugin should not be used on production, as it has potential to generate a log of error log messages.ACF Enable Escaping & Disable Notification Plugin: We know some users just want to enable the new behavior immediately and check their site’s front-end to see if anything has been removed, rather than try to debug it from the notices. This plugin immediately enables the new behavior planned for ACF 6.2.7, actually escaping the content, and turns off the notices in the admin.
Both plugins can be used together to disable notices, enable the new escaping so you can see on the front end if forms or other iframes/scripts are removed, and then get changes logged to the PHP error log.
Q&A
The latest session highlighted that ACF Chat Fridays is one of the best places to bring questions about ACF. The questions under discussion touched on practically every aspect of ACF 6.2.5, and also what users can expect to see from future releases.
We’ve included some of the questions and answers from the latest session below, with minor edits made for clarity and style.
Q: Does the escaping only happen if we use the ACF shortcode, but not if we use something like the_field or get_field?
A:: In 6.2.5, this only happens for the ACF shortcode, but in a future release (likely
6.2.7), it will also happen when using the_field or the_sub_field. However, ACF 6.2.5 displays a warning when the_field or the_sub_field are being used in a way that could output unsafe HTML. The warning message is included to give you a chance to get ahead of this change.
Q: Will ACF 6.2.5 automatically detect all instances of unsafe HTML right after the update?
A: Notices are only triggered when the field values are rendered, i.e., when the page is requested. ACF has to render the output first to drive the notice. Pages that don’t receive traffic won’t need to render their fields, so the notices will not be generated.
Q: Does the admin warning in ACF flag all uses of the the_field() within the theme files, or only if it detects problematic content?
A: The warning only appears when an ACF field tries to output content, the escaping has (or will) been done, and the escaped value is different from the original value.
Q: I’m seeing a message in the dashboard, relating to a sub_field being pulled in. It looks like innocent HTML to me. Does this mean there will be a problem with the escaping or is it a false positive?
A: It’s possible to get some false positives, usually when there are special characters being converted into HTML entities. The ampersand is the most common we’ve seen so far, so if you have an ampersand in your post or your field value it will be converted into the HTML entity version. This should still render fine in the browser, so you wouldn’t need to make any code changes. In addition, WYSIWYG fields which contain inline styles may have their attributes cleaned up by the escaping which will result in a change being detected. For example, <a style=”font-weight: bold;”> would be cleaned up to <a style=”font-weight: bold”> and this would be detected as a change.
You can enable stripping unsafe HTML immediately if you’re confident that you’re already securely escaping your output where necessary. We recommend enabling it on a local site or development environment first to make sure it’s rendering properly and none of the content looks strange, especially content that’s being flagged.
Q: For the upcoming release, are you saying that any and every instance of the_field() or the_sub_field() will need to be changed to get_field() or get_sub_field()?
A: No, and for security you should not do this. Certain fields aren’t going to have HTML stored in them. Even if it does have HTML, and it’s not something that could be flagged as potentially unsafe, you can keep using the_field() and the_sub_field(). Most HTML is considered safe by default. It’s mostly things like <script> and <iframe> tags that will get stripped out.
This is a situation where you can test by opting in early on a development site and make sure the content is still being rendered as it should be.
If you’re having trouble identifying what content is actually getting flagged, Liam made an excellent plugin that allows you to start logging what we’re flagging in a more detailed way, showing what the content looked like before and after, so you can get a better idea of what’s being changed.
Q: Will this impact WYSIWYG fields when pasting in YouTube and other links that automatically create YouTube embeds?
A: Nope, we’ve handled that too! We remove unsafe HTML, and then handle embeds after that. So just YouTube links becoming iframes is fine. The oEmbed field also renders iframes by default. That will continue to work with the_field() and the ACF shortcode.
Q: What page of the WordPress admin shows the alerts from ACF?
A: They’re present on every page. Given that it may require code changes, we thought it would be best to make the alert system wide.
Q: Is there a way to trigger the notice to ensure that ACF is successfully catching any unsafe usage? My thought is testing for false negatives, essentially.
A: There’s two notices you might see. The one for the shortcode is a red notice, letting you know it’s being escaped already, and a separate notice for the the_field() and the_sub_field(). You’ll have to render with either the shortcode or the_field() or the_sub_field() for that notice to show up, and then visit the page on the front end so that those functions run and can log the notice.
Q: I can test for this locally just fine, but checking in production is a little more difficult. Could I run something in production that looks in the postmeta table for ACF field values and checks if there is any data stored that would be impacted by the change? I can test locally and see no notices, but I don’t know what a user might have stored in production.
A: We’d recommend cloning the production database and then running a script to do that locally, so you’re not running potentially expensive queries. This might not pick up every user change if you’ve got a very fast changing site, but it should catch most of them.
It is certainly possible to write a script to crawl a local copy of your site and find every instance of potentially unsafe HTML. We didn’t want to include that as default behavior in the update, as it would result in a lot of processes being run on sites where it wasn’t really necessary.
If you absolutely need to test on production, we recommend using the debugging plugin so you can get more detailed error logs, then turning on the update very briefly before turning it back off. Then you can start combing through your error logs. Doing this may impact your traffic, so we’d be very wary of doing this if you have a high traffic site.
ACF 6.2.5 doesn’t do any of the default escaping for the_field() or the_sub_field(), but it does detect them, so you could update ACF, get the notices, and get it fixed before we ship the version of ACF that escapes those by default.
Resources & Links
We share relevant resources during the call. We’ll sum them up here and try to provide a bit of context:
- 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 February 2nd, 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.
- February 2, 2024
- March 1, 2024
- March 15, 2024
- March 29, 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
Mike is the Senior Editor of Delicious Brains. Based in Hamilton, Ontario, he has an extensive background in business-to-business communications and marketing. His hobbies include reading, writing, and wrangling his four children.