24 Aug

ACF PRO 6.0 RC 1

By Iain Poulson

ACF PRO 6.0.0 RC 1 is now available for download 🎉!

This release includes the repeater pagination feature and new generation of ACF Blocks from Beta 1, as well as introducing the new plugin UI refresh.

ACF 6.0 has been released! Read the release post.

Call for Testers

We’d love to get as many eyes on this release candidate as possible, so if you can please help us kick the tires and take it for a spin. We are also hoping that those developers who have written plugins or code to extend ACF will test their code with the new release.

Translators

ACF 6.0 uses a new system for translation that we detailed in the beta 1 release post. The short version of this is that translations are now built from translate.wordpress.org, combined with PRO strings which are submitted on GitHub

Get the Update

To access this release, PRO users can login to your account, navigate to the “Licenses” page and select version “6.0.0-rc1” from the available downloads.

For ACF Free users, the 6.0.0-rc1 release is available on the GitHub repository.

We’d love to hear what you think of the new features. If you have any questions or issues with this version then please don’t hesitate to get in touch.

What’s Next

We’re aiming for general release some time later next month, and we may ship an RC2 release in between.

Full Changelog

New – ACF now has a new refreshed UI with improved UX for editing field groups, including a new tabbed settings layout for fields. New – Repeaters now have an optional “Pagination” setting which can be used to control the number of rows displayed at once. New – ACF Blocks now have a versioning system allowing developers to opt in to new features New – ACF Blocks now support version 2, enabling block.json support, reduced wrapper markup and significant other new features New – ACF Blocks no longer use Block IDs saved in the block comment Enhancement – Bulk actions for field groups now include “Activate” and “Deactivate” options Fix – ACF will no longer perform a multisite database upgrade check on every admin load once each upgrade has been performed Fix – ACF Block templates which render other blocks will now have their InnerBlocks rendered correctly Fix – ACF Blocks preloading now works for blocks saved in edit mode Fix – ACF Blocks edit forms now behave correctly if they are not visible when loaded Fix – ACF Blocks now always fire render_block_preview events when a block preview is displayed or redisplayed Fix – ACF Blocks with no fields now display advisory text and are selectable in the block editor. This message is filterable with the acf/blocks/no_fields_assigned_message filter, providing both the message to be displayed and the block name it’s being displayed against Fix – Accordions inside ACF Blocks now match the current native block styling Fix – ACF Blocks which contain no fields now preload correctly Fix – Changes to an ACF Block’s context now trigger a re-render Fix – A rare warning inside wp_post_revision_field will no longer be possible Fix – The field “move” option now no longer displays for fields when only one field group exists Fix – Language for field group activation state now standardized to “active” and “inactive” Fix – SVGs containing foreignObject tags now correctly render in JSX rendered ACF Blocks Fix – Server errors during ACF updates or version checks are now cached for 5 minutes rather than 24 hours Accessibility – The new ACF UI has significantly improved accessibility for screen readers and alternative input options i18n – All strings inside ACF are now translatable i18n – Accented term names in taxonomy fields are no longer corrupted at output i18n – ACF translations are now synced with contributions from translation.wordpress.org at each release, increasing ACF’s supported languages and updating many other translations. PRO strings should still be submitted as pull requests on GitHub (Additional thanks to maximebj, emreerkan and Timothée Moulin for their contributions which are included here)

About the Author

Iain is the Product Manager for Advanced Custom Fields. He has a long history of building and growing WordPress plugins. Moonlights as a PhpStorm evangelist.

Tagged in

Release

Continue Reading

Blog Archive  / 

For plugin support, please contact our support team directly, as comments aren't actively monitored.

  • Jens says:
    August 24, 2022 at 12:07 pm

    I’m sorry but I personally don’t like the new UI. It looks good, don’t get me wrong but using the basic WordPress UI makes more sense in the backend. I’m now worried that this makes it all load slower. All the plugins are using their own UI.. it makes the WordPress backend look like a mess, but that is not on you only.

    • erik62 says:
      August 25, 2022 at 4:46 am

      This!

    • Bart Bak says:
      August 25, 2022 at 8:36 am

      I must say I partially agree. The new UI looks nice and clean, and from what I see improves the whole experience of configuring and setting up. The problem I have is every plugin uses a different UI, there is zero visual consistency on the admin side which makes WordPress look very visually "disorganized" and chaotic, plugins break the visual language of the admin panel. A limited library of the WordPress UI is also a thing. But no regulation = freedom. Btw, I love the product and will continue supporting but wanted to share my thoughts since I like the have a clean and seamless user experience on the admin side. Since we build products for people, it also helps the non-technical user navigate across the admin pane without learning new behaviors and interactions.

    • Glenton Samuels says:
      August 25, 2022 at 10:17 am

      What even is basic WordPress UI at this point? Gutenberg’s UI and controls look completely different from the rest of the WordPress admin. Even essential plugins like WooCommerce do not adhere to the basic WordPress UI. Look at Jetpack and those plugins are from the same company lol. The real issue is WordPress never established any design resources or guidelines for the admin. There are no robust set of UI controls or patterns to reference so plugin devs have to pick up the slack and this is what you get.

      • Jens says:
        August 25, 2022 at 10:29 am

        The default WordPress UI is what the plugin loads now. The plugins you mention are all plugins that non-developers work in on a daily basis. ACF (it’s in the name) is not made for people who want something simple. Those people use a page builder…

    • bosettiandrea says:
      September 2, 2022 at 9:04 am

      Totally agree. @ACF Team, don’t get me wrong: thanks for your work and improvements but this shift of UI feels like first step of overcomplicating things, shifting away from what made ACF so great. ACF before version 6.0 felt like a natural extension of WordPress, as a plugin should be in my opinion (especially an important plugin like this one). Please reconsider this change or think about a simplified version of ACF for casual users, leaving the pros with what they know and love. Thanks.

  • Tom Hole says:
    August 24, 2022 at 2:07 pm

    I would second what @Jens said. The UI looks modern/clean and great. If all of WP looked this I would be thrilled.
    I build with as low a plugin-payload as possible and try to give me clients as close to a native WP experience as possible. This just makes yet another bit of WP look like a completely different tacked on CMS. On it’s own it looks great. Tacked into the WP backend it – like every other plugin that tries to revent the WP dashboard wheel – looks a mess

    • kelseybarmettler says:
      August 24, 2022 at 4:02 pm

      Thirding what’s been said here. There’s a reason the opening paragraph said "there’s a good reason for [not changing the ACF UI]. It’s worked so well since it was introduced and has always felt native to WordPress’ own UI." Changing the appearance of buttons and other elements is absolutely immaterial to the goal of making ACF easier for non-programmers to use.

  • Michael Thomas says:
    August 24, 2022 at 2:10 pm

    I love the new look! Can’t wait to upgrade.

  • Baxama says:
    August 24, 2022 at 2:12 pm

    Please add a possibility to continue to use the plain standard WordPress UI font, elements, colors, style. In a plugin which adds custom fields, there is absolutely no need for fancy own loading and rendering time increasing and round border whatever blingbling. Thank you very much (long time paid licence user).

  • Zeshan says:
    August 24, 2022 at 2:14 pm

    Excited for the UI but worried for the UX

    • Liam says:
      August 24, 2022 at 4:53 pm

      Hey Zeshan! Feel free to give it a play and give us any feedback. ACF’s UX was the foundation of the reskin design, and every change we’ve made was specifically to try and improve the experience for developers – so we’re exciting to hear your feedback!

  • Zeshan says:
    August 24, 2022 at 2:15 pm

    There’s a typo btw: "…users will be able to upgrade with changing any code…" Shouldn’t it be: "…users will be able to upgrade without changing any code…" ?

  • Bowe Frankema says:
    August 24, 2022 at 2:30 pm

    I love the thought you put into the UI/UX overhaul and I do not agree with some of the people here. This is related to the user interface for us (the developers). It has no effect on our end users, so the criticism about "making the backend look like a mess" do not hold up. It seems it’s much easier to work with large field groups and some much needed fixes. I’ve not seen any changes to the actual metabox output, but that is already a mess so I say keep doing what you’re doing. Looking forward to the release!

  • Evan Fraser says:
    August 24, 2022 at 2:39 pm

    Looking great so far, I really like this, reminds me a bit of the Gravity Forms UI. Will these UI updates carry over to options pages?

  • GLOC says:
    August 24, 2022 at 2:54 pm

    I use the front-end forms extensively, does this effect me? I hope not, as I have entire websites based on the old ui. This might break all of them in numerous and possibly unseen ways.

  • Frank says:
    August 24, 2022 at 3:22 pm

    Remember when WP introduced Blocks, everybody hated them (specially freelancers and their clients) and now the Classic Editor plugin has 5+ million installs. If ACF can learn from that lesson, it should have the option of making this new UI optional. Power users will have a hard time using this new UI. When I am working with 25 custom field groups, each with over 10 fields (and most with repeater, flexible or clone field types) I want access to all in one shot, no tabs, no jazz, nothing hidden. I think the effort could be directed to different areas of the plugin, like an interface to create custom locations or rules without having to do it manually in the functions.php file.

  • Rai says:
    August 24, 2022 at 3:36 pm

    I love it! waiting to get the it.

  • zack9 says:
    August 24, 2022 at 4:11 pm

    I disagree with the negative UI comments below. I think these are great changes and welcomed! If you’re so concerned about it not matching WP, load your own style sheet. I certainly do. I always customize WP backend! Great update acf

  • Brad Needham says:
    August 24, 2022 at 4:15 pm

    Really hope this ui update gets added to edit screens!? Clients would love this! Current ui is quite aged… We’ve been waiting for updated client side ACF editing ui update for a long time.

    • Liam says:
      August 24, 2022 at 4:51 pm

      Hey Bradley! For 6.0, we’re sticking with the field group edit screens. We’ll discuss if we could make it available (opt-in of course – as many users wouldn’t want an automatic change here) for a future release though!

  • Elly says:
    August 24, 2022 at 4:15 pm

    Exciting to see 6.0.0 on the horizon! Looking forward to seeing new updates to working with Gutenberg and continued improvements to nested blocks, too!

  • apmeyer says:
    August 24, 2022 at 4:19 pm

    I use the auto generated $block[‘ID’] for a variety of things. Is this value/property going to be non-existent in 6.0 or will it simply output something with the new methodology described? If it’s going to output nothing that’s going to be a big problem for many past projects.

    • Liam says:
      August 24, 2022 at 4:49 pm

      It’s definitely not going away! It’ll still be there, but the format of it will be different in ACF 6.0. It’ll be much longer (for example, it’s block_d892f1b0eea73986514a997d68d29741 in an example block I’ve got here now) – it’s now based on a hash of the attributes and data for your block, which means blocks are much more portable as you can copy/paste blocks, or use them in block patterns etc without worrying about block comment stored block IDs causing issues.

      • apmeyer says:
        August 24, 2022 at 4:59 pm

        Whew. Ok. That should work just fine.

      • Andrew Fair says:
        August 24, 2022 at 5:25 pm

        Hey Liam, From what this says | We’d specifically like to draw attention to """block ID removal in ACF 6.0""", as it’s something you should be aware of if you’re using $block[‘ID’] in your block templates. These block IDs are no longer saved in the block data, and are generated based on a hash of your block’s attributes and data. This reduces the chances that you’ll have duplicate block IDs on your page than in ACF 5.x, as ACF Blocks inside Query Loop Blocks will no longer have duplicate IDs, and enables support for things like block patterns and custom post type block templates. | I think the word Removal is making me think it’s going away. I have far to many websites built with multiple blocks per page that require a unique number. So it greatly concerns me the use of "removal" if it’s not removing but changing. I do see where it says "and are generated based on a hash of your block’s attributes and data" so it implies that something is being made. So this is confirming it doesn’t mean removed but "overhauled" or "modified". Even in the ACF documentation it says to use the $block[‘id’] to create unique IDs.

        • Liam says:
          August 25, 2022 at 11:48 am

          Hey Andrew, That’s a fair comment – I’ll edit that to be more clear. By "removal" there, I mean specifically the saving of block IDs to the block comment (the actually text that WordPress builds that contains the data and attributes for your block) We’re definitely not going to remove block IDs from being available to your block templates! I think when blocks were first added to ACF, you could rely on block IDs being unique, but with recent WordPress changes like block patterns, block styles, full site editing and query loops – the odds of a block ID being duplicated on a page increased significantly. ACF 6.0 reduces the chances of a block ID being duplicated to one case: Where you’ve got two exact copies of the same block on the same page, with exactly the same data, field values, attributes, etc. We can’t really work around that case, so we’ll be clear that a block ID has a (albeit small) chance of not being unique still with ACF 6. For those situations, we’ll provide some example code for how to add a random ID to each block on save, so you can have some element that unique, but we’ve found most cases of people using block IDs is to output <style> tags in their template, which while it’s not valid HTML to have the same ID on two elements, that case will not result in anything breaking.

          • Baxama says:
            August 26, 2022 at 5:29 am

            What happens if I add/remove/change attributes of my block in a later revision/update of my project? Will blocks/data still be found and correctly referenced everywhere?

          • Earle Davies says:
            August 26, 2022 at 4:01 pm

            I understand the logic of generating a block ID based on the contents of the block to keep them unique. However I don’t understand the logic of generating them on the fly and not storing them as they were before. I use those block IDs to be able to validate data when someone interacts with a block on the frontend. Sometimes sensitive data is stored in the ACF field on the page that’s not output on the frontend. Then I need to retrieve those values and compare to a block ID from the frontend. This seems no longer possible unless I somehow use the new undocumented pre_save_block hook.

  • apmeyer says:
    August 24, 2022 at 5:02 pm

    I’d love to see some time spent making certain fields more usable in the Gutenberg Sidebar. There are a few – such as the wysiwyg field – that are mostly unusable without switching a block to edit mode. It would also be nice to be able to disallow edit mode so that a block cannot be flipped over to a set of fields – effectively making the sidebar the only option for managing ACF settings for the block.

    • Tom Hole says:
      August 24, 2022 at 5:33 pm

      You can disallow edit mode already When you call the ACF block you can use ‘mode’ => ‘edit’ That will only allow it to show as an edit field. You can then also add image support preview to drop a screenshot in to make it a more useable for clients without having a full-fat backend render https://gist.github.com/stirtingale/e6008d230335790ffd8d5b310780e383

      • apmeyer says:
        August 24, 2022 at 5:45 pm

        Thanks, but that’s not what I’m after. If an ACF Block has InnerBlocks it can’t be set to only be in edit mode or that InnerBlock area is useless. I want an option to NOT have edit mode. Preview only for working with InnerBlocks and seeing full render; ACF Fields available in sidebar when the block is selected.

  • Nathaniel Meyer says:
    August 24, 2022 at 5:28 pm

    Will you be improving the users Experience when managing content. This is actually more important for us. I don’t care so much about the interface I use as a developer creating the fields. However the customers we build the website with need to manage content and the current UI is dated, slow and hard to navigate (mainly flexible content ) I would take some notes from ACF extended for this.

  • Stephen Morton says:
    August 24, 2022 at 6:27 pm

    I really appreciate the thoughtful UX improvements here! However, like others, I do have some concerns about changing the UI. I’ve always appreciated plugins that don’t try to reinvent the wheel and use the standard WordPress styles wherever possible. ACF has always been great with this and it looks like an official extension of the WordPress admin. It’s not a deal breaker by any means and I do genuinely think the new UI looks good and modern but wanted to add my feedback.

  • Karol Piekarski says:
    August 25, 2022 at 2:36 am

    Hi! Will it be possible to copy data in the repeater?

    • Liam says:
      August 25, 2022 at 9:00 am

      Hey Karol! You can duplicate rows in a repeater already by holding shift when you mouse over a column and hitting the "duplicate" button that shows up!

  • Alex アレックス says:
    August 25, 2022 at 5:04 am

    Hey, at first I also thought why change the default WP look. But for me it works and as long as my clients have the default feeling, thanks! One small thing I noticed while using it: https://capture.dropbox.com/BgTCKBTcIBF56vwA Maybe it’s because I have the font "Inter" installed local but the text looks reaaaally unsharp. Noticed this right away. Latest MacOS and latest Chrome.

  • Simon Bach Dall says:
    August 25, 2022 at 5:40 am

    Hi will this version include the ability to rename fields without data loss?

  • Gareth says:
    August 25, 2022 at 5:44 am

    Looks very clean, a nice update – eager to get back to ACF development, was our default development tool for years to provide flexible CMS’ for our clients before we moved to Elementor. Great work, Gareth

  • Andrius Pekarskas says:
    August 25, 2022 at 5:51 am

    Very slow 🙁

  • Baxama says:
    August 25, 2022 at 5:54 am

    Question about this:

    block IDs are no longer saved in the block data, and are generated based on a hash of your block’s attributes and data

    What happens if I add/remove/change attributes of my block in a later revision/update of my project? Will blocks/data still be found and correctly referenced everywhere?

    • Liam says:
      August 26, 2022 at 5:42 am

      Hey Baxama, for some reason I can’t reply to your reply to my post, but I can reply to this one! What do you mean by found and referenced everywhere? The block ID will be updated everywhere the template it output – but if you’re relying on finding a block by a hardcoded ACF block ID in other code, that wouldn’t work correctly even in ACF 5, as Block IDs would occasionally change previously too.

      • Baxama says:
        August 27, 2022 at 7:25 am

        The block ID is used in example code in ACF documentation e.g. for specific styling and for custom "anchor" values.

        https://www.advancedcustomfields.com/blog/acf-5-8-introducing-acf-blocks-for-gutenberg/ https://www.advancedcustomfields.com/resources/blocks/ https://www.advancedcustomfields.com/resources/acf_register_block_type/

        Changing this ID can affect e.g. cached/minified css, links to anchor navigation, and also whatever else use of the ID has been made by developers based on the ACF documentation examples. Besides that, using things like block attributes (which can/will change over block code updates) to generate hashes for whatever later use is in general a not so bright idea.

        • Liam says:
          August 29, 2022 at 8:49 am

          Sure – the cached/minified case is definitely something people should be aware of, but we’d also expect the output HTML to be cached in this case too. Also, ACF 5.x would regenerate the block IDs in certain conditions, so this is unlikely to be a new issue – especially as the block ID will only change when the page updates and that would usually clear any caches – or if new blocks are added, that minified CSS wouldn’t have the new block IDs in either. Overall though, you shouldn’t rely on the block ID being static at all (and that’s the case in ACF 5 as well), if you need a persistent ID, our release documentation will have guides on how to add that in using filters.

      • Baxama says:
        August 29, 2022 at 8:39 am

        Hey Liam, for some reason my reply here from 3 days ago is still hidden/not approved, so I repost it now, with slightly altered links, in case that is/was the reason: The block ID is used in example code in ACF documentation e.g. for specific styling and for custom "anchor" values.

        advancedcustomfields.com/blog/acf-5-8-introducing-acf-blocks-for-gutenberg/ advancedcustomfields.com/resources/blocks/ advancedcustomfields.com/resources/acf_register_block_type/

        Changing this ID can affect e.g. cached/minified css, links to anchor navigation, and also whatever else use of the ID has been made by developers based on the ACF documentation examples. Besides that, using things like block attributes (which can/will change over block code updates) to generate hashes for whatever later use is in general a not so bright idea.

      • Baxama says:
        August 29, 2022 at 8:39 am

        Hey Liam, for some reason my to tries to reply to you are hidden/not approved, too bad.

  • Jakub says:
    August 25, 2022 at 6:13 am

    The UX changes you’re introducing are nice and I’m looking forward to see that! On the other hand, the UI overhead you’re about to introduce is absolutely unnecessary and I agree with may other commenters that it’s going in wrong direction. I believe most of us professionally using ACF chose it as a lightweight yet powerful tool, to keep the WP clean and native. Elliot followed that path for years which helped ACF to gain the broad audience and fanbase it has. Don’t get me wrong – there are nice parts and it looks polished, but why the odd custom color scheme and messing with the typography? I hope you’ll reconsider toning the new UI down to keep it clean rather than making it look like another flashy builder, as you’re not far from making happy both us, "WP minimalists" and those who seek some visual freshness 🙂

  • Tom Jardine-Smith says:
    August 25, 2022 at 6:58 am

    Excited for this. Less worried than others here about the UX/additional load times as I can’t imagine DB would have ignored this element when they were building it. No. 1 feature I would love to see in the next update is independent width control of cloned elements pleeeeease! XD

  • DeltaG says:
    August 25, 2022 at 7:36 am

    I didn’t read anything about fixing a pretty big issue we’re experiencing with ACF for years now. ACF still doesn’t clean up its mess in the database. This post in the support forums explains the issue that’s been going on for many years: https://support.advancedcustomfields.com/forums/topic/flush-unused-custom-fields/. I always thought a new version of ACF would at least make some progress within this point of concern. Is this going to be addressed in the (near) future of ACF?

  • Glenton Samuels says:
    August 25, 2022 at 10:21 am

    It’s a nice update, not over top. However, I’m much more interest in seeing an update to the controls for the ACF fields. Have it match up more with the controls in Gutenberg.

  • Michelle B. says:
    August 26, 2022 at 12:57 am

    I’m looking forward to the new release! There’s a lot of work put into this release, and even this article. Thank you for all you do for the WordPress community! Very exciting!

  • ginsterbusch says:
    August 26, 2022 at 1:39 am

    Well, as long as ClassicPress is still supported, and its just an "UI thing", all is well. I’m not particularly in fond of the garbage that is called Gutenborg. ACF Pro is one of the reasons to avoid all that clutter whatsoever. cu, w0lf.

  • gapowell says:
    August 26, 2022 at 3:12 pm

    One big suggestion for the sticky header when editing field groups (it’s too damn big!), .acf-admin-toolbar { position: sticky; top: 32px; position: relative; } .acf-headerbar-field-editor { top: 104px; top: 32px; }

  • Ben says:
    August 28, 2022 at 6:37 pm

    I’m having an issue with updating. I’m sure I’m doing something simple wrong… I download the update (advanced-custom-fields-pro.6.0.0-RC1.zip), unzip it then it’s named the same as in my current plugins dir (advanced-custom-fields-pro), export the data I’ve created in the former version in the "Tools" section of existing ACF plugin, delete the plugin, upload the new version and activate… But then when I go to it it still reads as the former version I was trying to update from (5.12.3). How do I get wordpress to recognize the update? Note: I am running a custom Underscore theme under WP Version 6.0.1. Any help appreciated.

  • Timothy Jacobs says:
    August 28, 2022 at 10:59 pm

    Looks great! A welcome improvement.

  • Paweł Strutyński says:
    September 3, 2022 at 6:27 am

    I would use the Phone field (which will be automatically added before the phone number :), similar to the Email field. It will be convenient for people who use, for example, an element to build a page.

  • intern ship says:
    September 8, 2022 at 9:20 am

    Battery Pack Market Size Worth USD 132.68 Billion in 2028 The global battery pack market size is expected to reach USD 132.68 billion by 2028 at a CAGR of 17.9%, according to a new report by Emergen Research. Growth in market revenue is primarily attributed to increasing applications of battery packs in consumer electronic devices such as mobile phones and laptops, power tools, and electric vehicles Get a sample of the report (To Understand the Complete Structure of this Report [Summary + TOC])@ https://www.emergenresearch.com/request-sample/739

  • Andy Toniievych says:
    September 13, 2022 at 1:33 pm

    I don’t like the new UI. It is much less convenient than the existing ones. The space reduction is minimal, but now we need to make additional clicks to see the required settings.

  • Indrek says:
    September 29, 2022 at 4:07 am

    Update 6.0.1… damn, I was really hoping to see "Update 6 removed". Fingers crossed for 6.0.2!

Sign up for the latest Advanced Custom Fields news, updates, and developer tutorials