ACF 6.2 Beta 1 Released

We’re excited to announce the first beta release of ACF 6.2 and ACF 6.2 PRO.

ACF v6.2.0-beta1 is now available with all new bidirectional fields, admin UI registration of options pages, support for multiple ACF JSON save paths and a number of bug fixes! 🎉🥳

PRO users can find the release in their account, and Free users can find the release on GitHub.

Bidirectional Fields

For years, ACF has recommended implementing bidirectionality for fields using code. ACF 6.2 brings this feature to the UI.

When editing a field group, supported field types (currently Post Object, Relationship, User and Taxonomy fields) will display a new “Advanced” tab with a Bidirectional toggle.

When enabled, you’ll be able to select one or more target fields which will be updated on each selected value for that field, back to the item being updated. This is a powerful and complicated feature. As such, it requires some thought about the connections you wish to make between fields across different item types. Here are some examples:

• A Relationship field displayed on the wc_product post type called “Related Products”. Enabling bidirectional, and setting the Target Field to the same field (“This Field”) will automatically add the wc_product Post ID being edited to the related products field on each of the selected values for related products.
• A user field displayed on a post type “Business Sectors”, where the user selected indicates who to contact about that business sector. If you enable bidirectional and set the Target Field to a relationship field output on a user, updating the business sector will allow you to automatically get all sectors they are responsible for on their author page.

The main complexity with bidirectional fields lies in determining where a field will be displayed. ACF supports showing the same field across multiple places, such as posts, users, taxonomies, option pages, blocks, etc., so the “item ID” being updated will vary depending on where it’s currently being displayed. This is usually a post ID, but could be a user ID or taxonomy term ID. However, you can’t save a user ID to a Post Object field, so the Target Field for a field displayed on a user profile must be a User field to be updated.

Bidirectional enabled fields will therefore only update their targets when they’re displayed on a Post, User, or Taxonomy, and not on options pages, blocks, widgets, or any other location type which doesn’t resolve to a post ID, user ID, or taxonomy term ID. Whenever ACF tries to update a Target Field it will ensure the item type being updated is compatible with the target field type. If not, it will skip the update.

The bidirectional setting will currently only enable one-way syncing of the data (unless you select This Field as the Target Field). If you wish to enable two-way syncing of data between two different fields, you’ll need to enable the bidirectional setting on the Target Field field as well, and set its target back to the original field.

Bidirectional fields currently only support Target Fields which are top level fields, and not fields contained within any other type of field, including Group fields.

You also can’t chain bidirectional updates; only the selected Target Fields will be updated with the currently editing item ID. If the Target Field also has bidirectionality enabled, it will not be updated.

Options Pages UI

ACF PRO has long had the ability to register options pages with PHP functions like acf_add_options_page(). ACF PRO 6.2 will make this even easier with the new Options Page UI. Take a look at the demo Damon Cook gave during a recent WP Engine Builders session:

You can find the new “Options Pages” menu item in the ACF “More” menu, or directly in the ACF sidebar. To make things even faster, we’ve also made it possible to create an options page while editing a field group! To do so, select “Add New Options Page” from the field group location rules, and a new modal will appear that will create an options page and assign it to the field group location rules:

Options pages created with the new UI are just as developer-friendly as you’d expect from a plugin like ACF: they support syncing via JSON, can be exported back to plain PHP code, and can be extended with many new filters and action hooks. We’re currently working on writing documentation for all of this ahead of the final release, but there are some filters worth mentioning here.

You can filter the settings used to register the options page with the new acf/ui_options_page/registration_args filter, with the first parameter being the settings passed to acf_add_options_page(), and the second parameter being the raw options page data.

If you’d prefer to disable the new Options Page UI on a site for any reason, you can do so with the following filter:

add_filter( 'acf/settings/enable_options_pages_ui', '__return_false' );

That will both disable the new UI and prevent ACF from loading anything related to it, though options pages can still be registered with PHP via the acf_add_options_page() function.

Please let us know on Twitter if you have any questions about extending the new Options Page UI while we finish up the documentation.

Multiple JSON Save Locations

We’ve had multiple requests over the years to support saving JSON to multiple different paths, and ACF 6.2 will finally bring support for it to the core plugin.

To accomplish this, we’ve added several new modifiers to the acf/settings/save_json filter that can be used to customize the JSON save paths. The following filters can be used to change the save path for a single file:

• acf/settings/save_json/key={$key} The field group, post type, taxonomy, or UI options page key.
• acf/settings/save_json/name={$name} The name of a field group, post type, taxonomy, or UI options page.
• acf/settings/save_json/type={$post_type} Can be one of acf-field-group, acf-post-type, acf-taxonomy, or acf-ui-options-page.

These filters give you granular control over where a JSON file is saved based on the name, key, or the post type of the item being saved. If multiple paths are a match for the same file, the most specific path will be chosen – i.e., the acf/settings/save_json/key={$key} filter will override the acf/settings/save_json/name={$name} filter.

We’ve also added a more general filter that can be used to filter all of the paths available when a file is being saved:

apply_filters( 'acf/json/save_paths', $paths, $post );

This filter has two parameters. The first is an array of the possible save locations for a file, and the second parameter is the entire field group, post type, taxonomy, or options page that is being saved. Here’s a quick example of how that could be used to filter the paths based on the title of the item being saved:

function custom_acf_json_save_paths( $paths, $post ) {
    if ( $post['title'] === 'Theme Settings' ) {
        $paths = array( get_stylesheet_directory() . '/options-pages' );
    }

    if ( $post['title'] === 'Theme Settings Fields' ) {
        $paths = array( get_stylesheet_directory() . '/field-groups' );
    }

    return $paths;
}
add_filter( 'acf/json/save_paths', 'custom_acf_json_save_paths', 10, 2 );

To make sure that the JSON files load from your new locations, you’ll have to make sure that any paths you’ve added via the filters above are also added to the existing acf/settings/load_json filter, which already supports passing in an array of multiple paths. You’ll also want to move any existing JSON files to the new locations after adding the above filters.

If you’d rather not use multiple paths, the existing JSON functionality will continue to work normally.

Wrapping Up

As always, we’d love to hear any feedback you have on the new features included in this beta. Feel free to stop by at our next ACF Chat Fridays on August 4th at 2pm GMT (10am US Eastern Time) and let us know your feedback or ask our developers any questions you might have about these new features. Alternatively, feel free to contact us directly to give us your thoughts. The final release of ACF 6.2 should be out within the next few weeks, and your feedback helps to make sure that it works well for everyone.

About the Author