Skip to content

Resolving your WordPress Admin ACF Message about "the_field"

How to Prepare for the ACF 6.2.7 Security Update

 

Recently, you may have started to see a notification banner in the backend of your WordPress sites, notifying you of an upcoming change to Advanced Custom Fields (ACF). This was part of the newest release of ACF 6.2.5 on January 16th, 2024 and prepares you for an upcoming release of ACF 6.2.7 in February.

ACF notification banner shown in WP Admin

The coming update addresses an issue where users with a role of Contributor or higher are able to insert HTML (tags like <script> or <iframe>) into ACF fields rendered with the functions the_field() or the_sub_field(). Most HTML tags are considered safe, but certain tags such as <script> or <iframe> can be used for malicious purposes and will no longer be allowed to be displayed using the ACF field, and instead you must use a native WordPress function to display them.

To prepare for this change, and to ensure nothing on our sites break during the update, there are a few steps we at Big Orange Lab are taking.

How BigOrangeLab is preparing our sites for the update

We can identify where each site will be affected by the update by looking under “show details'' in the ACF Pro notification banner. This will show us what fields are being rendered using the_field() or the_sub_field() and contain unsafe HTML.

ACF notification banner shown in WP Admin with details expanded to show affected fields

We can then find where these fields are being used and rendered in the code in the backend of the site and change the code from

<?php the_field( ); ?>

To

<?php echo get_field( ); ?>

This will allow the current <script> or <iframe> tags to continue to render as expected on the site when ACF updates in February.

How you can prepare your site for the update yourself

If you don’t have developers to make these changes for you, here is a more in-depth guide to how you can make these changes yourself. 

(1) Before making any changes to the code on your site, it is highly recommended that you run a backup through WPEngine (or your Hosting Provider) and test the changes on a development or staging environment first. If anything breaks while you are editing, be prepared to restore your site from this backup.


(2) Check if you received a notification from ACF that some of your fields will be affected by the security update. You can find this notification as a banner at the top of your screen when logged into wp-admin.

ACF notification banner shown in WP Admin

(3) Click “show details” to expand the banner and take note of which fields will be affected. 

(4) This update will require a code change, so it is important that you have access to the code files in the backend of your site. You can find these files by either connecting to your site with SFTP or by going to the “Theme File Editor” in WP admin under the “Appearance” tab.

 

Locate the Theme File Editor to find the code files for your site

You can sort through your code files for your theme in the right hand column and see and edit the code on the left.

 

(5) Search through the php files to find where the affected fields are being rendered with the_field() or the_sub_field(). Note that these may show up in multiple places across multiple files.

For example, if the ACF notification listed something such as 

  • field_name (field_name) - rendered via the_field()

you will likely find a line of code similar to <?php the_field(‘field_name’); ?> somewhere within your theme files.

 

(6) Change:

the_field() to echo get_field(

or  

the_sub_field() to echo get_sub_field() 

 

For example, If you find a line of code that looks like  <?php the_field(‘field_name’); ?> with the field in the parentheses being one flagged by ACF, change the line to <?php echo get_field(‘field_name’); ?>.

 

(7) Save your changes, then clear your website’s cache and check your site again to see if everything is still rendering correctly and nothing is broken.

 

(8) You can verify that you have resolved the ACF change by dismissing the notification and reloading the pages where the affected fields are. If the notification returns, there are still issues that need to be addressed. If the notification does not reappear, you are done preparing for the update.

 

Note: the notification will only come back once a page that renders an affected field is loaded. 



What to do if you can’t make these changes in time

 

ACF has stated that they will be releasing the 6.2.7 update in late February. If you are unable to make the necessary changes to your site in time to prepare for this update, here are a few things you can do to ensure your site does not break.

 

  • Don’t update ACF until you are ready. Make sure auto-updates are disabled and exclude it from plugins like Smart Plugin Manager so you can retain an earlier version of ACF until your site is prepared for the update to 6.2.7.

 

  • Update ACF, but first insert the line 

 

apply_filters('acf/the_field/allow_unsafe_html', false);

 

into your functions.php file. This will disable the changes that disallow unsafe HTML in the_field() and the_sub_field() meaning that even when ACF updates, the changes won’t take effect on your site.

 

This solution is only recommended as a temporary fix as it keeps the security vulnerability active even after updating ACF. It is recommended to remove these lines once you are able to follow the steps in the previous section to minimize the risk of unsafe HTML being inserted on your site.

Opt-in to the update early

If you are confident your site is ready for this security change and would like to have it applied to your site before the February release of ACF 6.2.7, you can add a line of code to your functions.php file to opt-in to the new behavior early:

add_filter( 'acf/the_field/escape_html_optin', '__return_true' );

Only do this if you are sure your site is ready for the update and you have already completed the other steps in this post to ensure none of your fields will break.