ACF escaping unsafe HTML - how to identify affected pages

PUBLISHED 6 Mar 2024

If the ACF plugin is displaying a notice in your WordPress dashboard about escaping unsafe HTML, you'll want to know what pages are affected and what changes are being made to them. Here's how to do that without being a pro developer.

A recent update to the WordPress plugin ACF (Advanced Custom Fields) means that two of its functions, the_field() and the_sub_field(), now only output safe HTML by default. That's great for security, but ACF 'escaping' HTML in this way could be a breaking change on some sites. In particular, <script> tags and <iframe> tags get stripped out.

From ACF version 6.2.5 (released 16 January 2024), sites started showing an admin notice (notification) in the WordPress dashboard if they were going to be affected by the upcoming changes; version 6.2.7 (released 27 February 2024) actually brought the changes into force.

The ACF blog has instructions on how to 'fix' this issue. For example, you might want to add a filter to stop <iframe> tags being stripped. However, before you can decide what to fix (and even whether you need to), you first have to understand how your site is affected. By that I mean, what pages are affected and what content is being changed.

This is easier said than done, especially as ACF's instructions are very much aimed at developers. So I wanted to add a little extra detail based on my own investigations as a non-developer, and how I put my mind at rest as regards one of my clients' sites.

The log in wp_options

Initially, I was very interested in the log that ACF mentions in its instructions:

Whenever we detect that escaping the field value has modified the output value, ACF will log data about the affected function call... This log is stored as an option in the wp_options table.

I found the option it is referring to using phpMyAdmin (a tool that your web host should be able to provide you with). Here's what it's called:

  • acf_will_escape_html_log (ACF version 6.2.5)
  • acf_escaped_html_log (ACF version 6.2.7)

However it's not very useful as it only logs the affected function call(s), and not other details such as post ID or the specific changes being made to content. Here's an example value:

a:2:{s:19:"field_5e207f87089ab";a:4:{s:8:"selector";s:9:"left_text";s:8:"function";s:13:"the_sub_field";s:5:"field";s:12:"Left Content";s:7:"post_id";b:0;}s:19:"field_5e20802bc53ce";a:4:{s:8:"selector";s:10:"right_text";s:8:"function";s:13:"the_sub_field";s:5:"field";s:13:"Right Content";s:7:"post_id";b:0;}}

Here's what that looked like in phpMyAdmin:

ACF escaped HTML option in phpMyAdmin

So this tells me that the output of the 'Left Content' and 'Right Content' fields is being modified (when rendered by the_sub_field function), but not much else. This is basically the same information that is displayed in the notice on the WordPress Dashboard. And that's much easier to read and understand:

Warning in WordPress dashboard from ACF Pro about unsafe HTML being escaped

So the log is a red herring, and you might as well just use the admin notice.

Testing individual pages

One interesting tidbit from ACF's instructions is that dismissing the admin notice in WordPress clears the log. You can use this to test individual pages to see whether any content is being changed. Here's how:

  1. Spin up a staging site (a copy of your website that only you can access). Your web host should give you the option to do this.
  2. On the staging site, make sure the ACF log is clear - dismiss the admin notice in the WordPress dashboard if you see it. (If you don't see the notice, the log is already clear.)
  3. On the staging site, visit the page you want to test.
  4. Reload the WordPress dashboard on the staging site (you can hit F5 to do this). If the page you just visited is affected by the ACF changes, the notice will reappear.
  5. On the notice, click 'Show details' to see which field(s) specifically have been changed on that page.

The reason you do this on a staging site is that it allows you to test pages one at a time. If you tried the same thing on your live (production) site, your site visitors would visit your pages, populate the log and trigger the notice - so you wouldn't know which page/s were responsible.

Identifying changes

Also, if you have ACF version 6.2.5 installed on the live site and 6.2.7 installed on your staging site, you can compare the two versions of the page (in the front end) to see whether there are any breaking changes.

You can even paste the page source of both versions of the page into a tool like to see what exactly is being changed. (Remember that absolute file and page paths may be different on your staging site to your live site, and that's OK.)

I did this for one of my client's sites and I could see that ACF was changing this code in a field:

<span style="text-decoration: underline;">

To this code:

<span style="text-decoration: underline">

Difference in page source code when HTML is escaped by ACF

In other words, stripping a semicolon that wasn't necessary anyway. So definitely not a breaking change!

Removing the semicolon from the field value on the live site stopped the admin notice from triggering. So not only could I reassure my client that it wasn't a breaking change, I could also 'fix' the issue and prevent the client from worrying about an ambiguously worded warning.

Notify of
Inline Feedbacks
View all comments
James Clark
Hi! I'm James Clark and I'm a freelance web analyst from the UK. I'm here to help with your analytics, ad operations, and SEO issues.
What do you think? Leave a commentx
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram