Advanced Custom Fields

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.

WordPress Core already handles 4-byte characters (such as emojis and some special Unicode symbols) in post_content, helping to avoid content truncation on sites that still use older database configurations. It would be very useful if ACF could provide similar handling for values stored in postmeta, especially for WYSIWYG, Textarea and Text fields. While updating database tables to utf8mb4 is the recommended long-term solution, many users are not aware of their database configuration and never access it directly. From a user perspective, content entered into an ACF WYSIWYG field is expected to behave in the same way as content entered into the standard WordPress editor. This becomes particularly important because a user may paste a large amount of text containing a single 4-byte character and unintentionally lose everything after that point if the database cannot store it correctly. Possible approaches could include: Automatic detection of unsupported 4-byte characters. Encoding or sanitization methods similar to WordPress Core. An optional setting such as “Ensure 4-byte / emoji compatibility”. Admin warnings when the database configuration may cause truncation. Providing native handling within ACF would improve consistency with WordPress Core and help protect users from unexpected data loss, especially on older sites that have not yet been fully migrated to utf8mb4.