Advanced Custom Fields plugin review and common issues

Field groups have Location Rules that control where they display. Open the field group in ACF → Field Groups → [group name] and check the Location section. Verify the rule is set correctly — for example, “Post Type is equal to Post” will only show on standard posts, not custom post types. If the rule matches but fields still do not appear, check if the field group is Published (not Draft). Also verify no conflicting rules exist (AND/OR logic can exclude the current screen). Clear your browser cache and reload the editor.

Repeater field data requires the correct template code structure. Use have_rows() to check if rows exist, and the_row() inside a while loop to iterate: while(have_rows(“repeater_field_name”)) { the_row(); $sub = get_sub_field(“sub_field_name”); }. Common mistakes: (1) using get_field() instead of have_rows()/get_sub_field() for repeater data; (2) incorrect field name (use the field name slug, not the field label); (3) calling the function outside the loop for the correct post — pass the post ID as the second argument: have_rows(“field_name”, $post->ID) if not in the main query loop.

ACF stores field data as post meta and also stores a reference to the field key (e.g., field_abc123) in a separate meta key. If the field groups were not migrated with the same field keys, the field key references in the database will not match the new field group definitions. Export field groups from the original site (ACF → Tools → Export) and import them on the new site — this preserves field keys. If field keys changed during migration, use ACF → Tools → Export to get the JSON and re-import, then use a database search-and-replace to update any stored field key references.

ACF Pro includes a Block Type API for creating custom Gutenberg blocks backed by ACF field groups. Register the block in your theme functions.php using acf_register_block_type() with parameters for name, title, render_template, and icon. Create the corresponding PHP template file that outputs the block HTML using ACF template functions (get_field(), etc.). Create an ACF field group with the Location Rule set to “Block is equal to [your block name]” — these fields appear in the block editor sidebar when the block is selected. This approach requires no JavaScript — the block UI uses ACF’s native field editor.

Elementor Pro supports ACF field data through its Dynamic Tags system. In the Elementor editor, click any text or image element → click the dynamic tag icon (lightning bolt) → select ACF Field → choose your field from the dropdown. This works for text, image, URL, and other field types. For custom loops over ACF Repeater data in Elementor Pro, use the Loop Grid widget with ACF Repeater as the data source — this requires Elementor Pro. For Elementor free, use the ACF Shortcode: to output field values.

ACF is the better choice when the project team includes developers familiar with ACF, when the site uses Elementor or Beaver Builder (strong ACF dynamic tag integrations), or when the Gutenberg block builder is needed. Meta Box is better when database performance is a concern (Meta Box uses more efficient data storage for complex relationships), when the project needs a UI-free code-based approach (Meta Box Framework), or when the higher ACF Pro pricing is a constraint. Both are excellent — project-specific factors (ecosystem, team familiarity, complexity) determine which is the better fit.

For standard content modeling with fixed structured data fields (team members with name, photo, bio, title; portfolio items with category, client, year, description), ACF free is fully sufficient. The Pro upgrade becomes necessary when you need Repeater fields (variable number of repeating items, like a list of services each with title and price), Flexible Content (letting editors mix different layout blocks in any order), or a custom Gutenberg block builder. Estimate: approximately 60% of custom field use cases in WordPress development are handled adequately by ACF free.

Yes, that can happen, especially on older sites with many plugins. This usually happens when the plugin, theme, and add-ons are updated out of sequence. In most cases, testing on staging catches the issue before it reaches the live site. From experience, backups and changelog reviews save a lot of cleanup time.

Start by checking whether another plugin already does the same job. In most cases, overlap is what creates avoidable conflicts and performance issues. A common issue is installing a plugin because it looks convenient without checking the stack first. From experience, a short compatibility review avoids most of the pain later.