ACF Compatibility Layer — get_field() Just Works

The biggest obstacle to switching from Advanced Custom Fields (ACF) or Secure Custom Fields (SCF) isn’t learning a new admin UI. It’s the fact that your theme probably contains dozens (or hundreds) of get_field(), have_rows(), and get_sub_field() calls. Rewriting all of them to use a different API is hours of work and risk of breakage.

Field Forge’s ACF Compatibility Layer implements the full ACF template function API. When Field Forge is active and ACF / SCF is not, the global ACF functions resolve to Field Forge’s storage. Your theme code keeps working unchanged.

---

What’s in the compatibility layer

Field Forge implements these ACF functions natively:

Core field functions

get_field($field_name, $post_id = null, $format_value = true);
the_field($field_name, $post_id = null, $format_value = true);
get_fields($post_id = null, $format_value = true);
get_field_object($field_name, $post_id = null, $format_value = true, $load_value = true);
get_field_objects($post_id = null, $format_value = true, $load_value = true);
update_field($field_name, $value, $post_id = null);
delete_field($field_name, $post_id = null);

Repeater and flexible content loop functions

have_rows($field_name, $post_id = null);
the_row($format_value = false);
get_row($format_value = false);
get_row_index();
get_row_layout();
reset_rows();

Sub-field functions (inside repeater / group / flex loops)

get_sub_field($field_name, $format_value = true);
the_sub_field($field_name, $format_value = true);
get_sub_field_object($field_name, $format_value = true, $load_value = true);
update_sub_field($field_name_or_selector, $value, $post_id = null);

Field group functions

acf_get_field_group($id_or_key);
acf_get_field_groups($args = []);
acf_get_fields($field_group);

Options page compatibility

// Both the 'options' and 'option' pseudo-IDs work
get_field('site_logo', 'options');
get_field('site_logo', 'option');

User field compatibility

get_field('bio', 'user_123');
update_field('bio', $new_bio, 'user_123');

Gutenberg block registration

acf_register_block_type([
    'name'            => 'hero',
    'title'           => 'Hero Section',
    'render_callback' => 'render_hero_block',
    'category'        => 'theme',
    'icon'            => 'cover-image',
]);

Every function above works identically to ACF. Same parameters, same return values, same behavior.

---

How it works

When Field Forge is active:

1. ACF’s global functions are defined by Field Forge via function_exists() guards
2. Calls route to Field Forge’s storage (the custom wp_fieldforge_values table)
3. Return values match ACF’s format — arrays, objects, strings, WP_Image / WP_Post / WP_User objects where appropriate
4. $format_value parameter is respected — passing false returns raw values, true returns formatted values (same as ACF)

If ACF is also active on the same site (during migration), Field Forge’s functions are not registered — ACF takes precedence. After you deactivate ACF, Field Forge’s versions take over. This means you can install Field Forge alongside ACF without conflicts during testing.

---

Why this matters

Migration without theme rewrites

Most “ACF alternative” plugins require you to rewrite every get_field() call in your theme to use their own API. For a site with 200 template files and 500+ field references, this is weeks of work and high risk of regressions.

Field Forge’s compat layer reduces migration to:

1. Install Field Forge alongside ACF
2. Run the field group + value importer
3. Deactivate ACF
4. Test the site — templates should render identically
5. Field Forge is now serving the same data that ACF used to serve

Zero template changes. Zero risk of “I forgot to update that one template.”

SCF compatibility for free

Secure Custom Fields (the WordPress.org fork of ACF created in October 2024) uses the same template functions as ACF — get_field(), have_rows(), etc. Because Field Forge’s compat layer implements the ACF API, it also works for SCF code. If you’re running SCF and want to migrate to Field Forge, same process, same compat layer.

Third-party plugin compatibility

Plugins that integrate with ACF usually call ACF’s global functions. Popular examples:

• WPGraphQL for ACFreads acf_get_field_groups() and acf_get_fields()
• Elementor Dynamic Tagsreads get_field() for dynamic content tags
• Beaver Themerreads get_field() for template parts
• Toolset’s ACF integrationreads ACF’s API

Most of these keep working when you switch from ACF to Field Forge because the compatibility layer provides the same API.

acf_register_block_type() works

ACF’s block registration function is one of the most common ACF Pro features agencies rely on. Custom Gutenberg blocks registered via acf_register_block_type() keep working after migration:

// This code works unchanged with Field Forge active instead of ACF
acf_register_block_type([
    'name'            => 'feature-card',
    'title'           => __('Feature Card'),
    'render_callback' => 'my_feature_render_callback',
    'category'        => 'theme',
    'icon'            => 'star-filled',
]);

function my_feature_render_callback($block) {
    $title = get_field('title');  // Works
    $icon = get_field('icon');    // Works
    // ... render HTML
}

---

What’s NOT in the compatibility layer

For full transparency, here’s what Field Forge doesn’t (yet) replicate from ACF:

• ACF’s admin screensField Forge has its own visual builder with different UI
• ACF’s hook and filter namesField Forge has equivalent hooks, but prefixed fieldforge/ instead of acf/
• acf.php JavaScript API in the adminField Forge has its own JS API
• Some niche ACF filters (field type extensions) — if you rely on custom field types defined via ACF hooks, migration may require small adjustments

For 95% of ACF sites, none of these gaps matter because theme developers only use the template functions, not the internal APIs.

---

Migration confidence

Because the ACF compatibility layer is tested against real ACF test cases, we know it handles:

• Basic text, textarea, number, email, URL fields
• WYSIWYG fields with HTML
• Image and file fields (returns arrays matching ACF’s format)
• Select, radio, checkbox fields (with format_value parameter)
• Date and time picker fields
• Repeater fields with arbitrary nesting
• Flexible content with multiple layouts
• Group fields
• Relationship and post object fields
• Taxonomy and user fields
• Options pages (both 'options' and 'option' pseudo-IDs)
• acf_register_block_type() callbacks
• format_value parameter across all functions

If you find a case where our compat layer behavior differs from ACF, it’s a bug we want to fix. Email support with details.

---

Ready to migrate without rewriting your theme?

Get Field Forge — from $40/year →

The ACF compatibility layer is in every version of Field Forge, including the free one. Migration from ACF or SCF takes minutes, not weeks.