Advanced Custom Fields

First use is saving blocks as global entities. And two, saving groups of blocks as "templates" for new content. Allow, with the GUI (and/or code, of course), to pre-populate new content with these templates.

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.

I just tested how the v3 block changes will impact our blocks. In doing so I see that the acf>mode value in blocks.json is no longer being respected, not for v2 blocks either (contrary to what is written in the release posts which say that v2 will keep working like it did). We usually use mode:preview, and force the users to use the fields on the side. But even with v2 blocks, you can now switch to the edit mode in the UI. I can somewhat understand that in v3 this won't be an option – because no edit mode will be available anymore. Some feedback about the edit button – might I suggest removing the edit button and instead adding a "expand" icon in the block sidepanel, which brings up the larger panel with block fields. Perhaps the "mode" needs to be thought out from scratch. Just throwing an example out there field_position: auto (both), sidebar, full auto – gives the current solution (though I would recommend adding a expand button) sidebar – fields are only shown in sidebar, full – fields are only visible in the expanded panel, sidebar shows a short text and button for accessing these. Why though? sidebar: if fields are simple, you don't really need the additional view full: if you have large repeaters, flexible content, nested fields, etc. those will just look very cluttered in the sidebar

Hello, the block api v3 is a really good upgrade of the system but it doenst work in a user friendly way. Mode function is removed and its always in preview mode. This results in a sidebar with all acf fields cramped up against eachother. I would suggest the Mode comes back to fix this issue. Mode: auto -> When block is clicked the popup opens. (no acf in sidebar) Mode: preview -> When block is clicked acf shows in sidebar. (pencil opens popup) Mode: edit -> Removed. Doesnt work with iframe system right? More info about my issue is in this post: https://github.com/AdvancedCustomFields/acf/issues/955

Love the ability to create/save options on a Select field when you have "Select Multiple" enabled. It would be useful for regular selects (select one) as well.

Hi, are you planning to make a MCP support ? Since it's really good to use LLM to make the first .json for a new component and that's work great, it's gonna be a huge improvement to add a mcp for your app !

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'; }

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

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.