Advanced Custom Fields version 6.3 is now available! 🚀🎉
ACF 6.3 introduces validation support for fields in ACF Blocks and the ability to store ACF Block field data in the post meta table.
This release also brings an enhanced experience to selecting the menu icon for custom post types and ACF Options Pages, along with a new Icon Picker field type, improvements to the experience of selecting relational fields in conditional logic rules, and a whole lot of new goodness, improvements, and fixes.
We have also increased the minimum requirements for PHP and WordPress in this release.
This has been a big effort from all involved. Thanks to all those that tested out the beta release over the last few weeks.
👨💻 Please find the release notes below. For the latest ACF news, follow us on Twitter @wp_acf.
Let’s get into it.
Validation is a powerful feature of ACF. Fields can have validation rules applied to them, like being required, minimum and maximum values, or even custom rules. These validation rules have previously only worked for post-wide fields and not for fields inside ACF Blocks. Creating a system for validation of block fields inside the block editor has been a large technical challenge and wasn’t something ACF supported until now.
Validation for fields in ACF Blocks is enabled by default for all blocks, and works the same way as validation works for field groups assigned to posts, pages or other data objects, supporting all the same custom validation logic and filters.
Any existing posts with ACF Blocks will be validated the next time the page is edited, and any fields failing validation, such as empty required fields, will mean the page cannot be saved again until the issues are resolved.
When you add a new ACF Block to the page, the validation will only run the first time you deselect the block, or try to save the page to avoid interrupting you while you’re editing a block. It is possible to turn off validation by default for fields in ACF Blocks
By default, WordPress stores a block’s field data inside the block’s HTML comment in the post_content
column of the posts table.
This is fine for many situations, but you may also want to create an ACF Block that saves and reads its data from post meta to make it easier to query.
ACF 6.3 makes this possible with a new block.json
attribute: usePostMeta: true
(default false). Learn more about saving block data in post meta.
This functionality would enable you to create a custom post type, with a locked block template, letting you replicate a classic editor-like experience where only your block exists to enter specific structured data. This data would then be stored in post meta and allow you to query it easily.
When we released ACF 6.1 and brought custom post type registration to ACF, the way you could select the admin menu icon for the custom post type (CPT) in the UI left a lot to be desired, requiring you to enter the string of the Dashicons class or the URL for an image. This was the same experience you get when registering an ACF Options Page in the UI since ACF PRO 6.2.
Our designer Dale had always envisioned a better UX, but it wasn’t possible to implement for those releases. Until now! Choosing an icon for the admin menu for a CPT or an Options Page is made infinitely easier, giving users the ability to view, search, and select from the Dashicons icon set. We’ve also added selecting an image from the WordPress media library, or uploading a new one as needed. The basic text input can still be used when setting the icon from an external image URL.
Take a look at Phil’s demo in a recent ACF Chat Fridays session.
Due to how ACF’s own admin pages are built, using our own ACF field types to construct the settings, we’ve had to build out this icon picker setting as a new ACF field type, which we’ve also made available in both ACF and ACF PRO.
When you need your content editors to pick an icon like a dashicon, or from the media library, you can create an Icon Picker field in your field group. You control where your editors can choose from (Dashicons, media library, and external URL), and we’ll be looking at making the field type even more extensible to allow loading in other icon sets, in a future version
This is an all-round big release, with the larger features already mentioned and some other improvements. Let’s take a look at some of the most impactful improvements.
The conditional logic rules to show and hide fields based on the value of another field in that group is an extremely powerful feature of ACF that allows developers to create intelligent and dynamic forms for their clients to fill out.
However, when you needed to conditionally show a field based on what was selected in a taxonomy field, for example, the experience was somewhat cumbersome. You would need to know the ID of the taxonomy term to enter in the rule.
For example, only show the ‘CEO Title’ textbox if the ‘Director’ User field has the CEO selected:
We’ve spent some time really polishing the UX and making sure that whenever a Taxonomy, User, Relationship, Post Object, or Page Link field is used in a conditional logic rule, you can actually select from the data in the field without having to know object IDs!
Take a look at Anthony’s demo in a recent ACF Chat Fridays session.
To improve the support we offer ACF customers, we’ve added key ACF data to a new panel in the WordPress admin’s “Site Health” section. This allows you to copy and paste the data into support tickets so our support team can be better equipped to help you, in a shorter time.
Finally, as we proposed in ACF 6.2.7’s release notes, the ACF Shortcode is now disabled by default for new installs of ACF, first installed after the release of 6.3. Learn how to enable the shortcode If you specifically need to use it.
These are just the highlights, with more improvements and bug fixes bundled in this release. To see a full list of all the updates, take a look at the changelog.
We’ve again raised the minimum required versions of PHP and WordPress, like we did in ACF 6.2. As a plugin with a large user base, the team feels that we have a responsibility to assist in getting users to keep PHP and WordPress versions updated to the latest version as possible.
As of ACF and ACF PRO 6.3, we have raised the minimum required PHP version to 7.4 and the minimum required WordPress version to 6.0.
If you are running ACF on a site that doesn’t meet these new requirements, WordPress won’t let you update to ACF 6.3 if your PHP version is lower than 7.4, and will show a warning message if your WordPress version is lower than 6.0.
We’ve got a packed backlog with new features, improvements, and bug fixes to keep us busy over the next few months. For ACF 6.4 later this year, we’ll be looking at bringing a UI for registering ACF Blocks, making it easier to edit text content in the block editor for ACF Blocks, and implementing WooCommerce HPOS support.
If there’s features or improvements you’d love to see in ACF, please drop them into our feedback board and vote on others that are important to you.
Keep up to date with what we’re working on in our bi-weekly ACF Chat Fridays office hours.
Thanks to everyone in the ACF community who helped make this release possible! 🙌
Are you excited about the new features and improvements in ACF 6.3? Let us know in the comments below or on Twitter.
Speed up your workflow and unlock features to better develop websites using ACF Blocks and Options Pages, with the Flexible Content, Repeater, Clone, Gallery Fields & More.
For plugin support, please contact our support team directly, as comments aren't actively monitored.