Every rental property is different. One has a hot tub, fire pit, and kayaks. Another has a game room, pool table, and outdoor shower. A third has none of those things but does have a fully equipped commercial kitchen and a screening room. Each property has its own list of amenities, and that list needs to be accurate, up to date, and manageable by someone who has never touched a page builder in their life.
The traditional approach in Divi is to hard-code amenities directly into the layout. You build the property page, type the amenities in, style them, and move on. Then the property manager emails you because they added a paddleboard and want to update the listing. You open Divi, find the section, edit the text, republish. Two weeks later they removed the kayaks. Repeat indefinitely.
The Divi ACF Loop Engine changes this. You build the amenity layout once in Divi — the design of one amenity item, exactly how you want it to look. Then you bind that section to an ACF repeater field. From that point on, the amenities are managed entirely in ACF. The property manager logs in, adds or removes items from the repeater, and the page reflects the change instantly. No Divi. No developer. No back and forth.
What a repeater field actually gives you
An ACF repeater field is a structured, repeating data set attached to any post or page. For a rental property, you might create a repeater called amenities with two sub-fields: an icon and a label. Each row in the repeater is one amenity. The property manager sees a clean table-style interface in WordPress — add a row, pick an icon, type the label, save. That’s the entire content management experience.
The repeater doesn’t care how many rows it has. Three amenities, thirty amenities, it doesn’t matter. The data is stored in ACF. The Divi layout doesn’t know or care how many items are in the list — it just receives whatever the repeater contains and renders it.
This is the key benefit: the content and the design are completely separated. The design is defined once in Divi. The content is managed in ACF. Neither affects the other.
How the loop engine connects them
In Divi, you build the layout for a single amenity item — one row, one column, whatever design you want. Then in that row’s Advanced settings you add a custom attribute: data-dal-source set to the name of your ACF repeater field. Inside the modules in that row, you reference field values using double curly brace placeholders: {{amenity_label}}, {{amenity_icon}}.
When the page loads, the engine intercepts the rendered HTML after Divi has built it. It finds the row with the binding attribute, reads the ACF repeater data for that post, and clones the row once for every entry in the repeater — replacing the placeholders in each clone with the real field values. What reaches the browser is a fully rendered list of amenities, each one styled exactly as designed, populated with live data from ACF.
The property manager never sees any of this. They see a WordPress edit screen with a repeater field. They add a row, fill in the fields, click update. The page updates.
The rental property use case in practice
Imagine a rental property platform with 40 listings. Each property has its own page, its own set of amenities, its own photo gallery, its own details. Without the loop engine, you have two bad options: hard-code everything into 40 separate Divi layouts, or build a custom PHP template that bypasses the page builder entirely.
With the loop engine, you build one Divi layout — once. The layout uses a Divi Theme Builder template assigned to the rental property post type. Every rental property post shares that template. Each post has its own ACF field groups: the amenities repeater, a gallery field, text fields for the property description and details.
When a visitor views any property, the engine pulls the ACF data for that specific property and populates the shared Divi template with it. Property A shows its amenities. Property B shows its own completely different amenities. Same layout, different data, zero manual work per property.
Adding a new property is creating a new post, filling in the ACF fields, and publishing. The Divi layout is already done. The design is already done. The only work is the content — which is exactly how it should be.
What this works for beyond rental properties
The use case extends to any repeating structured content that doesn’t need its own post type. Team member bios with a headshot, name, title, and bio field. A services grid where each service has an icon, headline, and description. A FAQ section where questions and answers are managed in a repeater rather than hard-coded into a Divi accordion. A features list on a landing page that marketing needs to update monthly. Testimonials with a quote, name, and company field.
In each case, the pattern is the same: the design lives in Divi and doesn’t change. The content lives in ACF and can be updated by anyone with WordPress access. The engine connects them at render time without anyone needing to know the other exists.
Why this matters for content management
Hard-coded content in a page builder is a maintenance problem that compounds over time. Every update requires developer access or at minimum page builder access. Every change carries the risk of accidentally breaking something in the layout. Every new property, team member, or service item requires duplicating and editing a layout rather than just entering data.
Separating content from design — which is what the loop engine enables — makes sites dramatically easier to maintain. The people who manage content don’t need to understand or access the design layer. The people who maintain the design don’t need to touch content. Updates happen in the right place by the right people, and the site stays current without a developer in the loop for every small change.
For Lion Ridge clients, this approach typically reduces the ongoing time cost of content updates by a significant margin — and more importantly, it puts content control where it belongs: with the people who own the content.
The technical foundation
For those who want to understand what’s happening under the hood: the engine hooks into WordPress at template_redirect and uses a PHP output buffer to intercept the fully rendered page HTML after Divi has built it. This approach is necessary because Divi 5 is React-based and renders its HTML outside of WordPress’s standard content filters — meaning the standard plugin hooks don’t see Divi’s output.
The engine scans the HTML for the binding attributes, uses PHP’s DOMDocument parser to locate the relevant elements, fetches the ACF data, clones and populates the template, and replaces the original element in the DOM before the page reaches the browser. On pages without binding attributes, the engine exits immediately with no processing overhead.
The plugin supports ACF text, image, WYSIWYG, and gallery fields, as well as group fields inside repeaters. The gallery binding works the same way as the repeater — bind a Divi gallery module to an ACF gallery field and the module populates from ACF, with Divi’s lightbox and gallery styles preserved intact.
The result is a system that works with Divi and ACF rather than replacing either one — and keeps the design, the data, and the editing experience exactly where they belong.
