When I first discovered ACF Pro’s flexible content field, I fell into the trap of treating it like a full page builder. I defined 30 layouts with real elbow grease and the client said “I can build every page myself now”. Three months later the admin panel was taking 45 seconds to open and the post_meta table had crossed 200,000 rows. I had the wrong mental model.
ACF Pro’s most powerful fields are life-savers when you use them right and trip you up when you don’t. Here are two worth walking through in detail.
Flexible content
Simple concept. You define a set of “layouts” (hero, gallery, testimonial, CTA, etc.) and the editor builds the page by stacking them. Each layout has its own sub-fields.
Upsides:
– The editor is free to assemble pages without a designer in the loop.
– Each layout renders cleanly as a template-part on the theme side.
– Per-field permission control is straightforward.
Traps:
– Too many layouts and the panel slows down and the editor gets confused.
– Every layout creates its own post_meta row. A page with 10 layouts can produce close to 100 rows.
– For performance, get_field has to query each layout type separately.
– Versioning is painful. Remove a layout and old pages are left with orphan data.
My rules:
– Max 8 to 10 layouts. Beyond that, the site loses cohesion.
– Every layout has a clear job. No “general-purpose text block”; editors will put it everywhere and design consistency goes out the window.
– Layout names are semantic, “service_grid”, not “layout_1”.
– In have_rows loops, check the layout type first and skip early for performance.
– Before deleting an old layout, write a migration script and clean up the orphaned data.
Clone field
For reusing the same field group in multiple places. It serves DRY, but the prepend/display modes change behavior and can confuse.
Modes:
– Seamless: cloned fields appear directly inside the parent, field keys (meta_key) stay the same.
– Group: cloned fields are grouped under a prefix, accessed as clone_name.subfield.
My mistake: cloning the same button group in seamless mode in both hero and CTA. The same meta_key collided in two places. Data got corrupted. Group mode is always safer. You accept a prefix, and meta_key collisions don’t happen.
Another gotcha: using flexible content inside a clone field. It technically works, but performance drops and JSON export/import behaves inconsistently. Avoid it.
Practical example
On a corporate site I had 12 service pages, all with the same structure: hero, benefits, features, pricing, FAQ, CTA. To stop editors from reinventing each page with flexible content, I centralized the pricing and FAQ sections with clone fields. The editor updates pricing once and all 12 pages follow. Clone field + options page was a great fit for that case.
On a different project, the editor wanted per-page pricing, so I didn’t use a clone field. I exposed a pricing layout inside flexible content and left the freedom per page. Centralization is a per-case call.
ACF JSON export and git sync
ACF Pro can write field groups to an acf-json/ folder that you commit to git. That makes cross-environment sync painless. It’s the only way to stop copying field definitions out of the production database into branches. Enable acf/settings/save_json and acf/settings/load_json in the theme and field groups get versioned alongside the code.
Data cleanup
During one migration I had to clear orphaned ACF post_meta rows. This query did the job:
DELETE pm FROM wp_postmeta pm
LEFT JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.ID IS NULL;Meta isn’t automatically removed when a post is deleted unless the right hook is wired up. On large sites the cleanup reclaims real space.
Bottom line: ACF Pro is powerful, but without discipline it grows its own monster. Moderation in field count, layout variety, and clone usage keeps both the editor experience and the site speed intact.