Advanced Custom Fields

I am using power automate desktop to create a flow that I want to be able to add a new custom post type through the automation.

when use the Range field on backend it looks like this https://prnt.sc/AEv_eprUswgz with the number input below, i think it is ugly to the UI. In previous versions of ACF Pro the number input was on the right side of the range bar, which was good. no matter if the field is wider, the number stills below https://prnt.sc/VdPCovtR876K the solution is adding this custom css manually for backend .acf-range-wrap input[type=range] { width: 55%; } but ACF team should include an automatic adjustment in new plugin updates

I would like what is essentially halfway between a Textarea field and a WYSIWYG field. It would be the Textarea field in all aspects, except it would also have very simple format controls, like bold, italic, list items, and link. Use case: A client has a heading with one word that is a different colour/font/size/etc. At the moment, our options are using HTML in a text field, or using the basic version of the WYSIWYG field. We don't want to make it too complicated for clients by forcing them to use the HTML code, and the WYSIWYG field takes up a lot of space for what is usually no more than a couple of words.

The Button Group field has the option to display the buttons either horizontally or vertically. I would like to be able to display them in a grid. My use case is for setting the background-position of a background image, and a 3x3 grid with icons will look a lot nicer than the select field I am currently using. I could use 2 Button Groups, one for horizontal alignment, and one for vertical, but I think a grid would get the purpose across much better.

It looks ACF blocks that are in patterns are not preloaded. Since patterns are loaded on every block editor edit screen, this is a big performance hit. I can set an XDebug PHP breakpoint in my block template, save the block to a pattern, then load a new post with no blocks and see the PHP breakpoint processed. The block is still listed in the browser javascript console when I run acf.get('preloadedBlocks'), but I think the PHP breakpoint indicates the preloaded block is not used for loading the pattern. The pattern is still loaded with a new request to render the block.

"Unfortunately, this is how ACF currently works. The selection in that taxonomy cannot hide or show a field group other than using custom Javascript to detect the change and show \ hide the field groups." I have an ACF taxonomy field and I would like for it to be able to show/hide ACF Field group, the support told me it wasn't possible by default.

Sometimes you need to use a WYSIWYG field for shorter texts and when a WYSIWYG field field is placed next to normal input it's initial height is just too huge. It would be nice to have some control over it.

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

Dear Advanced Custom Fields Support Team, I hope this email finds you well. I'm reaching out to discuss a hypothetical scenario involving the use of ACF Pro licenses and how to programmatically respond to changes in license status. This is purely theoretical and not indicative of an immediate need but rather a preparation for potential future situations. Here's the scenario: Suppose I provide a client with a website that includes the ACF Pro plugin activated with a license key. If, for any reason, I need to restrict the client's access to the website, I would want to do so by remotely deactivating the ACF Pro license through the official ACF backend. Once deactivated, I would like to implement a method to check the license status via code and disable the website's functionality if the license is no longer valid. To prepare for this hypothetical situation, I have a few questions: Is it possible to remotely deactivate an ACF Pro license key associated with a client's website through the ACF backend system? If I were to deactivate the license, is there a way to check the license status programmatically on the website itself? In the event of a license deactivation, what would be the recommended approach to disable the website's functionality through code without affecting the already published content? I understand that the ACF Pro documentation states that the editing and display of field data outside the ACF admin screens will not be affected by the license status. My primary concern is to restrict access to the administrative features of the website, particularly the ability to create and edit PRO fields. I appreciate your guidance on this matter and any insights you can provide into how ACF Pro licenses can be managed in such a scenario. Thank you for your time and assistance. My email is jack361@qq.com . Thank you very much for your reply.

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.