This release contains several bug fixes and improvements, including a new way to return an escaped value from get_field() and related functions.

Please find the release notes below. And for the latest ACF news, follow us on Twitter @wp_acf.

Easier Escaping for get_field() and Related Functions

In previous versions of ACF we’ve recommended using the WordPress core escaping functions for escaping data that will be output to your theme or plugin using get_field() or similar get_ functions. That could look something like the following:

$value = get_field( 'text_field' );

if ( $value ) {
    echo wp_kses_post( $value );
}

Ahead of 6.2.7’s upcoming changes later this month to enable escaping automatically in the_field and the_sub_field, in ACF and ACF PRO 6.2.6, we’ve added a new optional $escape_html parameter to get_field() and similar functions that can be used to return the ACF escaped value:

get_field( $selector, $post_id = false, $format_value = false, $escape_html = false );

This optional parameter is set to false by default, which means that any existing code using get_field() or similar get_ functions will be unaffected by this change. Additionally, it requires that the $format_value parameter is set to true, otherwise an incorrect usage notice will be thrown and the field value will not be returned.

Using this parameter, rather than escaping the value yourself, allows field type specific escaping to take place. For example, the WYSIWYG field performs its escaping before shortcodes and other the_content filters are applied, meaning shortcodes which generate iframes or script tags aren’t removed.

Here’s how the example above could look with the new parameter:

// Passing true as the fourth parameter will apply wp_kses() with the acf context.
$value = get_field( 'text_field', $post_id, true, true );

if ( $value ) {
    echo $value; // XSS ok.
}

For most field types, the value will be passed through wp_kses() with the acf context, which allows for filtering the allowed HTML as shown in our HTML Escaping doc. Some field types, such as the WYSIWYG field and the oEmbed field, have their own escaping methods and will apply those automatically.

The optional $escape_html parameter has been added to the following functions:

• get_field()
• get_fields()
• get_field_object()
• get_field_objects()
• get_sub_field()
• get_sub_field_object()

6.2.6.1 Changelog

• Fix – Fatal JS error no longer occurs when editing fields in the classic editor when Yoast or other plugins which load block editor components are installed
• Fix – Using $escape_html on get functions for array returning field types no longer produces an Array to string conversion error

6.2.6 Changelog

• Enhancement – The get_field() and other get_ functions now support an escape_html parameter which return an HTML safe field value
• Enhancement – The URL field will be now escaped with esc_url rather than wp_kses_post when returning an HTML safe value
• Fix – ACF fields will now correctly save into the WordPress created revision resolving issues with previews of drafts on WordPress 6.4 or newer.
• Fix – Multisite subsites will now correctly be activated by the main site where the ACF PRO license allows, hiding the updates page on those subsites
• Fix – Field types in which the required property would have no effect (such as the tab, or accordion) will no longer show the option
• Fix – Duplicating a field group now maintains the current page of field groups being displayed
• Fix – Fields in ACF Blocks in edit mode in hybrid themes will now use ACF’s styling, rather than some attributes being overridden by the theme
• Fix – Text in some admin notices will no longer overlap the dismiss button
• Fix – The word link is now prohibited from being used as a CPT name to avoid a WordPress core conflict
• Fix – Flexible content layouts can no longer be duplicated over their maximum count limit
• Fix – All ACF notifications shown outside of ACF’s admin screens are now prefixed with the plugin name
• Fix – ACF no longer checks if a polyfill is needed for <PHP7 and the polyfill has been removed.

The post ACF 6.2.6 appeared first on ACF.

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.

The post ACF Chat Fridays: ACF 6.2.5 Security Release – Round 2 appeared first on ACF.

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 get_field. However, ACF 6.2.5 displays a warning when the_field or get_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.

The post ACF Chat Fridays: ACF 6.2.5 Security Release appeared first on ACF.

This release is a security fix release containing an important change you need to be aware of before you update, and prepares for a change to the output of the_field coming soon to ACF.

From ACF 6.2.5, use of the ACF Shortcode to output an ACF field will be escaped by the WordPress HTML escaping function wp_kses.

This has potential to be a breaking change if you’re using the shortcode ([acf field="field_name"]) to output potentially unsafe HTML such as scripts or iframes for textarea or WYSIWYG fields.

At ACF, we take security very seriously, but we also consider the impact that security fixes can have on your sites. To help site owners that are impacted by this release identify what fields are affected, the plugin will display a notice in WordPress admin screens, alerting you whenever some output has been escaped by this change.

From ACF 6.2.7, expected in February 2024, escaping unsafe HTML will also apply to other functions where ACF handles outputting the value of a field, namely the the_field() and the_sub_field() functions. To help get ahead of the impact of this future change, we’ve also added a notice in ACF 6.2.5 alerting you that your site is outputting HTML that will be altered by the escaping coming in 6.2.7.

This fix is necessary due to a vulnerability where users on your site with the role of contributor or higher, who do not have the unfiltered_html permission usually reserved for administrators, can manually set the value of a custom meta item outside of ACF to contain malicious HTML. Because of the vector, our usual sanitization on the save action will not apply. They could then use the ACF shortcode to output that HTML in an unsafe manner.

ACF 6.2.5 will detect when unsafe HTML has been removed from a field value output by the ACF Shortcode. An error message will be displayed in the WordPress admin, listing the fields which have been affected by this change, helping you diagnose where you may need to make fixes.

We’d like to thank Francesco Carlucci and the Wordfence team for the responsible disclosure of this vulnerability specific to the ACF Shortcode.

Upcoming Changes to the_field()

When testing the above change to resolve the vulnerability, we realized there were further actions we could take to improve security when ACF handles the output of a field. Specifically, the functions the_field() and the_sub_field() should also be made HTML safe by default.

Whilst we’re aware many users store HTML in fields which they do want rendered to the front-end, as these functions do not allow users to apply any escaping themselves, we feel it’s our responsibility to ensure any output from these is safe.

From ACF 6.2.5, we begin detecting when the escaped value is different from the currently output value, indicating that something is being removed from a field’s value. A list of affected fields and how they’re being output is shown as a message in the WordPress admin. This message is visible to every user of your admin, but the details of the field names and functions are only visible to users with the ability to use ACF admin screens.

In ACF 6.2.7, currently expected to release in late February 2024, we will change this behavior to strip unsafe HTML by default when the_field() or the_sub_field(), showing an error in WordPress admin when this has happened.

To be clear, we are not deprecating or removing the_field() or the_sub_field(), we are just ensuring it can only output safe HTML by default.

Disallowed HTML tags

By default, most HTML is considered safe. Things like images or tables present no risk and so the WordPress kses system which powers this escaping allows it by default. Only HTML which could be used for malicious purposes, such as <script> tags, or <iframe> tags are removed, and this is additionally configurable.

The list of allowed HTML and attributes is visible in the WordPress source code and includes the majority of HTML elements, except for iframes and scripts which can cause the browser to run third-party code.

We also pass the acf context to wp_kses, so if you wish to expressly allow certain HTML tags only for ACF, you can define this as detailed in our HTML escaping documentation.

How to use ACF securely

As a developer with ACF, we’re aware you may have a use case of storing HTML which needs to be output in an unsafe manner, such as using a Text Area field to store the full <script> tags which should be output to allow your users to edit this.

In these cases—and if you’re confident you can trust every user registered on your site with contributor or higher access—we recommend you use echo get_field() to output this unsafe HTML to ensure it’s not filtered.

For all other fields, we’d also recommend using get_field to output the value, but making sure you apply the right escaping for the type of field you need. This is likely to be something like the wp_kses_post function, for example:

echo wp_kses_post( get_field('field_name') );

Field type changes

As part of these changes, we’ve also introduced some changes across ACF to enable developers to allow HTML where they need to.

We’re aware some field types are designed to output HTML. For ACF’s default field types, specifically the oEmbed field type is designed to output an <iframe>, and the WYSIWYG field is designed to automatically handle embedding videos which may also be iframes. In the case of the WYSIWYG field, you’d still want unsafe HTML to be removed, but then allow oEmbeds to work, for example.

To support this, we’ve added a way for field types to mark that they will handle the escaping of HTML when requested, via a new parameter $escape_html. The new parameter is available on get_field and get_field_object, and is passed all the way through to the fields format_value method. This means if the field type supports handling escaping itself, setting this to true will get that escaped value. This argument should not be used by end users, as it additionally requires a check to make sure the field type has been updated to support escaping its own HTML. For every core ACF field other than WYSIWYG, this property will currently have no effect on the value.

In the case of the WYSIWYG field, this means the field will escape HTML before it runs the_content filters which handle embedding. For more information on the changes to field types which may affect third-party fields, please see our documentation for creating a field type.

Detection and notice information

Whenever we detect that escaping the field value has modified the output value, ACF will log data about the affected function call.

Any detected modification will trigger the log, but it may not necessarily be a breaking change. For example, & become & when escaped. This would be detected as a modification, but is unlikely to be a problem as it will still be rendered normally in the browser. In these cases you do not need to make any code changes, instead you can leave the upcoming automatic escaping to work correctly.

This log is stored as an option in the wp_options table. Whenever this log contains entries, the notices in WordPress admin will be shown for all users with the “Editor” role and higher by default. Users with the ability to manage ACF will have the option to view the full details. Users without the ability to manage ACF will be asked to contact their site admin about the error.

Admin users have the ability to dismiss the message, which will also clear the log. Dismissing the notice after you’ve made fixes will allow you to verify you’ve fixed every instance, as the message will not return after the affected pages have been loaded.

If you want to disable the error messages entirely, this is also possible via the following filter:

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

This filter will also disable the log being populated when set to true. You can hide the notice on admin pages while retaining the log system on the front-end by ensuring you only add the filter in an is_admin() check, and including the necessary logic to limit it to specific users or roles.

Additional debugging options

The logic between the shortcode vulnerability fix and the_field change is similar, and debugging instances where we will strip (from ACF 6.2.7) or are currently stripping in the case of the shortcode is the same.

ACF fires two new actions, acf/removed_unsafe_html and acf/will_remove_unsafe_html.

These actions provide 4 different parameters:

• $function – This is the name of the function triggering the action, acf_shortcode, the_field or the_sub_field.

• $selector – This is the selector that was passed to the function. This matches what is sent in by your theme (or the shortcode).

• $field – This is the computed full field object for the request object. This will contain the field key, type and other information which can help you find the affected code in your theme.

• $post_id – This will be the $post_id provided to the function. This may be false if it’s not provided when the current global post ID is used.

Attaching a function to this action in debugging would allow you to access functions like debug_print_backtrace or Xdebug’s xdebug_break functions on your development environments if you need to find more information on exactly where in your theme or custom code the unsafe HTML is removed during output. We’ve produced a demo WordPress plugin which adds additional debug logging to your PHP error log as an example of this.

Conditionally disabling the new behavior

If you trust your users with the role of contributor or higher, it is possible to use one of two new filters to disable this automatic escaping by returning true. You should limit the filter to specific field keys using the additional parameters available.

• acf/shortcode/allow_unsafe_html will disable the escaping for the shortcode.
• acf/the_field/allow_unsafe_html will disable the escaping when using the_field.

The filters provide different arguments should you wish to allow unsafe HTML for a specific field type, on a specific page, or for a specific field name or key.

The shortcode filter provides you the field type and the full attributes array passed into the shortcode, along with the full field object if available:

apply_filters( 'acf/shortcode/allow_unsafe_html', false, $attributes, $field_type, $field_object )

For example, if you’re using [acf field="podcast_iframe"] to output an iframe, you could use the following code to allow that field to output potentially unsafe HTML (the iframe)

add_filter( 'acf/shortcode/allow_unsafe_html', function ( $allowed, $atts ) {
    if ( $atts['field'] === 'podcast_iframe' ) {
        return true;
    }
    return $allowed;
}, 10, 2 );

The filter for the_field() (and the_sub_field()) provides you with the field selector provided to the output function, the post ID (if provided), and the field type. It also provides you the field object which will contain the field key (but may be false if ACF wasn’t able to find the field reference).

apply_filters( 'acf/the_field/allow_unsafe_html', false, $selector, $post_id, $field_type, $field_object )

For example, If you’ve got a field called google_maps_iframe which contains an iframe of a google map, the follow code would allow it to still be output by the_field:

add_filter( 'acf/the_field/allow_unsafe_html', function( $allowed, $selector ) {
    if ( $selector === "google_maps_iframe" ) {
        return true;
    }
    return $allowed;
}, 10, 2);

Enable the new behavior early

If you’re not using ACF to store unsafe HTML, or you’re confident you’re already securely escaping your output where necessary, you can opt in to the new behavior now using the new acf/the_field/escape_html_optin filter:

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

This will enable stripping unsafe HTML immediately, and report an error in the WordPress admin when this happens.

Wrapping Up

All versions of ACF before ACF 6.2.5 are vulnerable to the reported shortcode vulnerability, so we recommend you upgrade immediately.

Additionally, we recommend disabling the ACF Shortcode entirely if you do not use it.

We’re aware you may have questions on these changes and are ready to support you. This Friday’s ACF Chat Fridays (Friday 19th January, 3pm UTC), and the following one (Friday 2nd February, 3pm UTC) will be dedicated to answering any questions you may have on this.

As a result of this security bug fix release, the previously announced changes to requiring an active license to use ACF PRO features have been delayed.

Please find the release notes below. For the latest ACF news, follow us on Twitter @wp_acf.

Affected Versions

ACF Free and PRO: <6.2.5

Security Response Timeline

• 2023-12-12 19:31 GMT – Initial contact from Wordfence via our support form asking us to confirm our support system was an acceptable method of disclosure.
• 2023-12-12 19:33 GMT – Confirmation sent from our development team that they could disclose this way.
• 2023-12-15 17:09 GMT – Disclosure received.
• 2023-12-15 19:00 GMT – Patch built and tested, however due to the holiday season we decided to hold the release until developers were back at their desks in the new year rather than the release disclosing this vulnerability.
• 2024-01-02 15:00 GMT – Decision taken to prepare the_field() changes as part of this security release, using the notification system from the shortcode, further delaying this release by an additional week.
• 2024-01-16 15:00 GMT – Release of ACF 6.2.5.

Changelog

• Security Fix – The ACF shortcode will now run all output through wp_kses, escaping unsafe HTML. This may be a breaking change to your site but is required for security, a message will be shown in WordPress admin if you are affected. Thanks to Francesco Carlucci via Wordfence for the responsible disclosure.
• Security – ACF now warns via an admin message, when upcoming changes to the_field and the_sub_field may require theme changes to your site to avoid stripping unsafe HTML.
• Security – Users may opt in to automatically escaping unsafe HTML via a new filter acf/the_field/escape_html_optin when using the_field and the_sub_field before this becomes default in an upcoming ACF release.

For support with the changes introduced in ACF 6.2.5, please contact our support team rather than the comments below.

For questions and help about this release, please contact our support team.

The post ACF 6.2.5 Security Release appeared first on ACF.

TL;DR – Releases in 2023 made it possible for developers to install ACF PRO with Composer, brought custom post type and taxonomy registration into the plugin, introduced a UI for the Options Pages feature, brought in native bidirectional relationships, and packed numerous bug fixes and improvements into 12 other minor and beta releases.

Let’s take a look back at 2023:

• Achievements
• Plugin Releases
• Website Improvements
• User Feedback and Community Growth
• What’s Ahead in 2024?
• Thanks

Achievements

ACF was fortunate enough to earn awards in two different user-voted competitions in 2023.

In April, ACF took the top spot in Torque Magazine’s annual Plugin Madness competition. ACF won the inaugural Plugin Madness in 2016, and made an appearance on the bracket every year since.

Results from the WP Awards were announced in December, with ACF earning the most votes in the Dynamic Data Plugins category, as well as receiving the most votes in any category. This marks the second year in a row ACF has earned this distinction.

It’s great to see ACF recognized like this, but I also love seeing individual users recognizing just how useful ACF is for them:

Plugin Releases

We started off 2023 with ACF 6.0.7, but it was the second release of 2023, ACF 6.1, that really got people talking. It introduced the ability to create custom post types and taxonomies directly within the plugin. This was one of our most often requested features, and now registering post types and taxonomies in ACF’s UI is as slick and intuitive as creating field groups and fields:

This release also updated ACF’s JSON sync, import, and export tools to include post types and taxonomies registered with ACF.

Field Selection Modal

The dropdown field selection menu wasn’t always clear, especially for new users. ACF 6.1 introduced the “Browse Fields” button, which opens a modal showcasing field types in a way that’s easy to search and informative, including descriptions, visual representations, and links to documentation.

ACF 6.1 included a host of other improvements, such as full compatibility with PHP 8.1 and 8.2, the ability to filter the post status for post objects fields, customizable field settings tabs, and improved test coverage.

Options Page UI

The development team kept up a regular cadence of bug fix and enhancement releases over the next few months, culminating in the release of ACF 6.2 in early August. This release introduced the ability to create options pages right from the plugin admin UI in ACF PRO, brought bidirectional relationship functionality natively to the plugin, and included enhanced support for registering multiple locations for JSON files.

The Options Page feature in ACF PRO allows you to register global, site-wide fields and place them on new pages in the WordPress admin. This has long been a feature of ACF PRO, but prior to ACF 6.2, they would have to be registered using a code snippet. This wasn’t ideal for workflow, as you had to create field groups, save them, go to your code editor to register the page, and then reload the field group editor to select the options page in the location rules.

ACF PRO 6.2 introduced a UI to do this within the plugin, making it possible to create settings and child pages with just a few clicks:

Bidirectional Relationships

ACF’s Relationship, Post Object, User, and Taxonomy fields types give you the ability to create relationships between data objects, but this connection was only one way. Bidirectional relationships required a code snippet or a third-party plugin.

That changed with the release of ACF 6.2. The four relational field types now have an “Advanced” settings tab, with a toggle allowing you to turn on bidirectional mode and set the field to store the connection data on the other side of the relationship.

More enhancement, bug fix, and security releases followed in the closing months of 2023, culminating in the release of ACF 6.2.4 in late November.

Other Improvements

Along with working on our internal testing and release processes to continually improve the quality of the plugin’s codebase and how fast we can release updates, we also shipped three security fix releases to patch security issues in the plugin. We plan to be even more proactive in finding ways to improve the security of ACF in 2024.

In August, we raised the minimum required PHP version to 7.0 and the minimum required WordPress version to 5.8 to encourage users to update the sites and servers that run ACF.

Website Improvements

We introduced first-party Composer support for installing ACF PRO early in 2023. This was an exciting development for many of our users, but it turns out we were just getting started.

We’ve significantly improved our documentation for ACF Blocks, including an ongoing series of tutorials. If you’re new to ACF Blocks, get started with Create Your First ACF Block, and then move on to more advanced concepts like How to Use Block Locking and Using InnerBlocks and Parent/Child Relationships.

Prefer a video format? We’ve got you covered:

We’ve also introduced or updated tutorials on Conditional Logic, How to Create an Options Page, How to Query Posts by Custom Fields, and made other improvements to our documentation. This is an ongoing project, so please make sure to let us know where our documentation could be improved, and what new tutorials you’d like to see.

User Feedback and Community Growth

It was a big year for releases, but 2023 may have been even bigger in terms of direct feedback from users. Throughout the year, we’ve been committed to incorporating feedback and suggestions to ensure that the plugin continues to meet the needs of its users. We’ve actively engaged with the community, encouraging users to share their thoughts and ideas for future improvements.

The launch of ACF Chat Fridays, our regular open office hours session, has given us a great pipeline to direct user feedback on issues they’re experiencing, challenges they’ve solved, and what they’d like to see next. Make sure you’re in the loop and register for the nest session.

This year also saw the introduction of the first-ever annual ACF user survey, helping us to better understand how users are building WordPress sites with ACF, and how we can deliver what will help our users the most. Check out the results of the survey.

In addition, 2023 also marked the creation of our public feedback board, where users can post feature suggestions, vote on others, and track progress of suggestions.

WordCamps in Europe and North America

We like to attend WordCamps when we can, and 2023 saw us at some of the largest WordPress events in the world: WordCamp Europe and WordCamp US in 2023.

Liam Gladdy and I attended WordCamp Europe in Athens, Greece, along with Rob Stinson and other colleagues from WP Engine. We had a great time running product demos at the WP Engine sponsor booth, chatting with customers, and meeting with partners.

A great 2nd day at #WCEU with the @wp_acf team and the rest of the @wpengine folks pic.twitter.com/NtfFVn2MLl

— Iain Poulson (@polevaultweb) June 10, 2023

Matt Shaw and Anthony Burchell from the ACF development team, and Damon Cook from WP Engine DevRel attended WordCamp US in National Harbor Maryland, and reported a similar experience. We hope to see you at a WordCamp in 2024!

DE{CODE} 2023

Naturally, we were also present at what might be the world’s largest virtual WordPress event: DE{CODE} 2023. Hosted by WP Engine, DE{CODE} is a 100% virtual event dedicated to helping WordPress developers build smarter, maximize conversions, and modernize the user experience.

Our presentation, “7 Things You Didn’t Know You Could Do With Advanced Custom Fields,” covered some of ACF’s lesser-known features, including some that were revealed to the public for the first time at DE{CODE} 2023. You can catch the whole presentation in the player below.

We’ll have more exciting news at DE{CODE} 2024, taking place March 19 (North America/APAC) and March 21 (EMEA), so make sure to mark your calendars and keep an eye on Twitter for news about the conference agenda.

Statistics

Let’s take a look at some of the stats from the past year.

Development

The engineering team has done another stellar job in 2023:

• Shipped 2 major releases
• Shipped 14 minor releases, release candidates, and betas
• Pushed 2,211 commits of code (+12% from 2022)

Support

The support team has always been a big part of ACF, and they continued to do a great job in 2023:

• Answered a total of 9,899 tickets
• Sent a total of 19,567 replies
• An average of 825 tickets per month
• Average customer satisfaction score of 92.5%

Community Engagement Stats

• Held 19 sessions of ACF Chat Fridays
• Surveyed 2,031 users in our first annual survey
• Published 76 blog posts, tutorials, and updated docs
• Held 9 WP Engine Builder sessions dedicated to ACF

Usage

The free version of ACF is at 2 million+ installs, with WordPress.org reporting that over 46% of them are running ACF 6.2:

Let’s have a look at data about sites that activated ACF PRO in 2023:

ACF Major Version

WordPress Version

PHP Version

What’s Ahead in 2024?

Our first major release of 2024, ACF 6.3, will focus on improvements and enhancements to ACF Blocks. The first of these is introducing field validation for fields contained within ACF Blocks. Many ACF fields allow you to set parameters for the input they will accept, and reject any input that falls outside those parameters. Historically, this validation wasn’t available for fields included in ACF Blocks. This will change with the release of ACF 6.3.

The second new feature for ACF 6.3 involves how field data is saved in ACF Blocks. When you create an ACF Block and add content to it in the content editor, the field data in that block is saved the same way WordPress saves the rest of the block editor information: to the post content column in the post table. However, some users would prefer to store the field data from their ACF Blocks in post meta, like classic ACF fields do. We’re working on a way to give you control over where that field data is saved when you create the block. This should make it easier to access this data for sorting and querying.

That’s the relatively near future. Looking further ahead for 2024, we’re working on a way for folks building headless WordPress sites or decoupled front end components to skip the PHP template stage when creating ACF Blocks. ACF is widely used in headless builds, so we’re examining ways to define paths to front end components in block.json, and then use the same component in the editor to show a preview of the block.

We’re constantly improving the UI and UX of ACF Blocks to make editing blocks as native as possible, and 2024 should have some enhancements along those lines. This is a long-term project, but we’re hopeful that editing ACF Blocks will be no different to core blocks.

We’re also planning enhancements to conditional logic for relational field types, Flexible Content field layouts, and much more. Make sure to sign up for our mailing list for the latest news.

Thanks

I’d like to thank the entire ACF team and everyone else at WP Engine for making these achievements possible in 2023, and ensuring we’ll continue to build on that success throughout 2024.

As always, my biggest thanks are reserved for our users. We asked for your feedback, and you delivered, helping to ensure that ACF continues to meet your needs. The development process is enriched and improved because of your participation.

What else would you like to see from ACF as we move forward into 2024? Let me know in the comments.

The post ACF 2023 Year in Review: Beyond Custom Fields appeared first on ACF.

The January 5th edition of ACF Chat Fridays provided an open forum for user questions and use cases, as well as insight into some of the new features and enhancements coming in ACF 6.3.

Co-hosted by Iain Poulson, Matt Shaw, Anthony Burchell, Damon Cook, 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

ACF Chat Fridays kicked off its 2024 season on January 5. Sessions are typically held every two weeks throughout the year.

Iain Poulson started the session with a quick update on ACF 6.3, the plugin’s next major release, noting that it will be focused on enhancements and new features for ACF Blocks, before opening the floor for user questions.

Q&A

Questions about the best way to use ACF, feedback about the plugin, or feature requests? ACF Chat Fridays is one of the best places to make sure your voice is heard and your questions answered.

We’ve included some of the questions and answers from the latest session below, with minor edits made for clarity and style.

Q: Any news on the possibility of having field groups at the top of the block editor? We often use field groups for page settings, and while the sidebar may be the logical place for this, we often have specific options that are easily overlooked when added to the sidebar.

A: At the moment, it’s at the bottom because that’s the system WordPress has implemented. As you noted, WordPress does let you move it into the sidebar, but then you end up with a weird mismatch of legacy CSS inside the block editor.

We do want to move that into a kind of native experience, actually bringing it more into the block rather than relying on the WordPress legacy system. WordPress is looking at this as well, as the current legacy system causes problems for things they want to do with iframes, etc.

You should definitely expect it to move at some point, but in this case it might be the WordPress design team or our design team who figure out where it should go.

Q: What can we expect regarding ACF Blocks in the next update? Any new features or fixes?

A: One of the big things ACF 6.3 will introduce is block validation. ACF fields often include validation, such as setting a certain field as “required,” or a Number field with minimum/maximum inputs. However, if the fields are set to ACF Blocks, the validation doesn’t work due to how WordPress saves data. We intended to fix this in ACF 6.3.

ACF 6.3 will also introduce more choice in how field data associated with an ACF Block is saved. Currently, the field data is saved inside the post content as part of the block data. We’re working on an option to allow the block to save that data in the wp_postmeta table instead.

This would be helpful when the block requires your editor to put in data, but you really want to store that data in postmeta because it’s a lot easier to search, query, or filter. We’ve heard from a lot of users who want to do this.

We also have a really exciting piece for anyone building full headless WordPress sites or building frontend components for their ACF Blocks in React, Vue, or similar. Currently, to actually render what it looks like in the editor, you must include a PHP template. This is annoying if you’ve already built a React component for your actual frontend, because you’ll also have to create a PHP template that’s only used to render the component in the editor. Starting in ACF 6.3, it will be possible to define a path to your frontend component in your block.json file, and the same component will be used in the editor to show a preview of that block.

We’re continually improving the editing UI for ACF Blocks, moving it closer in looks to native WordPress blocks. If you’re building a site with a mix of native WordPress blocks and ACF Blocks, the editing experience is slightly different, which isn’t ideal for clients. This is a very long-term effort, but we’re chipping away at it. One day, it might be possible to do inline editing in ACF Blocks, instead of having the main block editor section look like a form when you turn the block into edit mode. This isn’t really WYSISWYG editing currently, as it doesn’t look like the native blocks where you can just edit the data inline. We’d love to move towards something like that.

Q: The functions API supports get_field(). Is there a function that supports something like get_known_field_groups()?

A: Absolutely. You can use acf_get_field_groups(), which will give you all the field groups you’ve got, or acf_get_fields(), which retrieves all the fields from a specific field group, and returns them as an array of field objects.

There are functions for practically everything in ACF, but we’re very careful about which ones we document. Basically, we only document them when they support a common use case and they’re unlikely to change. We’ve recently published documentation for acf_get_fields(), and we’re looking at creating documentation for acf_get_field_groups() as well.

Resources & Links

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

• ACF Blocks
• The acf_get_fields() Function
• ACF on Twitter
• ACF Emails and News
• Sign up for ACF Beta News
• ACF’s Feedback Page

Coming Up on ACF Chat Fridays

Join us on January 19th, 2024 at 3pm UTC for the next session of ACF Chat Fridays.

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.

• January 19, 2024
• February 2, 2024
• March 1, 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.

The post ACF Chat Fridays: A Look Ahead at ACF 6.3 appeared first on ACF.

The December 8th session of ACF Chat Fridays looked into AJAX validation with ACF forms, the potential for an ACF Blocks UI, adding ACF fields to WordPress core blocks, and much more.

Co-hosted by Iain Poulson, Matt Shaw, Anthony Burchell, Damon Cook, 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

December 8th marked the last session of ACF Chat Fridays for 2023. ACF Chat Fridays will return to its regular biweekly schedule on January 5, 2024.

Iain Poulson launched the final session of 2023 with a quick update on the release of ACF 6.2.4, with another bug fix release, ACF 6.2.5, likely to follow in early 2024. The remainder of the forum was dedicated to user scenarios and questions.

Q&A

Questions about the best way to use ACF, feedback about the plugin, or feature requests? ACF Chat Fridays is one of the best places to make sure your voice is heard and your questions answered.

We’ve included some of the questions and answers from the latest session below, with minor edits made for clarity and style.

Q: I built a flexible block with some baked-in ACF forms, so you could insert the block, and you’d have your ACF options in the sidebar and do things like change the button text, whether it added an email, an opt-in, and so on. It was working nicely, but one of the big things I came up against was AJAX validation.

If you’re rendering an ACF form in the backend, and you try to save that page, the fields fail validation if they’re not filled in.

I thought I had gotten around it originally by using the acf/load_field filter, and basically saying “if you’re in the admin, and it’s this form, just set required to false.”

This worked to a point, but it was preventing AJAX validation from working. If my field failed validation, instead of saying “You must fill in this field”, it took me to a whole other page saying validation had failed and that I needed to fill out the form.

I found the exact same question on the ACF Extended forum, and the answer there appeared to be “don’t render your forms in the block editor.” This is a shame, as it was really nice, it was building out the form in real time as the user was selecting the options so they could see what they were going to get.

I have solved this using a JS filter, but I daresay that approach is a little heavy handed. I haven’t seen much discussion of this online, so I thought I’d raise it.

A: We’ve had instances where an ACF form is being used on the front end, and it’s either been triggered by another submit process or it’s triggering somebody else’s submit process. When you’re in the editor, and click Save Post, that hits a submit trigger that ACF listens for. It will then say “you haven’t submitted this form” because there’s no context or awareness that you’re actually in the editor, and nobody is really submitting your form, you’re just showing it to the editors. We should look into making sure ACF forms don’t have a submit when they’re in the block editor for cases like this where no one really needs to fill out the form in the block editor, it’s just a way of letting editors view what they’ll get on the front end.

Q: Are there any plans to include a more “drag and drop” interface for creating ACF blocks? The recent updates have been very useful, like creating option pages, and integrating custom post type and taxonomy integration.

A: Yes! We’re currently working on this. Registering ACF Blocks may be the last remaining thing in ACF where you must code. We’re looking at the best way to implement a UI for creating an ACF Block. It would be a great addition to ACF PRO.

ACF Blocks are essentially a PHP template and a block.json file. The block.json file has a ton of configuration options that aren’t entirely clear. ACF inherits the block.json structure for block creation from WordPress, but there isn’t easy documentation around that.

The screens ACF has in place for registering options pages, custom post types, and taxonomies are really helpful for users, especially if they either don’t know exactly what they want to do, or if they simply want access to the whole array of options and settings, and then you can use our screens to see the simple stuff first and then add in more advanced settings.

We hope to launch a UI for ACF Blocks sometime in the next year.

Q: It would be great if we could attach an ACF field to an existing core block. I’ve been using Query Loop blocks extensively, creating block variations and pre-query hooks to customize it in various ways. But the scenario

The use case I keep encountering is where someone wants to use a Query Loop block and specify which posts it will fetch. For example, you might be using a Query Loop block to loop over a post type of “Products.” You can say “give me six products” or “give me products ordered in this way,” but you can’t say “just give me this product, this product, and this product.”

So far, the way I’ve solved this is by saving it as post_meta. For example, we had a website with a load of members and a board of advisors. We needed a block that would just show those board members. I used ACF to insert a Post Object field on the post type where you select the group members, and then that’s saved as post_meta. I’ve made a Query Loop block variation that filters the arguments to say “if this post_meta exists, override the query and just show me those things.” This attaches the meta data to the post, rather than to the block. It doesn’t render in the back end, but it works on the front end.

Being able to attach ACF fields or ACF Blocks directly to a WordPress core block like Query Loop would be incredibly useful.

A: Nick Diego has been doing a lot of interesting work lately on extending core blocks. I’d suggest looking him up just to see how that flow of data can go. But of course, with ACF Blocks, you have PHP for the templates, so inserting those into a WordPress core block might be tricky just because of that disconnect.

I feel like that you could use ACF fields with core blocks, and then do something with them in the field data, but inserting ACF Blocks into a core block would be more difficult.

Update: During the 2023 State of the Word address, Matías Ventura indicated that the ability to connect core blocks to custom fields will be coming to WordPress core. The example he gave was to insert a heading or a paragraph into a core block, and indicate that you want it to come from a custom field.

Q: Is there a way to iterate over an ACF Block’s configuration and output a string of inline styles? When I have an ACF Block, and I’ve configured padding, font-size, etc., they’re all stored in different places. Unless I’m missing something, it seems like an arduous process to go through every time.

A: You should be able to do this with the get_block_wrapper_attributes() function. It allows you to use the styles built by WordPress’ native supports for a block, such as background and text colors, padding, margin, etc.

There are some cautions when applying this in your ACF Block PHP template. If that function is used when the block is rendered in the editor, you’ll get a PHP warning. Instead, use ACF’s $is_preview variable to know when your block is being output on the frontend, and then use get_block_wrapper_attributes() to add all the styles selected for your block. See ACF Blocks: Using get_block_wrapper_attributes() for more details.

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.4
• Nick Diego on Custom WordPress Blocks
• The ACF Form Function
• State of the Word 2023
• ACF Blocks: Using get_block_wrapper_attributes()
• ACF on Twitter
• ACF Emails and News
• Sign up for ACF Beta News
• ACF’s Feedback Page

Coming Up on ACF Chat Fridays

Join us on January 5th, 2024 at 3pm GMT for the next session of ACF Chat Fridays.

What do you think we should cover during the first session oft 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. You can watch the November 10th session on YouTube.

• January 5, 2024
• January 19, 2024
• February 2, 2024
• February 16, 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.

The post ACF Chat Fridays: ACF Blocks UI, AJAX Validation, and Styling ACF Blocks appeared first on ACF.

This release includes a number of bug fixes and improvements, along with fixes for license activation when using ACF as a must-use plugin.

As a result of this bug fix release, the previously announced changes to requiring an active license to use ACF PRO features have been delayed until a future version.

Please find the release notes below. For the latest ACF news, follow us on Twitter @wp_acf.

Must-Use Plugin Installs

After the release of ACF 6.2.3, we received reports from users that ACF was not activated despite having a license key defined in code, and the updates page was not visible. This is an issue for users who use the Bedrock framework or other methods of loading ACF as a must-use plugin.

ACF 6.2.4 fixes two issues for this type of installation. Firstly, the updates page is now visible by default for these types of installation. Secondly, if you define your license key in code, ACF will now correctly activate your license for the site.

Changelog

• Fix – Custom Post Types labels now match the WordPress 6.4 behavior for “Add New” labels
• Fix – When exporting both post types and taxonomies as PHP, taxonomies will now appear before post types, matching the order ACF registers them. This resolves issues where taxonomy slugs will not work in post type permalinks
• Fix – Advanced Settings for Taxonomies, Post Types or Options Pages now display with the correct top padding when toggled on
• Fix – When a parent option page is set to “Redirect to Child Page”, the child page will now correctly show it’s parent setting
• Fix – When activated as a must-use plugin, the ACF PRO “Updates” page is now visible. Use the existing show_updates setting to hide
• Fix – When activated as a must-use plugin, ACF PRO licenses defined in code will now correctly activate sites
• Fix – When show_updates is set or filtered to false, ACF PRO will now automatically still activate defined licenses
• i18n – Maintenance and internal upstream messages from the ACF PRO activation server are now translatable

The post ACF 6.2.4 appeared first on ACF.

This release includes a number of bug fixes and improvements, along with ACF PRO activation improvements and a JSON schema for ACF Blocks.

Please find the release notes below. For the latest ACF news, follow us on Twitter @wp_acf.

ACF Blocks JSON Schema

Users have long requested we provide a JSON schema for ACF Blocks so you can configure your IDE or code editor to automatically validate your ACF Blocks configuration JSON files. We’ve now published one over on GitHub.

By adding the $schema property to your block.json set to our URL, editors like VS Code or PHPStorm will automatically validate your values for WordPress Core and ACF specific keys in block.json.

Instructions for using the schema can be found here. If you spot anything missing or incomplete, please feel free to open a PR on that repo with suggested changes.

ACF PRO Activation Improvements

Purchasing an ACF PRO license has always been required to receive plugin updates and access to PRO field types and features, but this wasn’t enforced in the plugin, leading to potential for piracy and abuse. The vast majority of customers won’t be affected by this change, as you’ve always needed a license to download ACF PRO. However, you will now need to make sure to enter your license key in the plugin to use all of the features enabled by your license.

As of ACF 6.2.3, sites without an active license will display a warning in the ACF screens, and will have the following restrictions in place in a future version.

Once these restrictions are live, unless a valid license key has been activated for the site, it won’t be possible to create new or edit existing PRO fields, or use the premium features such as Options Pages and ACF Blocks in ACF’s admin screens.

The use of ACF on a site is in 3 different areas, and to clarify how these changes affect those areas take a look at the following table:

	ACF Admin	Editing Posts	Displaying Data
	Where you create and edit field groups, fields, and Options Pages in the ACF admin screen using PRO field types	Where content editors enter field values and ACF Blocks when editing posts, pages & custom post types	How the field values are rendered on the front end of the site by the theme or a page builder
Valid license activated	No impact	No impact	No impact
Expired license activated	Can edit existing ACF PRO fields, ACF Blocks, and Options Pages Cannot create new ACF PRO fields, ACF Blocks, and Options Pages	No impact	No impact
No license activated	Cannot edit existing ACF PRO fields, ACF Blocks, and Options Pages Cannot create new ACF PRO fields, ACF Blocks, and Options Pages	No impact	No impact

There are no changes to legacy lifetime licenses. Any valid ACF PRO license key will be valid to activate and use PRO features on any site, subject to your license site limits.

If you previously activated a license and the subscription has expired, you will not be able to create new PRO fields, but you will be able to edit existing PRO field definitions.

The editor experience for ACF fields, blocks and options pages will not change, and your site editors will be able to use all features as they do now. It will not affect field values. The restrictions will only apply to ACF’s admin screens for editing field groups.

Improvements like this are important to the continued success and sustainability of the plugin. Learn more about the license activations restrictions.

Changelog

• New – An ACF Blocks specific JSON schema for block.json is now available on GitHub
• New – Flexible Content fields now show the layout name in the layout’s header bar and supports click-to-copy
• New – Duplicating Flexible Content layouts now appends “Copy” to their name and label, matching the behavior of field group duplication
• Enhancement – ACF PRO will now automatically attempt license reactivation when the site URL changes, e.g. after a site migration. This resolves issues where updates may fail
• Enhancement – Presentation setting for ‘High’ placement of the Field Group made clear that it’s not supported in the block editor
• Fix – acf_format_date now ensures the date parameter is valid to prevent fatal errors if other data types are passed in
• Fix – CPTs with a custom icon URL now display the posts icon in the location column of the field groups screen
• Fix – The ACF JSON import form will now disable on first submit resolving an issue where you could submit the form twice
• Fix – The “Add Row” button in the Flexible Content field now displays correctly when using nested layouts
• Fix – Warning and Error notices no longer flicker on ACF admin pages load
• i18n – ACF PRO license activation success and error messages are now translatable

The post ACF 6.2.3 appeared first on ACF.

The November 10th session of ACF Chat Fridays dug into recent and upcoming releases for ACF, using ACF with page builders, and ACF Blocks.

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

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

The November 10th session focused on user questions and feedback, with questions ranging from using ACF with page builders, using ACF’s Flexible Content field as a page builder, ACF Blocks, and much more.

In addition to the Q&A, the session also covered details of what to expect in ACF 6.3, as well as news about the recently released ACF 6.2.2 and the upcoming release of 6.2.3. These are primarily bug fix releases, but with a few enhancements in the mix. ACF 6.2.2 adds a new acf/filesize filter to allow third-party media plugins to bypass ACF calling filesize() on attachments with uncached file sizes, which may result in a remote download if offloaded. In addition, ACF Blocks which have not been initialized by the editor will now render correctly, and ACF PRO license status and subscription expiry dates are now displayed on the “Updates” page.

ACF 6.2.2 also includes fixes to ensure product pages for WooCommerce version 8.2 or newer will now correctly support field group location rules, color picker fields no longer autocomplete immediately after typing 3 valid hex characters, and more. Please see the ACF 6.2.2 release post for more details, and expect more bug fixes and enhancements in ACF 6.2.3.

The final session of the year takes place on December 8, 2023. For more, please make sure to watch the session here.

Q&A

Questions about the best way to use ACF, feedback about the plugin, or feature requests? ACF Chat Fridays is one of the best places to make sure your voice is heard and your questions answered.

We’ve included some of the questions and answers from the latest session below, with minor edits made for clarity and style.

Q: I’m using ACF and Elementor. I’ve created a custom publication type called “products”, and custom fields that I use to customize the page. I’ve also created a Relationship custom field to retrieve similar products to be displayed at the bottom of my product page. But I can’t use this field in my similar products block, I can only retrieve products in the same category as the main product on the page. How can I use my Relationship custom field?

A: ACF is positioned around determining what data you need and giving your content editors a way to fill in that data. How it’s displayed on the frontend has more to do with the tool you use to display that data, in this case Elementor. They might have components that allow you to to change where the selection is coming from and plug that into an ACF field.

Q: I’m increasingly having clients who want the ability to manage/build templates themselves. I love how ACF and Elementor make it easy for them to do that, but it only works on some ACF features. Is there anything in the works to make this kind of easy integration with more WordPress builders or base WordPress?

A: We have to rely on page builders to include ACF integrations. We try to make it as easy as possible with hooks and filters, but the moment we shipped any code for a specific page builder, we’d be chasing our tail on every single release they do. You’re probably better off reaching out to the page builders directly in cases like this. We have a pretty good relationship with a lot of the page builders, so if there’s anything that they want to do, they could reach out to us and ask about deploying what they need.

Q: We use ACF’s Flexible Content as our page builder, with no other builders. We’ve got a lot of templates to choose from. It’s pretty fast when I’m building, but when a client wants to add a new page and they start to build it out, we sometimes get 502 errors. Is there anything coming in the future to help speed up or optimize Flexible Content?

A: This is a performance issue we’re aware of and working on. If you’ve got a post with 200 fields, when you edit the post, you’re loading 200 field inputs in the DOM, getting them all from the database and then writing them back to the database when you update the post.

This issue can arise with any field, but it tends to show up the most with Flexible Content fields, as there are often multiple layouts and lots of fields within those layouts. We are working on performance improvements for this. Right now, when you load an ACF field group, it loads the entire DOM. We’d like to get rid of that, and have it only loads what it needs to, when it needs to.

Q: I’m having some issues with the ACF Blocks I create not outputting things like line-height and appearance on the frontend, although it appears to work in the back. I’ve registered the support in my block.json file, but does this need to have its own class variable in my render.php file?

A: When you click on any of the supports that you’ve registered, WordPress dynamically applies a wrapper to the outputs you see in the back end so you can see them live. The fact that you can see those supports in the block editor means they’re registered correctly, as they wouldn’t be available otherwise.

Make sure you have is preview set to true, and that will basically load all the values you’ve set in your supports, and output them only for the frontend.

The get_block_wrapper_attributes() function reads all the block supports that need to be passed to the block, such as CSS. etc.. If you’re using that function, that should take care of almost everything. Please reach out on Twitter) if this doesn’t work and we can try to dig into your specific block.

Q: I’m jumping into ACF and modern WordPress development, and our team is used to the pattern of create custom blocks -> register them -> build pages by adding the required blocks.

I don’t understand what is the configuration difference between the block.json and the options that can be set when registering the component in functions.php.

Currently my block registration just does a glob search on the blocks folder so I don’t have to register every component individually. Is there a better pattern for going about this?

A: In theory, you could define everything in functions.php, but we don’t recommend this. Using block.json passes a lot of other stuff, like WPDefinedAsset, which is how you load scripts and styles. That can be really difficult to do the PHP way.

This depends on your tooling, but the easiest way to search is likely what you’re doing now: a glob search on the blocks folder. Make sure you’ve got it set up to handle compiling all your block assets, CSS, etc., that are specific to your blocks.

Q: Is there any news on ACF Blocks field validation and using ACF Blocks with WordPress React components?

A: We’ve been working on these features, and we expect that block validation will be included in the next major release, ACF 6.3. Regarding React components with ACF Blocks, we’ve discussed ways for those on a headless WordPress setup to use frontend components they’ve built as the preview in the editor, rather than having to rebuild the components as a PHP file. That may appear in 6.3. As for actually using WordPress React components with your ACF Blocks, that’s a bigger challenge and will not be included in ACF 6.3. This is something we’re still working on.

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.2
• get_block_wrapper_attributes()
• ACF on Twitter
• ACF Emails and News
• Sign up for ACF Beta News
• ACF’s Feedback Page

Coming Up on ACF Chat Fridays

Join us on November 10th at 2pm GMT for the next session of ACF Chat Fridays.

What do you think we should cover at our session in December, and sessions 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. You can watch the November 10th session on YouTube.

• December 8, 2023
• January 5, 2024
• January 19, 2024
• February 2, 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.

The post ACF Chat Fridays: Page Builders, Blocks, and New Releases appeared first on ACF.