• WooCommerce has Classic Checkout (PHP) and Checkout block (React), each with different customization methods.
• Add/remove fields via settings, plugins, or custom PHP code, with plugins offering no-code solutions.
• Advanced Custom Fields (ACF®) lets you visually define and manage custom fields for checkout with minimal code.
• ACF works for backend data in Block checkout but requires integration with Block APIs for frontend display.

With 4.5 million stores using WooCommerce, a lot of revenue flows through its checkout forms.

Friction at that final step is where you lose people.

Research backs this up: according to the Baymard Institute, around 18% of people abandon checkout because it feels complicated, and most stores request more fields than they actually need.

WooCommerce ships with sensible defaults like billing, shipping, and order notes, yet stores often ask for more information than customers care to provide. Removing fields that serve no purpose and rewriting unclear text helps shoppers move forward with less friction.

Our goal here is to make it easier for your customers to finish paying without guessing what you want from them.

Understanding WooCommerce checkout: Classic vs Block

WooCommerce offers two checkout systems that behave differently.

The older setup, often called Classic checkout, runs through PHP templates and shows itself whenever a page contains the [woocommerce_checkout] shortcode. This version accepts traditional code snippets and many long-standing tutorials still reference it.

WooCommerce might even give you the option to switch to the Checkout block in one click:

The newer system, known as the Checkout block, is built on React and appears in the editor as a block labeled Checkout.

It handles layout and interactions in the browser, which means most PHP hooks that worked in Classic simply do nothing here.

Confusing the two systems leads to issues that look like missing fields or plugins that appear installed yet never apply their changes.

A quick way to avoid that trouble is to confirm which checkout architecture is active before attempting edits or installing tools.

One interesting thing to note is that you can switch between these two options regardless of whether you’re using a block or classic theme.

What you can change in WooCommerce checkout

WooCommerce gives you a lot of control over checkout fields, though how much depends on your approach.

You can:

• Add new fields to collect information WooCommerce doesn’t ask for by default, like delivery dates, VAT numbers, gift messages, or special instructions.
• Remove fields you don’t need, such as the second address line or company name.
• Rearrange fields to match how your customers naturally fill out forms.
• Rename labels and placeholder text to be clearer or match your brand voice.
• Change validation rules to make fields required, optional, or conditional based on other inputs.

Three paths get you there:

1. WooCommerce’s built-in settings – limited but don’t require much technical skill.
2. Custom code using WooCommerce hooks and filters – flexible but requires PHP knowledge.
3. Plugins like Advanced Custom Fields (ACF®) – the practical middle ground for most store owners.

What you can change with built-in settings

WooCommerce includes toggles that influence the checkout page, but it doesn’t let you edit the fields directly.

There’s no built-in screen where you add, remove, or rearrange inputs, so the controls you do get work indirectly:

• Store location settings decide which address fields make sense for your region. If your store only sells domestically, you might see fewer inputs than shops selling internationally. Changing selling locations or the default customer location adjusts which fields WooCommerce thinks are relevant.
• Shipping settings determine whether a shipping address section appears at all. Stores selling only downloads, or shops offering local pickup without delivery, may not show any shipping address form because WooCommerce knows it isn’t needed.
• Account settings influence whether customers create an account during checkout. Enabling guest checkout removes username and password prompts, which shortens the form.

These toggles help simplify checkout, but they don’t let you customize individual fields. To remove something, add new inputs, or control which fields are optional, you’ll need either a plugin or custom development.

Main approaches to customizing your WooCommerce checkout

There are several paths you can take to change how WooCommerce checkout works, and each one fits a different level of complexity:

• Stores running the newer Checkout block rely on a React-based system that offers a neat mobile layout, though bigger changes often require development knowledge.
• Plugins offer a no-code route with a visual editor, so you can add or adjust inputs without touching templates.
• Code gives the greatest control, but only applies to Classic checkout, because most PHP hooks do nothing in the Block system. If you tried PHP snippets on a Block-based store, nothing would appear.

Match your needs with the right approach:

How to add WooCommerce custom checkout fields

The WooCommerce checkout experiences for Block and Classic are built on different technologies, so the method for adding custom fields isn’t interchangeable. PHP hooks won’t work on Block checkout, and JavaScript-based solutions won’t work on Classic.

One thing does apply to both, though: if your store uses High-Performance Order Storage (HPOS), you’ll need to save custom field values with $order->update_meta_data() instead of the older post meta functions.

If you’re using classic checkout

Classic checkout runs on PHP, which means you can customize it using WooCommerce’s built-in hooks like woocommerce_checkout_fields or by overriding template files directly.

Most checkout field tutorials and plugins you’ll find online were written for Classic checkout, so compatibility is rarely an issue. If you need deep customization flexibility – conditional fields, complex validation, tight control over markup – Classic checkout with PHP is still the most capable option.

Method 1: Add custom checkout fields using code

Writing your own code gives you full control over checkout fields, but it requires PHP knowledge and careful attention to WooCommerce’s data handling conventions.

The core hook for field customization is woocommerce_checkout_fields, which passes you an array of all checkout fields organized by section: billing, shipping, account, and order. You can modify this array to add new fields, remove existing ones, or change their properties:

1. Add a custom field by appending a new array to the appropriate section. Each field needs a type, label, and usually a placeholder and required value. You can add fields to billing, shipping, or the order section, depending on where the data belongs.
2. Remove a field using unset() on the field key. For example, unsetting billing_company removes the company name field.
3. Modify a field by changing its array values directly. You can update labels, placeholders, CSS classes, or toggle the required property.
4. Validate input by hooking into woocommerce_checkout_process and checking submitted values. Use wc_add_notice() to display errors.
5. Save the data using $order->update_meta_data() inside the woocommerce_checkout_create_order hook. This approach is required for HPOS compatibility.

You can also make fields conditional based on cart contents and style them using CSS classes passed in the field array.

Method 2: Add custom checkout fields using plugins

If PHP isn’t your thing, a checkout field plugin handles the technical work and gives you a visual interface for managing fields.

Two popular options are Checkout Field Editor for WooCommerce and Flexible Checkout Fields. Both let you add, edit, reorder, and remove fields using a drag-and-drop UI. They support a wide range of field types, including:

• Text
• Email
• Textarea
• Select dropdowns
• Radio buttons
• Checkboxes
• Date pickers
• Color pickers

Most field editor plugins also include conditional logic. You can show or hide fields based on products in the cart, product categories, cart total, shipping method, or user role. This streamlines checkout by only asking relevant questions.

Custom field data typically flows through to order confirmation emails, the admin order screen, and CSV exports, though you’ll want to verify this works as expected for your setup.

1. With the plugin installed and activated, go to WooCommerce > Checkout Form.
2. In the Checkout Fields tab, switch to the Classic Checkout option.

3. Click Add Field and add your custom field’s details, with unique names and useful labels, then click Save & Close.

4. Drag the field where you want it to appear, then save your changes.
5. Load up the checkout page and confirm it works.

If the field doesn’t show, your site is probably using the Checkout block. To switch to classic:

1. Go to Pages > All Pages and find the checkout page. 
2. Open it, delete the Checkout block, search for and add the Classic Checkout block. 
3. If this isn’t available, add a shortcode block with \[woocommerce_checkout].
4. Save.

A few things can go wrong when using this method.

Theme conflicts sometimes break field display, especially with heavily styled themes. Plugin conflicts can occur if you’re running multiple checkout customization tools. And not all plugins support HPOS yet, so check compatibility before installing. When troubleshooting, disable other plugins temporarily to isolate the issue.

Method 3: Add advanced checkout fields using ACF

ACF sits between hand-coded PHP and scope-limited checkout plugins.

You get a proper UI for defining fields, but with enough flexibility to handle complex requirements, and you won’t outgrow it as your needs evolve.

Say you sell custom engraved products and need to collect engraving text, font choice, and a preview approval checkbox, but only for products in a specific category. ACF lets you define this field group once in the admin, then display it conditionally at checkout with a small snippet of code.

ACF isn’t checkout-specific, which makes it more versatile than single-purpose plugins.

The same field management interface works for product pages, user profiles, settings screens, and more. If you’re already using ACF elsewhere in your store (like for adding custom fields to WooCommerce products), extending it to checkout keeps your workflow consistent.

The setup has two parts: defining the field in ACF’s visual interface, then adding a small code snippet to display and save it.

To create a radio where the customer can choose when they want the order delivered to them from three options.

First, create the field group:

1. Go to ACF > Field Groups and click Add New. Name it something descriptive like “Delivery window.”
2. Click Add Field. For this example, set the field type to Radio Button, the label to “Preferred delivery time,” to get a matching field name, then add the options.

3. Add any other fields you need to this group. ACF’s interface lets you set field widths, instructions, and default values, all without code.
4. To ensure the field doesn’t show up all over your backend, set the location rules to Page is equal to Checkout.

5. Publish the field group.

Next, add the code to display and save the field. This goes in your theme’s functions.php file, code snippet, or a custom plugin. If you’re not comfortable with any of these options, ask your developer to handle this step.

It’s a quick enough job and you’ll usually only need to do it once.

The first part involves adding a radio field to the classic WooCommerce checkout form, under the order notes. Customers see a group labeled “Preferred delivery time” with three choices – Morning, Afternoon, and Evening:

add_action( 'woocommerce_after_order_notes', 'my_delivery_time_field' );
function my_delivery_time_field( $checkout ) {

    woocommerce_form_field( 'preferred_delivery_time', array(
        'type'     => 'radio',
        'label'    => __( 'Preferred delivery time', 'textdomain' ),
        'required' => true,
        'options'  => array(
            'morning'   => __( 'Morning', 'textdomain' ),
            'afternoon' => __( 'Afternoon', 'textdomain' ),
            'evening'   => __( 'Evening', 'textdomain' ),
        ),
        'class' => array( 'form-row-wide' ),
    ), $checkout->get_value( 'preferred_delivery_time' ) );
}

Then, take the customer’s selection from the checkout form and store it as order meta, using the key _preferred_delivery_time. That way, the information is permanently attached to the order in the database:

add_action( 'woocommerce_checkout_create_order', 'my_save_delivery_time_field', 10, 2 );
function my_save_delivery_time_field( $order, $data ) {

    if ( ! empty( $_POST['preferred_delivery_time'] ) ) {
        $order->update_meta_data(
            '_preferred_delivery_time',
            sanitize_text_field( $_POST['preferred_delivery_time'] )
        );
    }
}

Finally, display the saved preferred delivery time in the WooCommerce order edit screen, underneath the billing address. Converts the stored value (morning, afternoon, evening) into a human-friendly label before outputting it:

add_action( 'woocommerce_admin_order_data_after_billing_address', 'my_show_delivery_time_admin' );
function my_show_delivery_time_admin( $order ) {

    $time = $order->get_meta( '_preferred_delivery_time' );

    if ( $time ) {
        $labels = array(
            'morning'   => __( 'Morning', 'textdomain' ),
            'afternoon' => __( 'Afternoon', 'textdomain' ),
            'evening'   => __( 'Evening', 'textdomain' ),
        );

        echo '<p><strong>' . __( 'Preferred delivery time', 'textdomain' ) . ':</strong> ' 
            . esc_html( $labels[ $time ] ?? $time ) . '</p>';
    }
}

Once that’s in place, test the full flow: add a product to cart, go through checkout, choose your preferred delivery time, and confirm it appears in the order details.

The real value of ACF shows up when you need to change things later.

Adding a new field or adjusting options happens in the ACF interface, with no code changes required. You only touch PHP when you need to display the field somewhere new or change where it appears on the page.

If you’re using the Checkout block

As we’ve established, the Checkout block is WooCommerce’s newer checkout experience, built on React and the WordPress block editor. You can customize it visually – toggling fields on or off, reordering sections, adding Express Checkout options – without touching code.

That visual simplicity comes with a tradeoff.

Because the Checkout block runs on JavaScript rather than PHP, the classic customization methods don’t work here. You can’t use woocommerce_checkout_fields or template overrides. Advanced customization means working with WooCommerce’s Block extensibility APIs, which require JavaScript and React knowledge.

For developers, those APIs are capable. You get Slots and Fills for inserting custom components, built-in validation hooks, and conditional visibility rules. But the ecosystem is still maturing. Not all checkout plugins and extensions support the Block checkout yet, so check compatibility before committing to this path.

The upside is that the Checkout block delivers better mobile UX out of the box, modern styling that matches the block editor aesthetic, and improved performance. If your store prioritizes an organized, fast checkout and you don’t need heavy customization, it’s a better foundation going forward.

Method 1: Use Block-compatible checkout field plugins

The easiest way to add custom fields to Block checkout is with a plugin built specifically for it. These plugins give you a no-code interface for creating fields that work within the Block architecture.

When evaluating plugins, check for two things:

• explicit Checkout block support
• and HPOS compatibility.

Many older checkout field plugins were built for Classic checkout only and won’t function correctly – or at all – with the block version. Plugin listings and documentation usually state block compatibility clearly; if they don’t mention it, assume it’s not supported.

As you might have guessed, Checkout Field Editor for WooCommerce also works here. The process is the same as before, except now you’re working within the Block Checkout section.

Just like before, the plugin handles rendering inside the Block checkout and should save data in an HPOS-safe way.

Method 2: Use WooCommerce Blocks extensibility APIs

When plugins can’t deliver what you need, WooCommerce’s Block extensibility APIs give you full control – but you’ll need JavaScript and React experience to use them.

The core concept is Slots and Fills. WooCommerce defines specific Slots throughout the Checkout block where you can inject custom React components. Your code registers a Fill that targets a slot, and WooCommerce renders your component in that location.

The general workflow:

1. Create a React component for your custom field. This handles the UI, user input, and any client-side validation.
2. Register your component as a Fill targeting the appropriate checkout slot, like woocommerce_blocks_checkout_order_notes_block for the order section.
3. Access form values and checkout state through WooCommerce’s React context providers. These give you cart data, shipping info, and other checkout state your field might depend on.
4. Implement validation by hooking into the checkout validation system. You can prevent submission and display errors if your field’s requirements aren’t met.
5. Save submitted data by sending it to a PHP endpoint that uses $order->update_meta_data() for HPOS compatibility. The JavaScript side passes data, while the PHP side persists it.

This approach is required for anything interactive or dynamic, like fields that update based on selections, real-time validation feedback, or custom UI elements that go beyond standard form inputs.

Where does ACF fit into block-based WooCommerce checkout?

ACF can’t render fields inside the Checkout block on its own. The Block checkout doesn’t process PHP template hooks or shortcodes – it’s a self-contained React application. So ACF’s usual method of displaying fields on the frontend doesn’t apply here.

That doesn’t make ACF useless for Block checkout stores. It’s extremely valuable for backend work: storing configuration options, building admin settings panels, or managing structured data that influences what appears at checkout. You might use ACF to let store admins define which custom fields should exist, what options a dropdown should contain, or which products trigger additional questions.

The pattern is to pair ACF with the Block extensibility APIs. ACF manages the data and admin interface. A custom JavaScript component reads that data (via REST API or localized script data) and renders the appropriate fields in the Checkout block. PHP handles saving the submitted values.

This split approach takes more setup than the all-in-one Classic checkout method, but it keeps your admin experience consistent while working within the Block checkout’s architecture.

WooCommerce custom checkout fields troubleshooting

If you’ve added custom fields using code or a plugin and something isn’t working, these are the most common issues and how to fix them:

• Custom fields not appearing on checkout usually means you’re using Classic checkout PHP hooks on a store running Block checkout. Switch to a Block-compatible plugin or rebuild your customization using the WooCommerce Blocks extensibility APIs.
• Field data that disappears after order submission typically results from saving methods that aren’t compatible with High-Performance Order Storage. Update your code to use $order->update_meta_data() instead of update_post_meta(), or verify your plugin explicitly lists HPOS support.
• Unexpected errors or broken checkout layouts in Block checkout often point to plugin or theme conflicts because the strict JavaScript architecture surfaces incompatibilities that Classic checkout might tolerate. Disable other plugins one by one to isolate the problem, and test with a default theme like Storefront to rule out theme issues.

Troubleshooting Block checkout problems that you can’t pin down gets easier if you temporarily switch back to Classic checkout to see whether the issue is Block-specific. If your fields work on Classic but fail on Block, the problem is compatibility rather than your field configuration.

Deliver conversion-driven checkout flows with ACF

Getting checkout customization right starts with one question: Are you running Classic checkout or Block checkout? That choice determines everything else.

Classic checkout uses PHP hooks and template overrides. Block checkout requires React components and JavaScript APIs.

The methods aren’t interchangeable, and mixing them up is the most common source of problems.

Whichever path you’re on, save custom field data using $order->update_meta_data() to stay compatible with HPOS. This used to be optional, but now it’s the only way WooCommerce handles order data.

Once you’ve matched your approach to your checkout type, the next challenge is keeping things manageable. Conditional fields, product-specific questions, admin-configurable options – complexity adds up fast.

ACF gives you a structured way to handle that complexity.

You define field groups and metadata in a visual interface, then connect them to your checkout through code or Block APIs. As your store grows and checkout requirements change, you’re editing field settings rather than rewriting PHP or JavaScript.

Download ACF and start building checkout forms that scale with your business.

The post How to Add WooCommerce Custom Checkout Fields: Classic vs Block Methods appeared first on ACF.

• ACF custom fields work with the WordPress Block Editor, storing data in wp_postmeta and ensuring compatibility with Gutenberg.
• To display ACF fields, enable the native custom fields panel or use block plugins like Blocks for ACF Fields or native block bindings.
• For complex layouts, ACF PRO’s Blocks feature enables full control over custom block development using just PHP.
• ACF Blocks provide a scalable solution for projects requiring custom HTML output, dynamic field integration, or complex structures beyond standard block features.

The block editor fully supports custom fields, including those from Advanced Custom Fields (ACF®). ACF and native custom fields share the same metadata system – both store data in wp_postmeta – making them inherently compatible with Gutenberg.

Most field visibility issues trace back to disabled panels or incorrect location rules, not actual incompatibility.

Once you understand why fields aren’t appearing, fixes are straightforward.

We’re going to cover how to set up fields, display them in blocks, pick the right method for your use case, and avoid common pitfalls. We’ll also show you how to view custom field data in the Block editor through block plugins and block bindings.

For complex layouts involving repeaters or custom markup, ACF PRO’s Blocks provide a PHP-based path that doesn’t require React.

If you’re looking to display custom field values on the frontend instead, you can use a page builder like Divi, Bricks, Beaver Builder, and Elementor, all of which offer native ACF integration.

How custom fields in the block editor work

Custom fields are key/value pairs stored in the wp_postmeta table.

Each field creates a row with a meta key (the field name) and a meta value (the data). WordPress has supported this metadata system since long before Gutenberg existed.

ACF uses the same storage mechanism.

The difference is what ACF layers on top: a visual interface for creating fields, validation rules, conditional logic, and structured field definitions that enforce data consistency. Under the hood, an ACF text field and a native custom field store data identically.

This shared foundation means the block editor doesn’t treat ACF fields as foreign objects. They load, save, and query like any other post meta. The complications people encounter usually involve visibility settings and display methods rather than any fundamental compatibility issues.

The native custom fields panel is disabled in Gutenberg by default, and ACF hides it further to reduce confusion.

Here’s how to enable it when you need direct meta access.

How to enable custom fields in WordPress Block Editor

The block editor hides the native custom fields panel by default, but you can enable it in a few easy steps:

1. Click the three-dot options menu in the top-right corner of the editor.
2. Select Preferences.
3. Navigate to the Advanced section.
4. Toggle Custom Fields to on.

5. Click Show & Reload Page.

The editor refreshes and displays WordPress’s built-in custom fields panel below your content. This panel shows raw meta keys and values attached to the current post. You can add new fields, edit existing values, or delete entries directly.

If you don’t see the Custom Fields toggle in Preferences, ACF is likely hiding it. The next section explains why and how to restore access.

Why can’t I see custom fields in Gutenberg?

ACF intentionally hides WordPress’s native custom fields panel. This prevents confusion between the raw meta interface and ACF’s structured field groups – two different ways of viewing the same underlying data.

To restore the native panel while keeping ACF active, add this filter to a custom plugin or custom code snippet:

add_filter( 'acf/settings/remove_wp_meta_box', '__return_false' );

This is useful when debugging field values or accessing meta keys that aren’t part of any field group. Most users won’t need it for daily editing, but developers troubleshooting field issues will find it essential.

Do custom fields work with the block editor?

Yes. Native custom fields and ACF fields both load and save normally in Gutenberg. The block editor reads from and writes to wp_postmeta using standard WordPress functions, so any metadata system built on that table works without modification.

ACF adds validation, sanitization, and conditional logic on top of this flow.

When you save a post, ACF processes field values according to your field group settings before storing them as regular post meta. When you load a post, ACF retrieves that meta and formats it for display in its field UI. The storage layer remains unchanged.

Setting up ACF fields

While WordPress includes a basic custom fields interface, it only handles simple key/value pairs without validation, field types, or organizational structure. ACF gives you a proper custom field management system with repeatable workflows.

ACF organizes custom fields into field groups, containers that hold related fields and control where they appear. Each field group has its own location rules, field definitions, and display settings.

To create a field group with ACF:

1. Go to ACF > Field Groups > Add New.
2. Give the group a descriptive name that reflects its purpose, like “Product Details” or “Author Bio.”
3. Add individual fields using the Add Field button.

4. Save the group.

Each field needs a label (what editors see) and a name (what developers reference in code). ACF auto-generates the name from your label, but you can customize it. Use lowercase letters with underscores for consistent, predictable template access.

Location rules determine where your field group appears. Set conditions like Post Type is equal to Product or Page Template is equal to Landing Page to target specific content. You can combine multiple rules for precise control – showing fields only on certain post types, user roles, taxonomies, or page templates.

Creating field groups that work for you

Once you’ve created your first field group, a few structural decisions will save you headaches down the road.

Field names should use lowercase letters with underscores for separation (like event_date or product_price).

То eliminate inconsistencies when referencing fields in templates or debugging database entries, avoid:

• Spaces
• Hyphens
• or camelCase

ACF auto-generates names from labels, but we’d recommend reviewing them before saving, just so you’re familiar.

Location rules need precision.

Post Type is equal to Post works for blog content, but adding a second condition like Post Template equals Default prevents fields from appearing on archive pages or custom templates where they don’t belong. Layer conditions intentionally rather than relying on broad rules that might match unintended contexts.

Incorrect location rules are the most common reason fields don’t appear where expected. Double-check these settings first when troubleshooting missing fields.

Prefix field names on larger projects.

Using product_price instead of just price avoids collisions when multiple field groups contain similarly named fields. This will prove critical when querying meta values across different post types or building reusable template partials.

Field type best practices

With the basics of ACF in place, we can now go over some more advanced field configuration choices that will really start to shape your content model as it expands:

• Match field types to expected data because ACF enforces format rules automatically and eliminates validation headaches. Choose URL fields for links, Date Pickers for dates, Image fields for media, and Email fields for contact addresses.
• Write descriptive field labels since they serve as inline documentation and reduce editor confusion. Replace vague labels like “Image” with specific instructions like “Featured Product Image (800×600px minimum)” that set clear expectations.
• Use structured fields where freeform text creates consistency problems over time. Select fields with predefined options prevent typos, Group fields keep related data together, and Repeaters handle variable-length lists like team members or testimonials.
• Reserve complex field types for genuinely variable data because unnecessary complexity increases editing overhead. Default to simple fields and reach for things like Repeaters or Flexible Content layouts only when your content model actually requires them.

How to display custom field data in the Block Editor

ACF fields appear in their own metaboxes below or beside the main content area. But what if you want to see field values directly within the block editor canvas, alongside your other content blocks?

Two methods let you surface custom field data inside the editing interface: dedicated block plugins and native block bindings. Both display field values as part of your block layout while you work

Method 1: Using dedicated block plugins

Blocks for ACF Fields is a third-party plugin – it’s developed independently and is not affiliated with ACF or WP Engine – that adds blocks for displaying ACF field values directly in the editor canvas. The plugin provides a dropdown interface for selecting which field to surface.

To display a field using Blocks for ACF Fields:

1. Install and activate the plugin.
2. Open a post or page that has ACF fields attached. Fill in the fields with values if they’re still blank.
3. Add a new block and search for “ACF Field.”

4. Insert the block where you want the field value to appear in your layout.
5. Select your target field from the dropdown in the block settings panel.

The field value appears inline with your other blocks, updating as you edit. Detailed configuration options are documented on the plugin’s directory listing.

Method 2: Using native block bindings

Block bindings connect post meta directly to core block attributes. Instead of adding a dedicated field block, you bind an existing block, like a paragraph or image, to a custom field value. The bound block renders the field’s stored data on the frontend.

WordPress introduced block bindings to support dynamic, data-driven content editing. The feature lets you build layouts where blocks pull their content from metadata rather than manual entry.

To bind an ACF field to a core block:

1. Add a supported block (paragraph, heading, image, or button) to your content.
2. Open the Code Editor view for the block.
3. Add a metadata attribute specifying the bindings source and target field name. Here’s an example for a paragraph bound to a field called achievements:

<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"acf/field","args":{"key":"achievements"}}}}} -->
<p></p>
<!-- /wp:paragraph -->

4. Switch back to the Visual Editor. You’ll see a generic “ACF Fields” label rather than your actual field value. To verify the binding works, preview or view the published post.

Block bindings suit single-value text fields in straightforward layouts. A few practical limitations you should note:

• The editor shows a placeholder instead of the field value, so you lose the visual context that makes the block editor useful.
• Bindings require hand-editing JSON rather than clicking through a settings panel.
• Repeaters, Groups, WYSIWYG, and relational fields don’t work.
• When bindings fail, there’s no error message indicating why.

For editor-visible field values, ACF Blocks may be more practical.

Meet ACF Blocks: The scalable path for complex custom fields

Block bindings and Blocks for ACF Fields handle most field types without code, including Repeaters and nested structures for the latter. But you’re working within their boundaries. When you need specific HTML output or conditional logic based on field values, these methods reach hard limits.

ACF Blocks solve this gap. Available as part of ACF PRO, this feature lets you build custom blocks using PHP instead of React. You get full control over output markup while avoiding the JavaScript complexity that makes native block development inaccessible to many WordPress developers.

Unlike block bindings, ACF Blocks let you render your field values live in the editor.

If your project needs markup that doesn’t fit standard block patterns, or you’d rather not add another plugin dependency, ACF Blocks keep everything within the familiar ACF ecosystem.

When do I need ACF Blocks?

ACF Blocks make sense where your requirements exceed what dropdown selectors and attribute bindings can deliver, like when:

• Repeater or Flexible Content fields need loops to output variable numbers of items.
• Custom markup requirements demand precise HTML structure that core blocks can’t produce.
• Query Loop integration requires fields to work dynamically across multiple posts.
• Design specifications call for wrapper elements, conditional classes, or nested HTML that no-code tools can’t generate.

How ACF Blocks work

We’ve created an in-depth, beginner-friendly guide to building an ACF Block, covering everything from initial registration to advanced rendering techniques.

In a nutshell, though, the development process combines familiar WordPress patterns with ACF’s field system:

1. Define block metadata in a block.json file to register the block with the editor.
2. Create a Field Group with the location rule set to “Block” and target your specific block—this scopes fields to appear only when editing that block.
3. Render output using a PHP template with standard ACF functions like get_field() and have_rows().

Use custom fields in the block editor with ACF Blocks

Custom fields and the block editor work together without friction once you understand the moving parts.

Enable the native custom fields panel through Preferences when you need direct access to raw metadata. Use dedicated block plugins or native block bindings to surface simple field values within the editor canvas.

When your content model outgrows these approaches, with layouts demanding precise markup and fields that must work inside query loops, ACF Blocks provide the scalable path forward. You write PHP instead of React, using functions you already know.

ACF PRO unlocks Blocks alongside:

• Repeater fields
• Flexible Content
• Options Pages
• and the Gallery field.

Upgrade to ACF PRO to build custom blocks that match your exact requirements.

The post How to Use ACF Custom Fields in the Block Editor Without Coding appeared first on ACF.

• Custom post types store structured content, while their fields hold the actual data you display or filter.
• Coding fields manually means registering meta, building UI, validating input, querying, and rendering values yourself.
• That workflow is powerful but fragile; small mistakes lead to missing data or broken templates.
• Advanced Custom Fields (ACF®) replaces all that wiring with a UI, automatic saving, and simple template helpers.

Adding custom fields to your custom post types (CPTs) is a great way to organize and manage data in WordPress.

But while the data gets saved in the database, you can’t do much with it unless everything is properly set up.

To unlock the full potential here, you’ll need to handle a few key steps on the backend first: 

• Registering the fields
• Creating a simple interface for adding data
• Ensuring everything is saved properly
• Then displaying it on the frontend

Next steps are to learn the manual process for handling WordPress custom post type fields, or go with a more automated way using Advanced Custom Fields (ACF®).

Let’s get started.

How custom post types and their fields work

Custom post types are WordPress content containers you create when posts and pages don’t fit the job. They hold structured data like products, events, portfolio items, or property listings.

If you’ve seen the term “custom content type,” it’s simply another name for the same thing – WordPress’s actual implementation calls them custom post types.

Custom fields are the individual data points stored inside those posts – things like price, date, number of bedrooms, or square footage.

On a real estate site, for instance, you might register a Properties post type to separate listings from your blog.

Each property needs a price, number of bedrooms, square footage, and maybe a map location. Those values don’t belong in the title or main editor field. They need their own fields, which WordPress stores separately in post meta.

Understand this separation, and the workflow makes more sense: the post type defines the content category, while custom fields hold the specific facts you want to display or filter by.

How to register a custom post type

Registering a custom post type is likely familiar territory, but we’ll still do a quick pass before we move into field handling.

If you prefer a more straightforward UI approach, ACF includes CPT creation – our dedicated guide to creating a custom post type walks through that in detail.

In short, though: go to ACF > Post Types > Add New, set a name, choose labels, and decide which features it supports (title, editor, thumbnail, etc.).

Publish it, and WordPress adds it to the admin menu automatically.

If you want instead to build CPTs in code, we also have a more in-depth guide to WordPress custom post types. In a nutshell:

1. Call register_post_type() inside a must-use plugin or a custom code snippet. 
2. Set labels to define the admin UI text.
3. Use supports to determine available editing features.
4. Configure has_archive to control whether an archive page exists. 
5. If you want WordPress’s built-in Custom Fields box to show up, add 'supports' => ['custom-fields'] – it appears in the classic editor and Gutenberg’s screen options.

That said, many modern setups skip the legacy metabox and rely instead on explicitly registering fields using register_post_meta(). It gives better control, REST visibility, and block editor integration.

Either way, the important point is: registering a CPT just creates a container. It doesn’t give you field storage, editing screens, or display logic. That’s what we’re covering next.

How to add WordPress custom post type fields using code

We’ll cover for adding usable fields to custom post types: register the field, show it in the editor, save the value, and output it in your template. 

If you prefer a UI-based workflow, you can let ACF handle most of this. Skip the manual approach and jump ahead.

Registering custom fields

To register a custom field properly, you define it with register_post_meta(). This tells WordPress what the field is, how it should behave, and how it should be stored:

add_action( 'init', function () {
    register_post_meta( 'property', 'price', [
        'type'              => 'number',
        'single'            => true,
        'sanitize_callback' => 'floatval',
        'show_in_rest'      => true,
    ] );
} );

Here, property is the post type and price is the field name. Setting the type helps WordPress validate and cast values correctly. The single parameter tells it to store one value instead of multiple entries. A sanitized callback ensures bad or unexpected data doesn’t end up in your database.

Finally, show_in_rest makes the field available in the block editor and via the API, which matters if you are using Gutenberg or building a headless frontend.

Without this step, WordPress would just treat a field as unstructured meta with no rules attached.

Creating an admin interface for custom fields

If you need a custom interface for entering field values, add a metabox.

WordPress doesn’t create one for register_post_meta(), so you build it yourself:

add_action( 'add_meta_boxes', function () {
    add_meta_box( 'property_price', 'Property Price', 'property_price_box', 'property' );
} );

function property_price_box( $post ) {
    wp_nonce_field( 'save_price', 'price_nonce' );
    $value = get_post_meta( $post->ID, 'price', true );
    echo '<input type="number" name="price" value="' . esc_attr( $value ) . '" />';
}

This attaches a box to the Property CPT editor screen.

Inside the callback, you load the stored value with get_post_meta() so editors can update it, output a nonce for security, and render the input field.

You only add metaboxes when the default UI isn’t enough or when you want a controlled layout. This complements the registration step by giving editors a clear place to enter data.

Saving field values securely

To store the value, hook into save_post and make sure the request is legitimate:

add_action( 'save_post_property', function ( $post_id ) {
    if ( ! isset( $_POST['price_nonce'] ) || ! wp_verify_nonce( $_POST['price_nonce'], 'save_price' ) ) {
        return;
    }
    if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
        return;
    }
    if ( ! current_user_can( 'edit_post', $post_id ) ) {
        return;
    }

    $value = isset( $_POST['price'] ) ? floatval( $_POST['price'] ) : null;
    update_post_meta( $post_id, 'price', $value );
} );

This checks the nonce, skips autosaves, and verifies user permissions before doing anything. The input is sanitized based on the field’s expected type, then stored with update_post_meta().

If you registered the field with a sanitize callback, WordPress will also enforce cleanup automatically.

Displaying custom field values on the frontend

To show your field on the frontend, call get_post_meta() inside your template:

$price = get_post_meta( get_the_ID(), 'price', true );
if ( $price ) {
    echo '<p>Price: ' . esc_html( number_format( $price ) ) . '</p>';
}

This reads the stored value for the current post. You handle formatting yourself. Maybe add a currency symbol or wrap it in markup. Always escape output so untrusted data doesn’t leak into the page; esc_html() works for text, esc_attr() for attributes, and wp_kses() for controlled HTML.

If you enabled show_in_rest when registering the field, the value also appears in the block editor sidebar and in REST API responses. That makes it usable for Gutenberg blocks, headless frontends, or external integrations.

Querying posts by custom field value

You can filter posts by field values using WP_Query and a meta_query. For example, to list properties priced under $500,000:

$query = new WP_Query([
    'post_type'  => 'property',
    'meta_query' => [
        [
            'key'     => 'price',
            'value'   => 500000,
            'compare' => '<',
            'type'    => 'NUMERIC',
        ],
    ],
]);

meta_query supports comparisons like =, !=, <, >, BETWEEN, and LIKE, so you can match ranges, search text, or filter content by category. This works with fields created via register_post_meta() or normal post meta.

You’ll use this pattern anytime you need dynamic listings, e.g., showing events after today or powering custom search pages.

Managing custom post type fields with ACF (the faster way)

Writing meta logic yourself works, but it’s fragile. One missed capability check or sanitize step can create bugs you don’t notice until something in your workflow fails.

ACF exists to eliminate that risk.

It gives you a UI, builds the metaboxes, saves values correctly, and keeps things consistent across projects. That’s why most agencies default to it once they’ve had enough of debugging their own field code.

Adding fields for a CPT in ACF takes a handful of actions:

1. Open ACF > Field Groups > Add New.
2. Create your fields from 30+ field types with the correct types, labels, and names.
3. Set a location rule so the group appears only on your CPT. You can see the location rules at the bottom of the page here:

4. Save the group.

That’s it.

The editor screen will now show usable inputs without requiring you to wire anything up.

ACF writes the meta, validates it, and stores it.

For a complete walkthrough of creating custom post types and fields with ACF, including how to display them in your theme, you can watch this tutorial:

If you’re using a major page builder such as WPBakery, Bricks, or Beaver Builder, you can display these fields on the frontend without touching any code.

If you build themes manually instead, ACF gives you get_field() to fetch values and the_field() to output them, so you don’t have to write the retrieval and display logic yourself.

When you’re managing sites for repeat clients, reliability like this goes a long way.

Troubleshooting issues with fields not displaying

Building custom fields by hand invites breakage. ACF sidesteps most of these problems, but if you’re going the DIY route, here’s what to watch for, and what to do:

• Field group location rules misconfigured means your fields don’t appear because WordPress doesn’t think they belong to that post type. Fix it by correcting the location rules so they target the right CPT.
• Template file not loading happens when you edit a parent theme file while a child theme actually controls output. Move your changes into the active child theme template.
• Code outside the loop occurs when retrieval runs before WordPress knows which post is being displayed. Wrap your calls inside the Loop or pass the correct post ID manually.
• Caching masking updates means stored values exist, but the frontend or editor shows stale data due to object or page cache. Clear all caches after registering fields or saving meta.
• Hidden UI panels occur when the Screen Options toggle disables field visibility. Enable the panel at the top of the editor.
• Permalinks not refreshed lead to CPT routing issues and missing fields. Visit Settings > Permalinks and click Save.
• Data exists but isn’t showing typically means your logic fails silently because you’re referencing the wrong field name or context. Dump values with var_dump( get_post_meta( $post->ID ) ) or var_dump( get_field( 'field_name' ) ) to verify before debugging templates.

Let ACF handle your custom post type fields

Custom fields turn generic post types into structured, queryable content.

You can build the system yourself – register meta, create metaboxes, handle sanitization, and write template logic – but every step is another place for things to break. ACF handles all of that for you.

“ACF handles the repetitive, error-prone parts of custom fields – the sanitization, validation, and security checks – so developers can focus on building the features that make their projects stand out. It’s about freeing you up to do your best work.”

– Liam Gladdy, Senior Software Engineer at ACF and WP Engine.

Define fields visually, attach them to any post type, retrieve values with clean functions, and skip the fragile wiring entirely. You avoid nonce juggling, capability checks you might miss, sanitization errors, and site-breaking failures from referencing the wrong key.

If you’re building a single site or managing dozens for clients, ACF gives you a workflow that scales reliably.

When you’re ready to simplify your custom field workflow, download ACF and start building more fine-tuned WordPress sites.

The post How to Add WordPress Custom Post Type Fields appeared first on ACF.

ACF PRO v6.8.0-beta1 is now available with Abilities API support.

Integration with the New WordPress Abilities API

This release includes support for the Abilities API, a brand-new API that arrived in WordPress 6.9, designed to bring a unified, secure, and machine-readable way for plugins and themes to expose their capabilities.

The beta provides full exposure of the ACF schema and data via this new mechanism. Crucially, this integration will enable compatible tools, such as Agentic AI and automation platforms, to create, read, and update ACF field groups, custom post types (CPTs), and taxonomies, as well as interact with the data within those items.

This establishes ACF data as an immediate, first-class resource for any tool that integrates with the WordPress Abilities API.

Key Benefits

• ACF is Future-Proofed for AI: By integrating with the WordPress Core Abilities API, ACF’s structured data becomes instantly discoverable, interoperable, and secure for the next generation of AI and automation tools.
• Enhanced Interoperability: It lays the groundwork for any other systems built on the new WordPress Core standard.
• Structured Data, Simplified: ACF’s rich content model is immediately available to these advanced tools, establishing ACF as a foundational component for building the most sophisticated agentic WordPress experiences.

ACF Capabilities

With this release we expose the following capabilities:

This list of abilities is not fully reflective of what will be shipped in ACF 6.8, as some abilities may be added, changed, or removed prior to the official release.

What Does This Enable?

By exposing ACF’s schema and data through the WordPress Abilities API, ACF 6.8 unlocks a range of new workflows powered by AI and automation tools, without bypassing the WordPress security or permission model.

Here are a few examples of what this makes possible:

• AI-Assisted Content Modeling: Tools can now inspect existing custom post types, taxonomies, and ACF field groups, then create or extend data models based on intent rather than manual configuration. This allows AI to help design and evolve structured content models, not just generate content.

• Programmatic SEO from Structured Data: Large datasets, such as CSV files of locations, services, or products, can be turned into fully structured WordPress content. AI tools can create the required data model in ACF, validate each entry against field definitions, and safely import content at scale.

• Controlled Bulk Content Operations: Automation tools can query and update ACF-powered content using officially exposed capabilities. This enables responsible bulk operations – such as normalizing field values or updating metadata- while respecting validation rules and access controls.

• Rapid Prototyping and Demo Sites: Developers and agencies can generate realistic demo sites in minutes. Tools can create post types, taxonomies, field groups, and seed content automatically, dramatically reducing setup time for prototypes and client demos.

These examples are only the beginning. ACF 6.8 focuses on establishing the foundation that allows compatible tools to safely understand and interact with WordPress content models in a structured, future-proof way.

How Tools Integrate with ACF 6.8

ACF 6.8 does not introduce a new AI tool or workflow of its own. Instead, it exposes ACF’s schema and data through the WordPress Abilities API, allowing compatible external tools to integrate with WordPress in a secure, standardized way.

For example, an agentic development tool such as Claude Code can be connected to a WordPress site running 6.9 using an MCP (Model Context Protocol) server. Once connected, the tool can:

• Discover which ACF field groups, post types, and taxonomies allow AI access
• Create or modify ACF field groups using official capabilities
• Query, create, and update content that uses ACF fields
• Respect WordPress permissions and ACF’s AI access controls

From the tool’s perspective, ACF becomes a structured, machine-readable content model rather than a collection of admin screens.

ACF 6.8 focuses on providing the capabilities layer that makes these integrations possible. Specific setup steps will vary depending on the tool being used.

Testing the Beta

As it is a beta release, we do not recommend using this on production sites, but have released it for the broader ACF community who wish to test on development and staging environments so we can gather feedback for the general release.

This is a PRO only release. To access this release, please log in to your account and navigate to the “Licenses” page. You can then select “6.8.0-beta1″ from the available downloads or click on the ‘Install pre-release version’ tab for full instructions.

Learn more about testing pre-release versions of ACF PRO.

Enabling ACF AI

Once you’ve installed the beta, you will need to opt-in to the new AI features by adding the following filter to your theme’s functions.php or a custom plugin:

add_filter( 'acf/settings/enable_acf_ai', '__return_true' );

This filter enables the abilities and adds a new “ACF AI” tab. For existing field groups, post types, and taxonomies, the AI access setting will be off, requiring a manual opt-in. Any new items created will have the setting enabled by default.

To hear about future pre-release versions as they are released, sign up to our Beta news email list.

For the latest ACF news, follow us on X @wp_acf.

Changelog

• New – ACF now supports the WordPress Abilities API, with abilities for field groups, post types, and taxonomies

The post ACF PRO 6.8 Beta 1 appeared first on ACF.

Please find the release notes below. And for the latest ACF news, follow us on Twitter @wp_acf.

Changelog

PRO Only Release

• Fix – Fields in V3 Blocks used as an InnerBlock are now clickable
• Fix – V3 Blocks with a script tag in the render template no longer crash in the editor
• Fix – V3 Blocks with Inline Editing enabled no longer crash the browser tab in some scenarios
• Fix – V3 Blocks with Inline Editing enabled used as an InnerBlock no longer update the field values of the parent block
• Fix – Quickly closing the expanded editor for V3 blocks will no longer prevent field values from being updated
• Fix – Posts with V3 blocks can now be saved without clicking the block

The post ACF PRO 6.7.0.2 appeared first on ACF.

Hosted by Phil Johnston, Anthony Burchell, and Matt Shaw.

Sign up for the next session →

Session Recording

Watch the full session below or skip to the highlights in the session summary.

Session Summary

Phil Johnston opened the session by introducing ACF 6.7, which released on December 3rd. The centerpiece of this release is Inline Editing, a feature that allows content editors to edit ACF fields directly within the block preview, eliminating the need to use the sidebar or a separate edit form.

Phil conducted a live demo showcasing two primary modes of Inline Editing:

• Text Editing: For text-based fields like Text or Text Area, users can click directly on the text in the preview and type changes, which automatically syncs to the ACF field.

• Toolbar Editable: For non-text fields like Images, clicking the element reveals a popover toolbar where users can modify the field, such as swapping out an image.

The demo highlighted how easy it is to enable this feature. Developers simply need to add "autoInlineEditing": true to the acf object in their block.json file. ACF then automatically scans the render template to detect fields and apply the editing capability.

For more advanced use cases, Phil demonstrated how to customize the experience using the acf_inline_toolbar_editing_attrs() helper function. This allows developers to manually define which fields appear in the toolbar for a specific element. He showed a sophisticated example where clicking a heading allowed users to set responsive font sizes for mobile, tablet, and desktop using custom icons in the toolbar.

Other key features discussed included:

• Block Toolbar Integration: Using the acf/block_top_toolbar_fields filter to add ACF fields directly to the main block toolbar (e.g., for layout toggles or background colors).

• Hide Fields in Sidebar: A new block.json setting to hide ACF fields from the sidebar entirely, decluttering the UI when Inline Editing or the pop-out editor is preferred.

• Customizable Popover Width: The ability to define a minimum width for the Inline Editing popover, useful for complex fields like Google Maps.

Q&A

Questions and answers from the session may have been edited for clarity.

Q: Can I use the WordPress icon names (dashicons) for the toolbar icons instead of custom SVGs?

A: Currently, you need to provide the SVG markup for custom icons. However, the team agreed that allowing users to simply pass a WordPress icon name would be a great enhancement and something they could look into implementing.

Q: Does Inline Editing work if I assign the field value to a PHP variable before outputting it in the template?

A: Yes. ACF scans the template for field values, so assigning get_field() to a variable and then outputting that variable will still work with the automatic detection.

Q: What does the acf_inline_toolbar_editing_attrs() function output?

A: It outputs a string of HTML attributes that are used by the block editor to identify the element as inline editable and determine which fields to show. These attributes are only present in the editor and do not render on the front end.

Q: How did you implement the responsive font size controls in the demo?

A: The implementation involved three Select fields (mobile, tablet, desktop) that output specific CSS classes (e.g., mobile-font-size-small). These classes are combined and added to the heading element. In the stylesheet, media queries define the font size for each class at different breakpoints.

Resources & Links

• ACF 6.7 Release Post
• Inline Editing for ACF Blocks
• ACF Beta News Signup
• ACF Feedback Page

Coming Up on ACF Chat Fridays

Register today for the next session of ACF Chat Fridays. Sessions are typically held on the first Friday of every month. Questions and suggestions for the development team are always welcome.

Register for the next session of ACF Chat Fridays here: https://wpeng.in/acf-chat-fridays/

The list of upcoming sessions is below.

• January 9, 2026

• February 6, 2026

• March 6, 2026

• April 3, 2026

Tag or DM us on X (formerly Twitter) with suggestions or feedback using #ACFChatFridays.

The post ACF Chat Fridays: Inline Editing for ACF Blocks appeared first on ACF.

And it brings a host of updates that will directly impact developers working with ACF PRO. With over 400 Core Trac tickets, including 125+ enhancements and 250+ bug fixes, the 6.9 release continues to evolve in powerful ways.

In addition to updates in the Block Editor, Site Editor, and performance, this release focuses heavily on new block registration, field systems, API architecture, and editor workflows, all of which are critical for developers using ACF PRO to manage custom fields and custom content types.

There are several key changes you’ll want to pay attention to—especially the introduction of the Abilities API, improvements to the Field API, and major updates to the Block Editor and DataViews.

ACF PRO remains fully compatible with WordPress 6.9, and the updates will provide exciting new opportunities for block development, AI integration, and aligning your custom field systems with the evolving WordPress landscape.

Let’s dive into the most important updates for ACF PRO users in this release.

The Abilities API: Major Impact for ACF PRO

As part of the broader initiative AI Building Blocks for WordPress, the Abilities API acts as a unified capability registry that allows WordPress Core, plugins, themes, and even AI tools to register their functionality in a machine-readable format.

Essentially, it’s a way to tell WordPress software what each plugin or theme can do, and it opens up significant potential for automation and enhanced integrations.

Why this matters for ACF PRO

For ACF PRO developers, the Abilities API is crucial because it paves the way for interoperability between ACF and other WordPress software components, particularly when it comes to AI tools.

Here’s why this matters:

• Full Schema Interaction: This upcoming feature will allow ACF to interact seamlessly with the Abilities API. Once available, ACF data will become easily discoverable and accessible by any compatible tool, allowing you to connect ACF data, such as Field Groups and Custom Post Types (CPTs), directly to other plugins, themes, or even AI tools.
• Ready for Agentic AI: The integration with Agentic AI means that ACF content will be first-class data for any AI-driven tool that can read structured content. This has massive implications for workflows involving AI assistants, content generation, and automation.
  
• Controlled Access: Importantly, this will be an opt-in feature. As a developer, you’ll have full control over whether you expose ACF data to AI tools. Administrators will need to enable it explicitly, ensuring that data is only shared when you want it to be.

As AI continues to evolve, the Abilities API sets the stage for ACF data to become much more dynamic and discoverable, allowing ACF users to automate processes and integrate custom fields in ways never before possible.

Field API Updates

The 6.9 release includes some crucial updates to the Field API, including:

• 10+ new field types
• 11+ new edit controls with validation
• and 16+ filter operators.

There are also new options like readOnly field attributes and expanded filterBy capabilities. 

While this may seem like a minor change, it has major implications for how ACF PRO developers will work with custom fields in the future.

For ACF users, these changes are primarily intended to power the new WordPress AdminViews, a modern interface for managing data directly within the WordPress admin. 

Here’s how this impacts ACF developers:

• Focus on AdminViews: The updates to the Field API are designed to support a more modern, UI-driven approach to managing fields in the WordPress admin. While ACF fields themselves won’t change immediately, this update aligns with the WordPress ecosystem’s new approach to data management.

DataViews & DataForms Improvements

One of the most powerful updates in the 6.9 release is the improvements made to DataViews and DataForms. These are essential for developers using ACF field data in the WordPress admin, particularly for building custom UIs and improving data management.

Key improvements include:

• Infinite Scroll: This feature allows you to display large datasets efficiently without manually paginating, which is essential for sites with ACF Repeater fields or relationship fields.
• New Layouts: New Card, Row, and Activity layouts are available, offering more flexible and interactive ways to present data in custom admin views.
• State-managed Children: This enables custom layouts that automatically manage state, including filtering, sorting, and pagination.
• Improved Validation: A complete overhaul of validation for synchronous and asynchronous checks ensures your data is always accurate and reliable.

These Core updates provide the architectural primitives that could allow ACF to eventually offer highly customizable admin dashboards for your Custom Post Types—enabling you to build rich, interactive views (like Kanban boards or galleries) directly within the plugin.

The addition of infinite scroll and better state management paves the way for future ACF interfaces to handle thousands of repeater rows or relationship connections with significantly improved performance.

As these standards mature, ACF can leverage them to create “DataForm-native” editing screens that feel like a seamless part of the modern WordPress admin, moving beyond the classic metabox design.

Block Editor & Block Architecture Updates

The 6.9 release introduces several updates to the Block Editor, many of which will make working with ACF Blocks easier and more intuitive.

1. Direct Drag and Drop

The ability to drag and drop blocks directly within the editor has been improved, making it easier to organize ACF Blocks in the editor. This is particularly useful for developers creating custom layouts and reusable components.

2. Ability to Hide Blocks

This release introduces a feature where you can hide blocks without losing their field data. This is especially useful for content editors who want to stage content without permanently deleting it.

3. Iframe Integration & apiVersion 3 Enforcement

The transition toward using iframes for the WordPress block editor is progressing, and apiVersion 3 has been enforced for all new or updated blocks. This ensures a consistent and stable block registration process moving forward.

ACF Impact

ACF Blocks V3 are fully compatible with iframe-based block editors and apiVersion 3. This ensures that ACF Blocks remain fully functional within the evolving WordPress editor.

Additionally, the new streaming block parses (WP_Block_Processor) improves the way ACF Blocks encoded in raw HTML or patterns are processed, ensuring that your blocks parse more reliably.

New Blocks & Improvements Relevant to ACF Developers

The 6.9 release introduces several new blocks, including:

• Accordion Block
• Term Query Block, Math Block
• and Improved Heading / Time-to-Read blocks.

The new native blocks will help reduce the need for custom ACF Blocks for common use cases. 

However, ACF Blocks built using the <InnerBlock> component can now integrate these new blocks directly into your custom ACF Block layouts, saving time and development effort.

Updates to Block Bindings API

The Block Bindings API is being improved in the 6.9 release, providing a more intuitive way to manage block attributes and integrate ACF fields.

• Developers can now easily switch between sources and bind/unbind attributes with a single click.
• The new block_bindings_supported_attributes_{$block_type} filter makes it even easier to map ACF fields to block attributes.

These improvements streamline the way ACF Blocks interact with the block architecture in WordPress software, making it easier to manage and map ACF fields to block attributes, especially for dynamic and interactive blocks.

Expect ACF support for the block bindings UI soon.

Updates to Interactivity API

The Interactivity API has been updated to support more predictable state management and directive handling, which will directly benefit developers working with dynamic blocks.

For ACF users, creating interactive ACF Blocks can now rely on more consistent rendering and script management.

The result? Smoother, more predictable front-end interactions.

Updates to HTML API

The 6.9 release introduces important changes to the HTML API, such as making serialize_token() public and enforcing stricter script text handling.

These changes provide more robust sanitation when ACF manipulates or outputs HTML data, ensuring cleaner and more secure handling of content.

Updated Admin Menu Search Query

The 6.9 release also changes how the admin menu search query behaves. It now uses $_GET instead of relying on the raw query strings ($_SERVER[‘QUERY_STRING’]).

Action required If you have ACF admin page extensions that depend on menu searches, you may need to review your assumptions and ensure compatibility with this updated search behavior. Make sure your custom code aligns with the new method for retrieving the search value in the admin menu.

PHP 8.5 (beta) Support

The 6.9 release introduces beta support for PHP 8.5, which will be fully supported in future releases.

Currently, ACF is testing and making sure we’ll be fully compatible and intend for an upcoming release to officially mark ACF as supporting PHP 8.5.

AI-Related Work Relevant to ACF PRO

The 6.9 release opens up exciting possibilities for AI-powered workflows, with the PHP AI Client and MCP Adapter tools.

• PHP AI Client allows you to integrate AI-assisted field workflows like autofill or content generation directly into ACF fields.
• MCP Adapter enables AI assistants to consume ACF field structures for automation.

These tools pave the way for AI-assisted content management, where ACF fields can be dynamically populated, modified, or enhanced by AI tools, improving workflow efficiency and unlocking new possibilities for automation.

Wrap up

This is not an exhaustive list of all the enhancements in WordPress 6.9. The official field guide includes additional updates that may also affect your ACF PRO workflows, such as:

• New REST API filters to better manage queries
• Updates to the admin menu search query for more predictable search behavior
• Improvements to accessibility across WordPress interfaces
• Further enhancements to the Block Editor and Site Editor
• And more…
  

These changes, while technical, offer many opportunities to streamline ACF workflows and improve integration with the broader WordPress ecosystem.

As always, make sure to back up your site before updating to the 6.9 release. And if you’re looking to leverage the full potential of ACF PRO’s features, stay tuned for upcoming releases that will make the most of the new updates in this release—especially in areas like AI integration, admin UI modernization, and data management.

FAQs

1. Is ACF PRO fully compatible with WordPress 6.9?

Yes. ACF PRO is compatible with all new block APIs, field updates, interactivity changes, and PHP 8.5 beta support in WordPress 6.9.

2. How does the new Abilities API affect ACF PRO?

The Abilities API allows ACF data to be more discoverable and interoperable with AI tools. It also provides more predictable access and control over data, enhancing future AI integrations.

3. Do the new Field API updates replace ACF fields?

No. The Core Field API is a standardization layer for managing data in WordPress admin interfaces. ACF will continue to provide powerful custom fields beyond what’s available in Core.

4. Will my existing ACF Blocks work with apiVersion 3 requirements?

Yes, but you should validate your blocks to ensure they are using ACF Blocks V3, which supports apiVersion 3 for future compatibility.

5. Does the new Hide Blocks feature affect ACF field data?

No. Hidden ACF Blocks retain their field data, which will reappear when the block is made visible again.

6. Does the Interactivity API update affect ACF Blocks?

Yes. The Interactivity API improvements help ACF Blocks work more predictably, especially for dynamic blocks with complex interactions.

7. Do I need to change anything due to the updated query cache or menu search?

Most users won’t need to change anything, but developers extending ACF admin pages may want to review assumptions about how menu search operates.

8. Can ACF integrate with the new PHP AI Client or MCP Adapter?

Yes. These integrations will allow AI-powered content generation directly into ACF fields and make ACF data more AI-friendly for future automation.

The post What’s New in WordPress 6.9: Key Changes ACF PRO Users Should Know appeared first on ACF.

This release introduces Inline Editing, a groundbreaking feature for ACF Blocks, allowing content editors to edit block field data by clicking directly on what they want to edit in the block preview area, without requiring any extra code or JavaScript by the block creator.

Inline Editing for ACF Blocks

Inline Editing is an opt-in feature for ACF Blocks that are built using version 3. It greatly simplifies the editing experience of sites that use ACF Blocks, making ACF Blocks much easier to edit, and similar to native blocks. ACF Blocks turn the block editor into a powerful site editing tool without developers compromising on the design integrity and builds of their sites, all the while giving content editors an easy, flexible, and controlled editing experience.

Two Types of Inline Editing

Inline Editing provides two distinct experiences for content creators, depending on the ACF field’s data type:

• Text Editable: Offers the most native-like feel, allowing editors to type directly into an element within the block preview area. This functionality is primarily available for Text and Text Area fields.
• Toolbar Editable: Used for all other supported field types (excluding Repeaters and Flexible Content fields and their subfields). When a field is clicked, a pop-up toolbar appears where the content can be edited using the familiar ACF field editing UI.

An example of a Text Editable field:

An example of a Toolbar Editable field:

Field Type Support

Here’s a breakdown of what editing experiences are available for each field type. We plan to improve the inline editing experience for fields that have subfields like the Repeater. The Expanded Editing Panel was introduced in ACF 6.6 to replace ‘Edit’ mode for blocks and to improve on the sidebar editing experience.

Field Type	Text Editing	Toolbar Editing	Expanded Editing Panel
Text
Text Area
Number
Range
Email
URL
Password
Image
File
WYSIWYG Editor
oEmbed
Gallery
Select
Checkbox
Radio Button
Button Group
True/False
Link
Page Link
Post Object
Relationship
Taxonomy
User
Google Map
Date Picker
Date Time Picker
Time Picker
Color Picker
Message
Accordion
Tab
Group
Repeater
Flexible Content
Clone

How to Enable Inline Editing

To take advantage of Inline Editing, your blocks must be using version 3 of ACF Blocks. From there, you have two options to enable Inline Editing for your blocks.

To enable it automatically for simple elements, set autoInlineEditing to true in your block’s block.json file.

    "acf": {
    "blockVersion": 3,
    "autoInlineEditing": true
}

With this enabled, ACF will automatically apply inline editing to any HTML elements where an ACF field’s value is the only thing within it, or to HTML attributes whose value comes directly from an ACF field (e.g., an tag’s src).

For those who want more control, two helper functions can be used in your block render template:

acf_inline_text_editing_attrs(): Use this to make an element directly editable like a Text field.

<h3 <?php echo acf_inline_text_editing_attrs( 'my_text_field' ); ?>>
    <?php echo esc_html( get_field( 'my_text_field' ) ); ?>
</h3>

acf_inline_toolbar_editing_attrs(): Use this to make an element pop up a toolbar when clicked.

<img src="some-image.png" <?php echo acf_inline_toolbar_editing_attrs( array(
    'my_image_field'
) ); ?> />

You can mix both auto and manual fields. If you want complete manual control, set autoInlineEditing to false in your block.json.

There are multiple configuration options for Inline Editing. Read our documentation to get started

Inline Editing is only available to ACF Blocks that are using version 3. Learn more about upgrading your blocks to v3.

ACF Blocks is a feature only available in ACF PRO.

And More

For a full list of all the changes in this release, check out the ACF 6.7 changelog.

What’s Next?

We’re already hard at work on the next version of ACF, with more new features and improvements planned – including support for the WordPress Abilities API, allowing Agentic AI and automation platforms to fully utilize your content.

If you want to be the first to hear about pre-release versions of these new features for testing, sign up to our beta news email list.

If there’s features or improvements you’d love to see in ACF, please drop them into our feedback board and vote on others that are important to you.

Keep up to date with what we’re working on in our monthly ACF Chat Fridays office hours.

Thanks to everyone in the ACF community who helped make this release possible!

Are you excited about the new features and improvements in ACF 6.7? Let us know in the comments below or on X.

The post ACF 6.7 Release – Meet Inline Editing for ACF Blocks appeared first on ACF.

This is your chance to join thousands of developers building with the real deal. This is the lowest price of the year on ACF PRO, available only for a limited time! Please note this discount is only available to new customers.

Unmissable Savings on ACF PRO

For a limited time, new customers can get up to 40% off ACF PRO licenses for the first year. This is the innovation you need to model complex data, now available at a price you can’t pass up.

Beyond ACF PRO, you can complete your entire developer toolkit with discounts from our partners. All discounts are for your first year only:

• WP Migrate Pro: This ultimate migration plugin is up to 50% off, allowing you to push and pull databases, media, themes, and plugins seamlessly.

• WP Offload Media: Reduce your server load and speed up delivery by offloading your media files to cloud storage. Save up to 40% on your first year.

• WP Offload SES: Ensure all your critical emails are reliably delivered. Save up to 20% on your first year.

• NitroPack: Achieve top scores on Core Web Vitals and get an instant site speed boost. Save up to 40% on plans (excluding the Starter Plan). This special discount replaces any existing evergreen deal.

ACF PRO is constantly evolving to meet the demands of modern development. The ACF Blocks V3 update is a game-changer, giving content editors a much-improved, streamlined experience where fields now open in a dedicated sidebar—making it easier to manage complex fields like Repeaters and Galleries.

Don’t Miss Out!

The time to invest in the tool trusted by pros is now. The sale runs from November 17th through December 5th, 2025.

The post Devs Who Know Choose ACF PRO: Get the Year’s Lowest Price on the Real Deal appeared first on ACF.

ACF PRO v6.7.0-beta1 is now available with the much anticipated Inline Editing feature for ACF Blocks.

ACF 6.7 has been released! Read the release post.

Testing the Beta

This is a PRO only release. To access this release, please log in to your account and navigate to the “Licenses” page. You can then select “6.7.0-beta1″ from the available downloads or click on the ‘Install pre-release version’ tab for full instructions.

As it is a beta release, we do not recommend using this on production sites, but have released it for the broader ACF community who wish to test on development and staging environments so we can gather feedback for the general release.

To hear about future pre-release versions as they are released, sign up to our Beta news email list.

For the latest ACF news, follow us on X @wp_acf.

Changelog

• New – ACF Blocks V3 now supports Inline Editing — edit your block content directly in place, right inside the editor. Just opt in to enable it.

The post ACF PRO 6.7 Beta 1 appeared first on ACF.