Advanced Custom Fields

On every request, ACF_Local_JSON has four callbacks registered on the acf/include_* actions: * include_fields * include_post_types * include_taxonomies * ACF_UI_Options_Page::include_json_options_pages Each callback calls scan_files( $post_type ). scan_files() walks every load path, then file_get_contents() and json_decode() every .json file, just to read its key and decide whether the file belongs to the type being scanned. After that, each matching file is decoded a second time when it gets registered. So every JSON file is read and decoded four times per request, plus once more for the type it belongs to. This happens even when a type has no JSON at all: we have no post types, taxonomies or options pages in JSON, and those three scans still decode all 145 field-group files. Measured impact (production site, 13 load paths, 145 JSON files, about 1.2 MB): Callback Time include_fields ~34 ms include_post_types ~17 ms include_taxonomies ~17 ms include_json_options_pages ~17 ms Total ~85 ms That's about 85 ms on every request that misses the page cache: logged-in pages, cart, checkout, admin-ajax, and REST. Suggested fixes Scan once per request. Decode each file a single time, group the results by type (the key prefix), and let the four include_* callbacks read from that one result. Cache the scan across requests, with a cache key built from each file's path, mtime, and size, so an edit or a sync invalidates it straight away.

We've modified our dropdown for selecting flexible content layouts and it would be cool if those were added natively to this selector. What changed: max height on popup + added scrollbar added search that gets autofocused when popup opens we marked some layouts are frequently used so they appear at the top with dedicated label other layouts are below separated by <hr> layouts are sorted alphabetically

As it is now, deleted ACF fields stay in the database, which can sum up on larger sites with a bunch of ACF fields. It would be great and very helpful, if there was an EASY NATIVE way with ACF PRO plugin to being able to delete old or unused ACF fields right inside the plugin from the database, without the need to delete them manually from the database. Besides the mess unused fields leave in the database - in some pagebuilders (e.g. Bricks), deleted ACF fields still stay in the pulldown selection choices when connecting content elements with ACF fields, which - again - messes up the pulldown-lists and makes editing and working with ACF fields quite hard sometimes.

It will be more than usefull to add the possibility of searching inside a repeater field expecially if it has a lot of rows or if it is enabled the pagination function. In my case we have more than 40 pages on the repeater field and it's a problem for us to search inside of it. Thanks.

Admin pages with a lot of WYSIWYG fields can be significantly slow to load. That's why there is the option "Delay Initialization", that waits for the editor to be initialized as soon as the user clicks it. The related JS is from the days before IntersectionObserver was born – but it could now definitely be improved so that TinyMCE will be initialized as soon as the field enters the viewport. Here's a little function I wrote that does exactly that: /** * Attaches an intersection observer to delayed WYSIWYG fields * to enable them automatically if scrolled into view * * Uses the `ready_field` and field.addAction('load') actions * @see https://www.advancedcustomfields.com/resources/javascript-api/#actions-ready_field * @see https://www.advancedcustomfields.com/resources/javascript-api/#actions-load_field */ handleACFWysiwygField = () => { /** * Is the field delayed? */ const isDelayed = (field) => { return field.$control().hasClass("delay"); }; /** * This function will be injected into the ACF field object. * So `this` will be the field */ function observe() { if (!isDelayed(this)) { return; } const field = this; const $wrap = field.$control(); const observer = new IntersectionObserver( (entries) => { if (entries[0].isIntersecting) { $wrap.trigger("mousedown"); observer.disconnect(); } }, { rootMargin: "300px 0px", } ); observer.observe($wrap[0]); } /** * As soon as the field is ready, prepare it * for observation */ function onReady(field) { if (!isDelayed(field)) { return; } field .$control() .find(".acf-editor-toolbar") .text("Initializing Editor ..."); field.observe = observe.bind(field); field.addAction("load", field.observe); } acf?.addAction("ready_field/type=wysiwyg", onReady); }; The function does the following things: wait for any wysiwyg field to be ready if the field is delayed wait for the field to be fully loaded ( field.addAction('load') ) patches the field with an "observe" function, that observes it and initializes the editor as soon as the field becomes within 400px of the viewport As this all can already be done using the JS API, I thought it would be worth sharing it publicly. But if the ACF support is reading this, maybe they'd consider adding the functionality to the core?

Please consider adding support for object caching. This will speed up the admin editing experience.

ACF is adding 0.545 seconds in average to the pagespeed when activated. And uses almost 1MB memory per visitor. Most plugins use 200KB memory or below, with no pagespeed impact. Here's the analysis and details: https://plugintests.com/plugins/wporg/advanced-custom-fields/latest

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.

Recommendation that a choice have to be made not an auto selected continent value. The downstream result is that while GeoTargeting is enabled later use not as expected for bucket region. While this is best for performance the context of usage has a disconnect.