Advanced Custom Fields

We are asking for a v3 equivalent of v2's in-canvas edit mode: a block's fields rendered in place in the canvas, where the block sits on the page. The context, briefly. Our blocks declared "acf": { "mode": "edit" } and editors filled the fields in place, on the page, seeing the block in its real context. WordPress 7.1 now always iframes the block canvas, and v2 guards against that by forcing preview mode and hiding the edit toggle, so v2 blocks became readable but uneditable. Moving to v3 is the correct fix and we have done it. But v3 offers no in-canvas form at all: the options are the Block sidebar or the Expanded Editor. Neither replaces what was lost. The Block sidebar is too narrow for real field layouts, where repeater columns collapse into each other and image thumbnails land on their captions. The Expanded Editor is a good form, but it covers the page, so editors lose sight of the thing they are editing. The frustration is the abruptness. In-place field editing is how ACF sites have been built and how editors have been trained for years, and the upgrade path removes it with no equivalent. For an agency with a large estate of client sites, that is retraining every editor on every site, to work around a UI gap rather than a design decision. Done would be a v3 block able to render its fields in the canvas, in place, as v2 could.

Please add a location rule option for "User Form is/is not Edit" Currently only All, Add, Add/Edit, Register (which might be a custom one for this client?) are available but there's no option to ONLY display on the EDIT screen without also showing it on the ADD screen (where we don't want it).

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.

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

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?).

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.