ACF Chat Fridays offer an incredible opportunity to meet with other users and the ACF development team. Each session answers your questions about the best way to build WordPress sites with ACF, and provides insight into new features coming to the plugin.
The November 10th session of ACF Chat Fridays dug into recent and upcoming releases for ACF, using ACF with page builders, and ACF Blocks.
Co-hosted by Iain Poulson, Matt Shaw, Liam Gladdy, and Anthony Burchell.
You can see the entire session in the player below, or catch the highlights in the session summary.
The November 10th session focused on user questions and feedback, with questions ranging from using ACF with page builders, using ACF’s Flexible Content field as a page builder, ACF Blocks, and much more.
In addition to the Q&A, the session also covered details of what to expect in ACF 6.3, as well as news about the recently released ACF 6.2.2 and the upcoming release of 6.2.3. These are primarily bug fix releases, but with a few enhancements in the mix. ACF 6.2.2 adds a new
acf/filesize filter to allow third-party media plugins to bypass ACF
calling filesize() on attachments with uncached file sizes, which may result in a remote download if offloaded. In addition, ACF Blocks which have not been initialized by the editor will now render correctly, and ACF PRO license status and subscription expiry dates are now displayed on the “Updates” page.
ACF 6.2.2 also includes fixes to ensure product pages for WooCommerce version 8.2 or newer will now correctly support field group location rules, color picker fields no longer autocomplete immediately after typing 3 valid hex characters, and more. Please see the ACF 6.2.2 release post for more details, and expect more bug fixes and enhancements in ACF 6.2.3.
The final session of the year takes place on December 8, 2023. For more, please make sure to watch the session here.
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’m using ACF and Elementor. I’ve created a custom publication type called “products”, and custom fields that I use to customize the page. I’ve also created a Relationship custom field to retrieve similar products to be displayed at the bottom of my product page. But I can’t use this field in my similar products block, I can only retrieve products in the same category as the main product on the page. How can I use my Relationship custom field?
A: ACF is positioned around determining what data you need and giving your content editors a way to fill in that data. How it’s displayed on the frontend has more to do with the tool you use to display that data, in this case Elementor. They might have components that allow you to to change where the selection is coming from and plug that into an ACF field.
Q: I’m increasingly having clients who want the ability to manage/build templates themselves. I love how ACF and Elementor make it easy for them to do that, but it only works on some ACF features. Is there anything in the works to make this kind of easy integration with more WordPress builders or base WordPress?
A: We have to rely on page builders to include ACF integrations. We try to make it as easy as possible with hooks and filters, but the moment we shipped any code for a specific page builder, we’d be chasing our tail on every single release they do. You’re probably better off reaching out to the page builders directly in cases like this. We have a pretty good relationship with a lot of the page builders, so if there’s anything that they want to do, they could reach out to us and ask about deploying what they need.
Q: We use ACF’s Flexible Content as our page builder, with no other builders. We’ve got a lot of templates to choose from. It’s pretty fast when I’m building, but when a client wants to add a new page and they start to build it out, we sometimes get 502 errors. Is there anything coming in the future to help speed up or optimize Flexible Content?
A: This is a performance issue we’re aware of and working on. If you’ve got a post with 200 fields, when you edit the post, you’re loading 200 field inputs in the DOM, getting them all from the database and then writing them back to the database when you update the post.
This issue can arise with any field, but it tends to show up the most with Flexible Content fields, as there are often multiple layouts and lots of fields within those layouts. We are working on performance improvements for this. Right now, when you load an ACF field group, it loads the entire DOM. We’d like to get rid of that, and have it only loads what it needs to, when it needs to.
Q: I’m having some issues with the ACF Blocks I create not outputting things like
appearance on the frontend, although it appears to work in the back. I’ve registered the
support in my block.json file, but does this need to have its own class variable in my
A: When you click on any of the supports that you’ve registered, WordPress dynamically applies a wrapper to the outputs you see in the back end so you can see them live. The fact that you can see those supports in the block editor means they’re registered correctly, as they wouldn’t be available otherwise.
Make sure you have
is preview set to
true, and that will basically load all the values you’ve set in your supports, and output them only for the frontend.
The get_block_wrapper_attributes() function reads all the block supports that need to be passed to the block, such as CSS. etc.. If you’re using that function, that should take care of almost everything. Please reach out on Twitter) if this doesn’t work and we can try to dig into your specific block.
Q: I’m jumping into ACF and modern WordPress development, and our team is used to the pattern of create custom blocks -> register them -> build pages by adding the required blocks.
I don’t understand what is the configuration difference between the
block.json and the options that can be set when registering the component in
Currently my block registration just does a glob search on the
blocks folder so I don’t have to register every component individually. Is there a better pattern for going about this?
A: In theory, you could define everything in
functions.php, but we don’t recommend this. Using
block.json passes a lot of other stuff, like WPDefinedAsset, which is how you load scripts and styles. That can be really difficult to do the PHP way.
This depends on your tooling, but the easiest way to search is likely what you’re doing now: a glob search on the
blocks folder. Make sure you’ve got it set up to handle compiling all your block assets, CSS, etc., that are specific to your blocks.
Q: Is there any news on ACF Blocks field validation and using ACF Blocks with WordPress React components?
A: We’ve been working on these features, and we expect that block validation will be included in the next major release, ACF 6.3. Regarding React components with ACF Blocks, we’ve discussed ways for those on a headless WordPress setup to use frontend components they’ve built as the preview in the editor, rather than having to rebuild the components as a PHP file. That may appear in 6.3. As for actually using WordPress React components with your ACF Blocks, that’s a bigger challenge and will not be included in ACF 6.3. This is something we’re still working on.
We share relevant resources during the call. We’ll sum them up here and try to provide a bit of context:
Join us on November 10th at 2pm GMT for the next session of ACF Chat Fridays.
What do you think we should cover at our session in December, and sessions throughout 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.