4 Aug

ACF PRO 6.0 Beta 1

By Iain Poulson

We’re excited to announce the first beta release of ACF PRO 6.0. ACF PRO v6.0.0-beta1 is now available with improved performance for Repeater fields with large datasets, and a new generation of ACF Blocks. 🎉🥳

ACF 6.0 has been released! Read the release post.

Thank Yous

We’d like to thank all of our GitHub developer preview users for their help in getting ACF 6.0’s block changes ready for release. Across the 4 developer previews (tagged as ACF 6.0.0-alpha#) we’ve fixed numerous bugs and implemented several additional new features based on your feedback, and we can’t wait to see what you develop with ACF Blocks in ACF 6.0!

Translation Improvements

ACF 6.0 introduces a new way of collecting translations from our wonderful contributors. For all the strings contained in the free version of ACF, these are now collected from translate.wordpress.org

This means ACF 6.0 introduces 10 new languages (or language variants) and updates almost all of the existing ones.

Many of you have submitted translations for numerous languages on WordPress.org since that translation functionality was introduced, but until this release they were never included or loaded into ACF. We’ve imported all the contributions we’ve received directly from our users into translate.wordpress.org for languages which weren’t already complete. These should be reviewed by the WordPress language editors over this beta cycle.

The existing languages we bundled in ACF have been trimmed where they are already complete and approved on translate.wordpress.org to only include the pro strings, but where a language is not complete, we’ve kept all the free strings included too, to avoid losing data while we wait for approval.

If you’d like to help us translate ACF to your language, or help verify translations for your language, you can do so on translate.wordpress.org. WordPress’s Translation Handbook has everything you need to get started. Once complete, you can request WordPress’s translation editors review your submissions as detailed here, or you can request to become a Project Translation Editor, where you can take control over ACF’s translations for your language.

For strings specific to the PRO version of ACF, we’ve updated our .pot file generation to only include PRO strings, and you’ll find these files inside a new folder on our GitHub repository, /lang/pro. Whilst today’s Beta 1 release is only for ACF PRO, we’ve manually updated the ACF Free repo with the new translations so you can start translating during this cycle.

To avoid ACF Free and ACF PRO having divergent translations, updates from translate.wordpress.org will not take effect in either version until each ACF release going forward.

Please let us know if you experience any issues with the new translations, and we can’t wait to see what languages you add support for next. English (Pirate) anyone?

Get the Beta

To access this release, please login to your account, navigate to the “Licenses” page and select version “6.0-beta1” from the available downloads.

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

What’s Next

We are planning another beta release this month with the first look of a plugin UI refresh, which brings an improved user experience to field groups and adding and editing fields.

The final 6.0 release will also contain a number of accessibility fixes, so look out for a release candidate coming soon.

Full Changelog (WIP)

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 now use Block IDs saved in the block comment. Enhancement – Bulk actions for field groups now include “Activate” and “Deactivate” options. 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 – 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. 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.

  • Rose Seto says:
    August 7, 2022 at 9:59 pm

    Hi there, Regarding ‘Block ID Removal’, it says: "We’ll still generate a $block[‘id’] for your templates as we know some users use that for element IDs, but the format of those IDs will change, and may be duplicated if you have multiple blocks on the same page with the exact same data…" I use Block ID ($block[‘id’]) for JavaScript and CSS, so if Block ID is removed or if it causes duplicated IDs then this could be an issue for me. I don’t want to have to manually add an ID name in the ‘Html anchor’ field in all of my blocks, so that’s why I rely on $block[‘id’]. If $block[‘id’] is completely removed from ACF Pro, is there a way to automatically generate a unique ID for each of my custom ACF blocks on the page, similar to your $block[‘id’]? Thank you!

    • Liam says:
      August 10, 2022 at 10:13 am

      We generate block ID based on the data and attributes for the block, so you’ll only experience duplicates if you have two exact copies of the same block, with the same field values and every attribute the same on a page – or you’re using something like a Query Loop block, containing ACF blocks which will already present a duplicate block ID in current ACF builds. If you really want to maintain a block ID, you can use the acf/pre_save_block filter to manually add in a new data attribute containing a block ID of your choice to the data array.

    • Liam says:
      August 10, 2022 at 10:21 am

      Also I should say, you could use acf/pre_save_block to automatically set a HTML anchor if it’s not set too!

      • Rose Seto says:
        August 10, 2022 at 2:05 pm

        Thank you Liam! Is there any documentation on the ‘acf/pre_save_block’ hook?

      • Rose says:
        August 10, 2022 at 10:14 pm

        For the acf/pre_save_block filter, I couldn’t find documentations on the ACF pro website, are there any examples on how to use it? Also, how is your block id ($block[‘id’]) generated with php? I’ve gone through a lot of the acf pro plugin files (such as block.php) and couldn’t find how the block id was generated. Thanks!

        • Liam says:
          August 19, 2022 at 2:31 pm

          Hey Rose! I know we’ve spoken in the support email, but just for the sake of anyone else reading this – we will be adding documentation for this as we get closer to release. $block['id'] is generated by building an MD5 hash of all a blocks sorted attributes, along with it’s context.

  • Phillip McCallum says:
    August 8, 2022 at 2:00 am

    Hi, We’re in the same position as Rose, we use the Block ID pretty heavily, so this seems to be a pretty large breaking change. We show the Block ID in the CMS in the sidebar and when users need to do a Scroll to block link, they copy that block ID. We’d need to get clients to go and update all of their links. :/ I’m sure its also used for SEO tracking / external linking to specific blocks. I understand the need to fix duplicate ID’s, I think we’ve been stung by this a few times, but are there other ways of fixing this? Cheers, Phill

    • Liam says:
      August 10, 2022 at 10:18 am

      Hey Phil, Unfortunately there aren’t any other ways to fix this, as having a persistent unique ID to any block fundamentally breaks aspects of the block editor, especially newer features like block patterns. If you really want to maintain a block ID, you can use the acf/pre_save_block filter to manually add in a new data attribute containing a block ID of your choice to the data array. My recommendation for scroll to block links is to use the WordPress functionality for anchors which is available on every block, and because we now use native WordPress functionality for block registration, you can use the block editor JS APIs to pre-fill those values if you wanted.

  • Lars Faye says:
    August 13, 2022 at 9:46 am

    The deprecation of the PHP acf_register_block_type function and eventual replacement with the blocks.json is extremely concerning, if backwards compatibility is not retained. If I understand this correctly, eventually any sites that registered blocks using this function will suddenly have its custom blocks stop working (either registration or asset enqueuing), unless they are registered using the blocks.json workflow? Won’t that break a massive amount of installs?

    • Liam says:
      August 19, 2022 at 2:26 pm

      Hey Lars, We won’t ever make any changes in ACF to remove acf_register_block_type – but are concerned WordPress may make changes at some point in the future that will break it’s support. But, if you’re willing to stick at the version of WordPress before that, we’ll support it as long as we support that version of WordPress!

  • Casey Milne says:
    August 16, 2022 at 9:57 pm

    Is there any way to use appender customization with the Inner Blocks? I’m not sure if this is possible now, I haven’t found anything I can pass to renderAppender="" that works in the current version… just wondering if ACF could enable that feature? Normally renderAppender (in React) is a component that is passed in… not sure how to control that in PHP, because it’s not just data like with the Inner Blocks template and templateLock.

    • Liam says:
      August 19, 2022 at 2:30 pm

      renderAppender isn’t currently supported in ACF Blocks, but we’ll log your feature request! Could you give us an example use case for what you’d be trying to achieve that isn’t possible with the currently templating system?

  • Jimena Martin Leon says:
    August 18, 2022 at 12:31 pm

    Hi, I’m creating a new WordPress block using npx @wordpress/create-block, and then I’m adding the ACF configuration key to the JSON file. But when I’m in the editor of the page the toolbar of the block doesn’t show the option to edit the custom fields. I’m not sure if I have to add something else in the edit field (…useBlockProps()) or why this could be happening. Do you have more documentation or an example to create WordPress blocks with the new ACF upload ? And there is a way to create new blocks with ACF using JS ? Thank you !

    • Liam says:
      August 19, 2022 at 2:28 pm

      Hey Jimena, @wordpress/create-block isn’t really suitable for creating ACF Blocks, as it’s loading it’s own JavaScript files to process the block, which isn’t compatible with ACF Blocks. Our example above is the best way to get started with ACF Blocks – or you can use some of the dedicated third party ACF Blocks creation tools – but i’m not sure if any are ready for ACF 6.0 yet!

  • Harish says:
    August 24, 2022 at 2:57 pm

    LOVE it Guys, I like the New UI. Excited to see Blocks

  • modemlooper says:
    August 24, 2022 at 3:55 pm

    The UI should be like core WP. I don’t see why plugins need to recreate it. It just causes confusion. I updated and it broke every block created with ACF. The blocks displayed but they were not selectable. The fields do not show in the sidebar. I had to delete every block in the content and re-add. This could be a terrible situation if you have to edit every single piece of content ever create with ACF blocks.

  • Jack Walker says:
    August 25, 2022 at 9:10 am

    Personally, I chose these cbd gummies for myself because I’ve heard a lot about this brand of cornbread hemp from Kentucky. I really like this delightful relaxation https://neurogan.com/blogs/news/cbg-dosage effect when I take one gummi before going to bed and nothing bothers me as before. In general, now this topic is very popular and I, for example, have read a lot of good things about the sedative effects of cannabidiol.

  • Peter Morvay says:
    August 31, 2022 at 8:21 pm

    Hi, all those changes to Blocks are great, but it looks more like ACF 5.13 to me. I saw RC1 new UI and let’s say it’s worth naming it 6.0 .. but honestly, I was expecting bidirectional fields, repeaters and groups saved as json/serialized array in database and removing field keys from DB – basically reducing ACF meta rows by 50-90%

  • Jansen Tolle says:
    September 7, 2022 at 9:56 am

    Absolutely huge and exciting update. Can’t wait to try the v2 blocks

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