Advanced Custom Fields

When ACF Local JSON is enabled, it is possible for an admin/developer to open and update a field group in the WordPress admin while that field group has a pending JSON sync. This can create confusion and risk overwriting newer field-group changes from Local JSON, especially on team projects where ACF field groups are committed to Git and synced between environments. Suggested native behaviour: Detect when a non-private Local JSON field group is missing from the database or has a newer modified timestamp than the database version. Show a clear admin notice linking to the ACF sync screen. Disable or warn against saving the field group until the pending sync has been resolved. Ideally block the save server-side as well, so the protection does not rely only on UI state. I built a small proof-of-concept plugin that handles this currently: https://wordpress.org/plugins/fieldlock-sync-guard-for-acf/ The plugin: Detects pending ACF Local JSON syncs. Shows an admin notice. Disables the Update button on ACF field-group edit screens. Blocks normal field-group saves server-side while a sync is pending. Ignores private Local JSON files. This feels like something that would benefit ACF users directly in core/ACF Pro, because it protects field-group changes in Git-based and multi-developer workflows without requiring an additional plugin. I’d love to see this considered as a native ACF feature, or at least as an official option/filterable safeguard for Local JSON workflows.

The DX of interacting with the subfields inside of group fields is a little clunky, often requiring that you store the entire group value in variable and then use array notation on it. If often find the clunkiness of this (the way it breaks up my template mark-up) dissuades me from using a group field even when it would be appropriate or useful in the back-end. I’d like to propose allowing the use of dot notation in get_field and the_field functions to access the subfields of groups. This would allow us to write templates in a more ergonomic way. For example, `php <?php $address = get_field( ‘address’ ); ?> <p> <?php echo esc_html( $address[‘street’] ); ?> </p> <p> <?php echo esc_html( $address[‘city’] ); ?> </p> ` Would be equivalent to, `php <p> <?php the_field( ‘address.street’ ); ?> </p> <p> <?php the_field( ‘ address.city ’ ); ?> </p> ` For backwards compatibility I’d assume there’d need to be some mechanism for ensuring this isn’t overriding a field which does have the name of ‘address.street’ (if periods are allowed in field names?).

WordPress is introducing a new system for registering icons (& icon collections) for use in the core/icon block. It would be great if ACF could pull icons from this new registry, in addition to those added via the ACF specific filters that already exist. This would allow editors to pull icons from other plugins without them needing to specifically support ACF. Make.WordPress blog on this new system: https://wp.me/p2AvED-wpz

Instead of storing field data in the post meta table, store the field values in a custom database table. This reduced performance issues and makes the data easier to query.

When my repeater block item has many fields in it, it makes the item block very large and making it very difficult to re-arrange them by drag and drop only. Many times I have to zoom far out from the browser to make it work. This is extremely relevant with using ACF to create gutenberg blocks as the edit section of the preview block is very limited. It would be awesome if when hovering over the drag and drop area that if the block is over [xxx]px tall then up and down buttons appear near the top and bottom of the drag and drop area. Clicking on them just moves the block up or down one spot accordingly. If the item block height is not that tall then it might not make sense to show or need the buttons as there may not be enough room for them. Thanks

For certain applications such as creating your own column system, it would be useful to have an index for each child block. In this case, for example, we could use the index to set the width of each column in 1 field in the parent. This could also make advanced structures possible where the Xste child block needs a different structure. So in short: being able to address an index for each child block within “innerblocks”.

When editing fields in ACF Blocks in the block editor, the UI for inputs can be different from the native WP block settings. This can be confusing to clients.

Ever needed to add the same social media link fields that are on the Contact page to a CPT single? Being able to check the selected fields in a field group, batch duplicate them, select the duplicates and then batch move them to the same other field group would save a lot of time.

Similar to https://github.com/hirasso/focal-point-picker , add a focal point picker for images when adding them via an image or gallery field. Output the relevant coordinates in the image array or via wp_get_attachment_image.

After updating to the latest version, conditional logic inside the Repeater field broke for table headers (<th>). When a sub-field's conditional logic hides a column, the corresponding <td> elements in the <tbody> correctly receive the .acf-hidden class and hidden attribute. However, the <th> elements in the <thead> remain completely visible. This causes the table headers and data columns to mismatch, severely breaking the layout of the admin UI. Steps to reproduce: Create an ACF Repeater field with a "Select" sub-field (e.g., source_type) and several other sub-fields that depend on its value (e.g., File, URL, Text fields). Set up Conditional Logic on those dependent fields to hide/show them based on the selected option. Open the post/page editing screen where this Repeater is located. Toggle the select field. Notice that while the input cells (<td>) hide and show correctly, the table headers (<th>) stay visible at all times, causing the columns to shift layout. Expected behavior: The JS script should toggle the .acf-hidden class on both the table headers (<th>) and the table data cells (<td>) simultaneously, keeping the table layout consistent. Actual behavior: The <th> headers are ignored by the conditional logic script and remain visible, leaving empty headers over mismatched data columns. Additional Information / Context Environment: WordPress Version: 7.0 ACF/ACF Pro Version: 6.8.5