Advanced Custom Fields

Since WordPress 6.2 <InspectorControls> can have “group” attribute – for example <InspectorControls group="styles"> – possible options are: – settings (default) – styles – color – typography – dimensions – border – advanced My use cases: – when creating simple ACF blocks without any field (wrappers like “container” and “group”) – for purpose of only using native Gutenberg fields from “Styles” tab and there’s no option to remove default “Settings” group completely (so in this case I would like to have no “Settings” and “Styles” tabs – similar to native paragraph block). – ability to add fields directly to one of groups – for example to color “group” to add ability to change color of specific ACF text field (so user can set all color settings from the same place in sidebar).

Now we have custom post types, it's be great to allow fields to be shown easily in admin columns without code

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?

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.

I suggest proper ClassicPress support. This would now be THE time. CP is not a pseudo-FOSS subsidiary of Automattic, but a community-driven fork. Also, much swifter without the Gutenborg clutter, less jQuery, less security issues, and better media database :) cu, w0lf.

I have an ACF Pro subscription, and when I contacted support about a website I run, they asked me to post this here. I apologize if this is not the right place to post this. Currently, the problem in my environment has been resolved (by resetting the DB), but I don't have the time to execute the following again to reproduce the problem. Please forgive me. ----------------------- I put the ACF field group in the "Trash". (This was a mistake.) Next, I restored it from the "Trash". Then, "__trashed" was automatically added to the end of the field key of some fields (I wonder why it was some and not all). For example, what was originally field_1212121212121 became... field_1212121212121__trashed This caused me a lot of trouble because I could not load the field correctly from themes or programs. I have now restored from a DB backup and this problem on "my website" has been resolved. ----------------------- However, I think this problem is too fatal to be caused by a one-click mistake (putting it in the trash). The issue of "__trashed" being automatically added to the slug of a "post" that has been put in the trash seems to be something that is not limited to ACF, but I have not been able to identify the cause of this problem. *You can find several example cases by searching "WordPress __trashed" on Google. What I hope for the time being is that this problem would occur less often if it were no longer possible to accidentally put something in the "trash" from the ACF custom field list screen. For example, an alert could be displayed saying "Are you sure you want to put this in the trash?" Of course, it would be best if __trashed was not added to custom field keys. Thank you in advance for your consideration.

There's one feature in Pods which I find useful is that when you rename a CPT or a field, it will also update accordingly in the database. This will save much time without having to alter the database values directly.

We need an extra 'add field' button. It would sit on all fields and would add a new field just below the field it was created from. This would help eliminate the annoying drag and drop that we need to do when adding new fields up top. Please see example screenshot.

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

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.