ACF Chat Fridays are open office hours with the ACF team and users, featuring live discussions of all things ACF, answering your questions on building sites with ACF, getting the most out of your fields, and what’s next for the plugin.
The December 8th session of ACF Chat Fridays looked into AJAX validation with ACF forms, the potential for an ACF Blocks UI, adding ACF fields to WordPress core blocks, and much more.
Co-hosted by Iain Poulson, Matt Shaw, Anthony Burchell, Damon Cook, and Brian Hardie.
You can see the entire session in the player below, or catch the highlights in the session summary.
December 8th marked the last session of ACF Chat Fridays for 2023. ACF Chat Fridays will return to its regular biweekly schedule on January 5, 2024.
Iain Poulson launched the final session of 2023 with a quick update on the release of ACF 6.2.4, with another bug fix release, ACF 6.2.5, likely to follow in early 2024. The remainder of the forum was dedicated to user scenarios and questions.
Questions about the best way to use ACF, feedback about the plugin, or feature requests? ACF Chat Fridays is one of the best places to make sure your voice is heard and your questions answered.
We’ve included some of the questions and answers from the latest session below, with minor edits made for clarity and style.
Q: I built a flexible block with some baked-in ACF forms, so you could insert the block, and you’d have your ACF options in the sidebar and do things like change the button text, whether it added an email, an opt-in, and so on. It was working nicely, but one of the big things I came up against was AJAX validation.
If you’re rendering an ACF form in the backend, and you try to save that page, the fields fail validation if they’re not filled in.
I thought I had gotten around it originally by using the acf/load_field filter, and basically saying “if you’re in the admin, and it’s this form, just set
This worked to a point, but it was preventing AJAX validation from working. If my field failed validation, instead of saying “You must fill in this field”, it took me to a whole other page saying validation had failed and that I needed to fill out the form.
I found the exact same question on the ACF Extended forum, and the answer there appeared to be “don’t render your forms in the block editor.” This is a shame, as it was really nice, it was building out the form in real time as the user was selecting the options so they could see what they were going to get.
I have solved this using a JS filter, but I daresay that approach is a little heavy handed. I haven’t seen much discussion of this online, so I thought I’d raise it.
A: We’ve had instances where an ACF form is being used on the front end, and it’s either been triggered by another submit process or it’s triggering somebody else’s submit process. When you’re in the editor, and click Save Post, that hits a submit trigger that ACF listens for. It will then say “you haven’t submitted this form” because there’s no context or awareness that you’re actually in the editor, and nobody is really submitting your form, you’re just showing it to the editors. We should look into making sure ACF forms don’t have a submit when they’re in the block editor for cases like this where no one really needs to fill out the form in the block editor, it’s just a way of letting editors view what they’ll get on the front end.
Q: Are there any plans to include a more “drag and drop” interface for creating ACF blocks? The recent updates have been very useful, like creating option pages, and integrating custom post type and taxonomy integration.
A: Yes! We’re currently working on this. Registering ACF Blocks may be the last remaining thing in ACF where you must code. We’re looking at the best way to implement a UI for creating an ACF Block. It would be a great addition to ACF PRO.
ACF Blocks are essentially a PHP template and a
block.json file. The
block.json file has a ton of configuration options that aren’t entirely clear. ACF inherits the
block.json structure for block creation from WordPress, but there isn’t easy documentation around that.
The screens ACF has in place for registering options pages, custom post types, and taxonomies are really helpful for users, especially if they either don’t know exactly what they want to do, or if they simply want access to the whole array of options and settings, and then you can use our screens to see the simple stuff first and then add in more advanced settings.
We hope to launch a UI for ACF Blocks sometime in the next year.
Q: It would be great if we could attach an ACF field to an existing core block. I’ve been using Query Loop blocks extensively, creating block variations and pre-query hooks to customize it in various ways. But the scenario
The use case I keep encountering is where someone wants to use a Query Loop block and specify which posts it will fetch. For example, you might be using a Query Loop block to loop over a post type of “Products.” You can say “give me six products” or “give me products ordered in this way,” but you can’t say “just give me this product, this product, and this product.”
So far, the way I’ve solved this is by saving it as
post_meta. For example, we had a website with a load of members and a board of advisors. We needed a block that would just show those board members. I used ACF to insert a Post Object field on the post type where you select the group members, and then that’s saved as
post_meta. I’ve made a Query Loop block variation that filters the arguments to say “if this
post_meta exists, override the query and just show me those things.” This attaches the meta data to the post, rather than to the block. It doesn’t render in the back end, but it works on the front end.
Being able to attach ACF fields or ACF Blocks directly to a WordPress core block like Query Loop would be incredibly useful.
A: Nick Diego has been doing a lot of interesting work lately on extending core blocks. I’d suggest looking him up just to see how that flow of data can go. But of course, with ACF Blocks, you have PHP for the templates, so inserting those into a WordPress core block might be tricky just because of that disconnect.
I feel like that you could use ACF fields with core blocks, and then do something with them in the field data, but inserting ACF Blocks into a core block would be more difficult.
Update: During the 2023 State of the Word address, Matías Ventura indicated that the ability to connect core blocks to custom fields will be coming to WordPress core. The example he gave was to insert a heading or a paragraph into a core block, and indicate that you want it to come from a custom field.
Q: Is there a way to iterate over an ACF Block’s configuration and output a string of inline styles? When I have an ACF Block, and I’ve configured
font-size, etc., they’re all stored in different places. Unless I’m missing something, it seems like an arduous process to go through every time.
A: You should be able to do this with the get_block_wrapper_attributes() function. It allows you to use the styles built by WordPress’ native
supports for a block, such as background and text colors, padding, margin, etc.
There are some cautions when applying this in your ACF Block PHP template. If that function is used when the block is rendered in the editor, you’ll get a PHP warning. Instead, use ACF’s
$is_preview variable to know when your block is being output on the frontend, and then use
get_block_wrapper_attributes() to add all the styles selected for your block. See ACF Blocks: Using get_block_wrapper_attributes() for more details.
We share relevant resources during the call. We’ll sum them up here and try to provide a bit of context:
Join us on January 5th, 2024 at 3pm GMT for the next session of ACF Chat Fridays.
What do you think we should cover during the first session oft 2024? Let us know on Twitter.
Sign up for the next session of ACF Chat Fridays here:
The list of upcoming sessions is below. You can watch the November 10th session on YouTube.