Advanced Custom Fields

We are experiencing major admin-side performance limitations when using large-scale ACF Flexible Content implementations for enterprise page-builder architectures. After profiling and testing extensively, the bottleneck does not appear to be server-side. The primary issue is browser-side rendering and initialization within the ACF admin UI. Currently, Flexible Content appears to initialize and render all layouts and nested subfields immediately, even when layouts are collapsed. As the number of layouts and nested fields grows, this causes: * very large DOM trees * high browser memory usage * expensive JS execution * slow editor interactions * long admin load/render times * degraded scalability over time This becomes particularly problematic for enterprise/editor-heavy implementations where: * Flexible Content acts as a centralized component/page-builder system * layouts are intentionally reusable across multiple templates * editors require access to all layouts within a unified builder * content teams collaborate across many departments * websites evolve continuously over multiple years * new layouts/components are added regularly In these scenarios, splitting layouts across multiple templates is often not a practical architectural solution. We believe ACF would greatly benefit from performance-focused rendering improvements for Flexible Content, such as: * lazy loading flexible layouts * rendering layouts only when expanded * virtualized rendering / virtual scrolling * partial DOM rendering * deferred field initialization * async or chunked hydration * pagination/incremental loading similar to Repeater pagination * mount/unmount lifecycle handling for collapsed layouts * background field initialization * deferred React rendering strategies Even partial-loading approaches would significantly improve scalability and long-term maintainability for large ACF implementations. At the moment, all layouts appear to initialize immediately, which creates substantial performance overhead once projects reach enterprise scale. This feature would greatly improve ACF’s suitability for large-scale page builders, enterprise editorial systems, and long-term evolving websites.

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.

Right now I have a site that uses the flexible layout field and over time we've added various new elements the user can use to author their page. The result is this big drop down list and it's just not user friendly any more. A screenshot is attached. If instead of a list a more horizontal popup could appear with icons and labels (i would have to define the icons naturally) this would transform the experience into something far more visual and user friendly and quick to locate the item needed.

So great that, finally, the ability to load theme.json colours has been added to the colour picker field, but the value returned is only the RGB numbers, which is only really 50% useful. I would like to see the array return expanded to also include the colour's slug, at the least, and also the css classes for both text and background use. If you're not sure what I mean, have a look at this plugin: https://github.com/log1x/acf-editor-palette Finally, it would be great to replace the current UI with the block editor's native one.

This is the PHP that ACF generates: 'has_archive' => 'docs', 'rewrite' => array( 'slug' => 'doc', ), To make it translatable it should be: 'has_archive' => _x( 'docs', 'slug', 'text-domain' ), 'rewrite' => array( 'slug' => _x( 'doc', 'slug', 'text-domain' ) ), It works if exists also: add_filter('acf/settings/l10n_textdomain', 'custom_acf_settings_textdomain'); function custom_acf_settings_textdomain( $domain ) { return 'text-domain'; }

In ACF, if we modify labels, descriptions, or options of a field, the value of field_nnnn remains unchanged. However, if we change the meta slug, a new field_nnnn is generated. This causes the existing data in post_meta to become orphaned. It would be better if changing the slug did not affect field_nnnn, so the link with existing data stayed intact. On the other hand, if we create a completely new field, then a new field_nnnn should indeed be generated. Thanks

The relationship field is not compatible with Woocommerce orders. There order list in the field do not have the order ID, only the Woocommerce status. This makes it impossible to differentiate an order from the other. We only need to make sure the order number is passed so we can search for an order and add it to the relationship field

Currently, if you add additional paths for ACF to load json from using acf/settings/load_json , it will use the LAST found acf field group. This means, even if a field is edited via the editor, it will still use the last path, such as from a plugin. This is described in the documentation: This filter will allow plugin and theme developers to easily register field groups, post types, taxonomies, or options pages which cannot be edited by clients. I have a different use case - we are an agency and want to have some base packages as all of our sites share a similar structure but I still need to be able to add fields to suit different clients, such as adding an additional image field in some nested field group. Currently, there is no way to change the behavior of this, it always picks the last. I propose adding a filter that would enable plugin developers to choose which file should be used for a specific field group. ` // Pick the newest version, regardless of if its in the theme or plugin folder add_filter('acf/json/pick_file', function($currentFile, $newFile, $newJson, $loadPath) { // Only modify it if its the plugins path if($currentFile && $loadPath == plugin_dir_path( __FILE__ ) . 'acf-json') { $currentJson = json_decode( file_get_contents( $json_files[ $json['key'] ] ), true ); // Compare modified dates and take newest if ( $currentJson['modified'] < $json['modified'] ) { return $newFile; } else { return $currentFile; } } return $newFile; }); ` All the code to support this would be very simple in the includes/local-json.php file: ` // __construct() add_filter( 'acf/json/pick_file', array( $this, 'pick_file' ), 10, 4 ); // scan_files() line 326 $json_files[ $json['key'] ] = apply_filters( 'acf/json/pick_file', $file, $json_files[ $json['key'] ] ?? null, $json ); // Maintain current behavior public function pick_file( $currentFile, $newFile, $newJson, $path ) { return $newFile; } ` Right now, the best you can do is choose to not include the acf-folder when doing acf/settings/load_json. This is problematic though if there are multiple field groups you want to load. Being able to filter individual files would unlock a lot of possibilities. TLDR Goal: Create new theme, importing packages via composer Use acf-json from packages Make changes via editor, save to themes acf-json folder Right now, will still use the packages acf-json, despite the theme's being newer. - Would like to use the themes json file, while allowing sync from the package should we update it. Workaround: Prepend the package's acf-folder path. This means the theme will always win, but it does unfortunately break the sync feature. Even if the package is modified and newer, it doesn't show sync available.

It would be great if you could include some function into ACF for checking automatically if the max_input_vars is enough to save the actual changement of a fieldgroup. And in the case it finds it too low, to reject saving to avoid deleting existing data.

Now in admin panel we can only see the name of current layout. It would be cool to see the key next to the layout name, eg. Layout name <i>layout-name</i>