Divi Machine - WordPress Plugin

Divi Machine Guide: Dynamic Catalogs, ACF Fields, Filters, and Templates in Divi

Divi Machine becomes useful when a standard Divi page is no longer enough: content lives in custom post types, those entries have fields, categories, relationships, images, dates, prices, or specifications, and visitors need a fast way to find the right item on the site. In this guide, we are not going through a promotional overview of the plugin. Instead, we will walk through a practical workflow: how to prepare your data structure, install the plugin, output fields, build a catalog card, connect an archive, add filters, and verify the result on the front end.

The main idea is simple: Divi Machine does not replace site planning. It helps connect a well-designed data model to the Divi visual builder. If you understand in advance which post types, fields, and taxonomies your project needs, setup tends to go smoothly. If you start by designing cards and try to figure out the data structure along the way, you are far more likely to end up with empty fields, broken filters, odd sorting, and duplicate archive entries.

This guide is written for site owners, editors, webmasters, and developers who work with WordPress and Divi but do not want to write separate PHP templates for every card. We will keep the wording precise: when a feature is clearly documented, we will say so directly; when behavior depends heavily on the theme, hosting, fields, or plugin stack, we will leave room for verification on a staging copy.

What problem the plugin solves and where it is especially useful

Divi Machine extends Divi for sites where content needs to live in structured records rather than static blocks. A typical example is a catalog of cars, real estate listings, specialists, events, courses, recipes, portfolios, job openings, documents, or products with non-standard attributes. Each entry follows a repeatable structure: title, image, set of fields, category, tags, and possibly a map, gallery, related item, or call-to-action button. The editor fills in the data once, and the site automatically displays it in cards, archives, single templates, and search results.

Standard Divi can produce a polished layout, but once you have a large number of similar items, maintenance becomes the real issue. If cards are built manually on each page, every design change turns into repetitive manual work. Divi Machine shifts the focus to the "data - template - output" relationship. You create a field, populate the entry, build the card template in Divi Library or Loop Builder, and then display the list through Archive Loop, filters, and custom field modules.

Divi Machine is strongest in projects with repeatable cards and property-based search. It works especially well in scenarios where the visitor is not trying to "read a single page" but to "find the right item." For example: choose a car by make, body style, and price; filter events by location and date; show specialists by area of expertise; display listings with a map; build a resource directory with a search form; or show related entries on an item page.

At the same time, the plugin does not magically make a site well-structured. It will not fix chaotic field names, mixed units of measurement, duplicate taxonomies, or a weak catalog architecture. It is best treated as a working tool for a data model that is already clear. Before installation, it helps to sketch a short table: what should be a separate post type, what should be a field, what should be a taxonomy, which fields will power filters, and which are only needed for output on the card.

When Divi Machine is the right fit

The plugin is a good fit for Divi-based sites that need to stay inside a familiar visual builder rather than moving to a separate dynamic content stack. It is especially useful if the team already works with Advanced Custom Fields, Secure Custom Fields, Pods, Meta Box, or a similar custom-data workflow. Divi Machine documentation describes Custom Field Item as a module that can output values from different field providers, not just a single source. In practice, that means the plugin name matters less than whether the field is properly registered, filled in, and available in the correct context.

Another strong use case is a filterable catalog. Divi Machine includes Divi Ajax Filter functionality, which makes it possible to build archives with filters based on categories, taxonomies, custom fields, price, WooCommerce attributes, and search text. This is more than a visual card grid. The visitor interacts with filters, and results update without a full page reload, as long as everything is properly connected to Archive Loop or an active Loop Builder layout.

When not to start with this plugin

If your site consists of five static pages, a couple of blog categories, and a simple contact form, Divi Machine will probably be overkill. Native Divi and WordPress features are more than enough for standard landing pages, blogs, informational pages, and simple templates. The plugin shines when you have repeatable objects, cards, fields, filters, and separate output logic.

It may also be a poor fit for teams that are not prepared to maintain a data structure. A catalog is not just a plugin install. Someone still has to keep values consistent, avoid creating near-duplicate taxonomies, fill required fields carefully, handle empty states, and think about performance. If you want something you can "turn on once and forget," a narrower ready-made plugin built for a specific use case may be a better choice, such as a real estate plugin, an events plugin, or a jobs plugin.

What to prepare before installation

Preparation matters more than it seems. Divi Machine sits at the intersection of WordPress, Divi, custom fields, taxonomies, archives, and filtering. A mistake in any one layer can look like "the plugin is not displaying data," even when the real cause is an empty field, an incorrect slug, the wrong field source, a conflicting filter, or the wrong Archive Loop target.

Start with the technical baseline. You need WordPress administrator access, an up-to-date WordPress installation, Divi installed, and the plugin ZIP file from your Divi Engine account. The documentation also lists a custom fields plugin as a requirement: Advanced Custom Fields, Advanced Custom Fields Pro, or Secure Custom Fields. Other supported field stacks can also work in a real project if the specific Divi Machine module can read them, but the easiest first launch is with a familiar WordPress + Divi + ACF setup.

Check for a Divi Ajax Filter conflict separately. The official documentation warns that Divi Machine includes the Divi Ajax Filter codebase. If Divi Ajax Filter is already installed as a standalone plugin, it needs to be deactivated before you start using Divi Machine, otherwise you can run into module conflicts and broken filter behavior. This is not a cosmetic recommendation. It is a practical preflight check before you start building an archive.

A minimal data map before building the first archive

For a car catalog, the structure might look like this: a separate post type called "Cars," taxonomies called "Make" and "Body Type," numeric fields such as "Price," "Mileage," "Doors," and "Seats," plus an image field, a gallery field, and a text description. For a specialist directory: a post type called "Experts," taxonomies such as "Specialization" and "City," and fields like "Experience," "Consultation format," "Phone," "Email," and "Profile photo." For events: a post type called "Events," taxonomies such as "Location" and "Topic," and fields like "Event date," "Venue," "Speaker," and "Registration link."

Taxonomies are generally better for grouping and filtering by a limited set of values. Fields are better for specific item attributes: a number, date, link, image, repeater, map, contact detail, or file. If you make "city" a plain text field and later want a reliable city filter, you will quickly run into spelling variations and editorial mistakes. If city is a taxonomy instead, you get a consistent list of terms, counts, and predictable filters.

Pre-launch checklist

• You have a staging copy of the site or at least a recent backup before installation.
• Divi is active, and the visual builder opens without errors on a test page.
• The custom fields plugin is installed, and the fields are assigned to the correct post type.
• The catalog includes several test entries with different values, otherwise there is nothing meaningful to test in the filters.
• The standalone Divi Ajax Filter plugin is disabled if it was previously installed as a separate product.
• Your hosting environment has enough memory and execution time for heavier pages with filters, galleries, and maps.

Practical check: before configuring filters, open a single entry of the target type and make sure the fields you plan to display in cards are actually filled in inside the admin panel. Empty data cannot be "fixed" by tweaking the output module.

Installation and initial verification in WordPress

Installing Divi Machine follows the standard workflow for a commercial WordPress plugin: upload the ZIP file through the admin panel, install it, activate it, and make sure the modules appear in Divi Builder. There is no need to cover purchasing, payment, or license retrieval in this guide. What matters for the setup is simpler: the plugin must be active, conflicting duplicates must be disabled, and Divi should show modules such as Archive Loop, Filter Posts, Custom Field Item, Search Posts, and related elements.

Open Plugins - Add New Plugin, choose Upload Plugin, upload the ZIP file, and click Install Now. After installation, activate the plugin. If WordPress says the archive does not contain a plugin, make sure you did not unzip it too early and that you are not trying to upload an internal file instead of the installable package. If the upload fails because of a file-size limit, the issue needs to be handled at the hosting level or through a standard installation method approved by the site administrator.

After activation, do not rush into building a complex archive. First, open a test page in Divi Builder and check whether the Divi Machine modules are present. The documentation recommends confirming that the plugin is active in the installed plugins list and that modules such as Archive Loop or Custom Field Item are available in the builder. This is an important intermediate step: if the modules did not appear, further setup is pointless.

What to check right after activation

Open a page or Theme Builder template where you can safely experiment. Add a simple Custom Field Item or Archive Loop module without changing the design yet. Your goal is to confirm that the builder loads the module interface without errors and that WordPress does not throw a fatal error after saving. Then check the front end in a separate tab. If the page opens normally, you can move on to the data layer.

If activation leads to a white screen, a fatal error, or the Visual Builder stops opening, proceed carefully: temporarily switch to a safe theme on a staging copy only, disable third-party plugins, check the PHP version, and review the error logs. Do not edit plugin files directly. If the issue repeats on a clean WordPress + Divi + Divi Machine + ACF setup, that is a valid reason to contact the developer's support team with a precise description of the environment.

The first test without filters

For the initial verification, create one test entry of the required type and fill in several fields. Then open Divi Builder and add a Custom Field Item to a simple layout. Enter the field name, choose the value source, and save the page. If the value appears on the front end, the "field - entry - module" chain is working. Only after that does it make sense to build a catalog card, because a card is made up of the same small outputs: title, image, field, button, gallery, link.

Data model: post types, fields, and taxonomies without chaos

Divi Machine works best when data is separated by meaning from the start. In WordPress, a custom post type answers the question "what objects are we storing?" A taxonomy answers "how are we grouping and filtering those objects?" A field answers "what properties does the object have?" You can blur those layers, but in most cases that only makes filters and templates harder to manage.

Imagine a course catalog. "Course" is the post type. "Subject area" and "level" are taxonomies because they are useful for filters and archive pages. "Duration," "price," "start date," "format," and "enrollment link" are fields because they are properties of a specific course. "Instructor" can be either a field or a related post type, depending on whether the instructor has their own page, photo, bio, and list of courses. The earlier you make those decisions, the fewer rebuilds you will face in Divi.

Fields that will later become filters

Not every field needs to be filterable. A field like "description" or "internal note" is usually displayed in the card or the single-entry template, but it does not belong in filters. On the other hand, "city," "property type," "price range," "date," "seat count," "rating," "availability," and "format" often affect how the visitor chooses. For this kind of data, decide in advance which field type and value format you will use. A number should be stored as a number, a date as a date, and a limited set of options as a select field or taxonomy, not as free text.

This is especially important for sorting. Archive Loop can sort by a range of criteria, including ACF values, but correct sorting depends on the value type. If price is stored as a string with symbols and spaces, numeric ordering may behave differently from what the editor expects. If a date is stored as arbitrary text, it is harder to use for events and upcoming entries. Reliable setup does not begin inside Archive Loop. It begins with the correct field type.

Repeaters, galleries, and relationships

Divi Machine supports scenarios where a single entry contains repeatable data, a gallery, or related entries. That is useful for more complex cards: a list of specifications, a schedule, a set of images, related specialists, similar listings, or map locations. But these elements should not be added "just in case." The more complex the entry, the more important it is to decide where that data will be displayed: in the archive card, on the single page, or only in the administrative interface.

For an archive, it is usually better to keep fields short and scannable: image, title, 2-4 key attributes, price or date, and a button. Repeaters, long descriptions, and complex relationships are better revealed on the single page. That keeps the archive faster, the cards easier to understand, and the user from drowning in detail before they even click through.

Example of a good catalog structure

• Post type: Cars or another catalog object.
• Taxonomies: make, body type, condition, location.
• Fields for the card: price, mileage, seat count, featured image.
• Fields for the single page: gallery, description, technical specifications, contact form.
• Filters: make, body type, price range, seat count, text search.

Custom Field Item: how to display field values in Divi

Custom Field Item is one of the core Divi Machine modules. Its job is to output a single custom field value in the right place within the layout. The documentation describes it as a Divi 5 module that prints a registered field with settings for source, label, prefix, suffix, visibility, empty values, links, images, numbers, video, repeaters, relationships, and other data types. In practice, it is the bridge between the admin panel, where the editor enters data, and the public Divi template.

Working with the module does not start with design. It starts with the source. The field must exist in ACF or another supported stack, be assigned to the correct object, and contain a value. Then you add Custom Field Item in Divi, specify the field name, and choose where the value should come from: the current post, user, options page, or another supported source. If the source is wrong, the module can be beautifully styled and still display nothing.

Basic field output workflow

1. Create a field or field group in ACF, Secure Custom Fields, Pods, Meta Box, or another supported tool.
2. Assign the field to the correct post type, user, taxonomy, options page, or other object.
3. Fill the field in a test entry with a real value.
4. Open the layout in Divi and add the Custom Field Item module.
5. Enter the exact field name, choose the value source, and configure the output format.
6. Save the layout and check the front end on an entry where the field is filled in.

If the value does not appear, check three things: the exact field slug, the field source, and the page context. For example, the field may be filled in on a post, but the module is placed on a normal page outside the loop. Or the field may live on an options page, but the options page source is not enabled. Or ACF may return an image as an array while the module expects a URL. These issues look similar, but they are fixed in different places.

Prefixes, suffixes, and empty values

Prefixes and suffixes are useful for units, currency, and short clarifications. For example, a price can be displayed with a currency symbol, square footage with a unit, and mileage with a label. But do not mix the value and the unit directly inside the field if that number will later be sorted or filtered. It is better to store a clean value and add the visual context at the output level.

Empty-value handling is especially important in real catalogs. Not every entry is filled out the same way right away. In Custom Field Item, you can hide the module, show custom text, or hide a related element by selector. For archive cards, it is usually better not to show an empty block at all, so the grid does not look broken. On a single page, it can sometimes be helpful to display a neat "Information is being updated" message if that genuinely helps the user.

Images, links, email, and phone

For media and links, check the return format in the field source. The documentation explicitly points out that the format in ACF and the module setting need to match: Array, URL, ID, value, or label. If a link field returns an array but the module expects a string, the result will be wrong. The same goes for images: you can choose image size, enable full-width output, set a fallback image, or make the image link to another field.

For email and phone, there are settings that turn the value into a link or button. This is an area where restraint matters. A direct email may be unnecessary in an archive card, but useful on the single page for a specialist or listing. If a field contains sensitive information, verify access rules and whether the output is truly meant to be public. Divi Machine can display the value, but the decision about whether all visitors should see that value still belongs to the site administrator.

Archive Loop and catalog cards: from entry to results grid

Archive Loop is responsible for displaying a set of entries: posts, products, projects, or custom post types. The documentation describes the module as a tool for archives and regular pages when you need a grid with pagination and dynamic updates when Filter Posts is connected. It can work with preset output options, saved layouts, query parameters, sorting, the current archive, and different loading modes.

The correct sequence is this: first make sure Archive Loop can display the right entries without filters. Then configure the card design. Only after that should you add filters. If you connect filters, search, sorting, and a complex layout all at once, it becomes much harder to tell whether the problem is in the query, the card design, the filter, or the data.

Prebuilt template or custom loop layout

Archive Loop can use prebuilt templates or a saved layout. The built-in options are convenient for a quick start because they help confirm that the entries are loading. But for a serious catalog, you will usually want a custom loop layout - a card built in Divi Library or Loop Builder with the exact modules you need: title, thumbnail, Custom Field Item, Post Meta, a View Post button, and possibly a Repeater or Gallery. That approach gives you much more control over the contents of the card.

The Custom Loop Layout documentation describes the logic clearly: you create the card layout in Divi Library, add modules for the specific post type, and then reuse that layout in Archive Loop and other places. This prevents you from copying the design manually onto every page. If the card needs to change, you update one layout and all related archives inherit the new version.

Key Archive Loop settings

Start with Post Type. For an archive template, you can use automatic detection of the current archive if that matches the purpose. On a standard page, it is usually better to select the post type explicitly so the module does not depend on context. Then define the Loop Style or Loop Layout, the number of entries, post status, sorting, and the rules for including or excluding terms.

Include/exclude settings are useful when you need to limit the initial set. For example, you may want to show only items from one category, exclude service entries, or display related content. But do not use these settings as a substitute for a solid data model. If one archive forces you to exclude dozens of terms by hand, your taxonomy structure probably needs to be reconsidered.

Sorting by an ACF field requires care. In Archive Loop, you can choose an ACF Field and a value type such as Numeric or String. For prices, ratings, sizes, and other numeric characteristics, use a numeric format. For titles, cities, and text-based values, use string sorting. The wrong sorting type often produces results that look like a bug even though the module is following the logic it was given.

Empty results and no-results layout

For a live catalog, you should always configure a "nothing found" state. Archive Loop lets you set either text or a layout for cases where there are no entries. This matters for filters: users may choose a combination that returns no matches. If they see a blank screen instead of a clear message, the site feels broken. A good no-results block should suggest resetting filters, changing criteria, or going back to the main category.

Quick summary for Archive Loop

First verify the basic output. Then connect the card layout. After that, add sorting, pagination, Load More, and filters. That sequence reduces the number of unknowns and makes it much easier to locate the cause when the result differs from what you expected.

Filters and search: how to connect Filter Posts, Search Posts, and results

Filtering is one of the main reasons users choose Divi Machine for catalog projects. The documentation describes Filter Posts as a module that lets you filter posts, products, or custom post types without a full page reload. It works together with Archive Loop or an active Loop Builder loop. That is the key point: the filter does not display the catalog by itself. It controls an existing loop block.

The setup sequence again starts with the result: first add Archive Loop or activate a Loop Builder loop and make sure it outputs the correct entries, then place Filter Posts on the same page. In the settings, choose the post type, add Filter Items, define the filter source, and choose the element format: dropdown, checkboxes, radio buttons, slider, search, range, date, or another available option. Then verify that the filter is updating the exact loop you intended.

Filter Posts: what matters most in setup

The first parameter is Filter Post Type. It needs to match the post type used in the target Archive Loop. If the loop shows Cars but the filter is configured for Posts, you will either get no results or filtering that makes no sense. If the page contains multiple loop blocks, use Target loop container and a CSS selector so the filter controls the correct area. This is especially important on more complex pages that include "related posts," "new listings," and the main catalog at the same time.

The second parameter is the update method. On change works well when there are only a few filters and the queries are lightweight: the user changes a value and the results update immediately. On button click is better for heavy catalogs, mobile interfaces, and pages with several filters: the user chooses the criteria first and then clicks the button. That reduces the number of requests and makes the behavior easier to understand.

The third parameter is filter counts. Updating the number of matching items can be useful, but on larger catalogs it may add extra load. If counts are not critical, a more conservative mode may be the better choice. If visitors really need to see how many results remain after selecting each parameter, enable it, but test the page speed carefully.

Search Posts and the results page

Search Posts is used for searching within the selected post type and chosen data sources. The documentation outlines the workflow: add the Search Posts Module, assign the correct Post Type, add a Search Item, configure Search Settings in Divi Engine - Machine Settings - Search Settings, and then create a results page in Theme Builder with Archive Loop and Custom Loop Layout. This is more than a standard search field. The search form needs to know what to search, where to search, and where to send the user.

For a car catalog, Search Posts can search by title, make, model, description, or selected fields. For a knowledge base, it can search by title, category, and key fields. For specialists, it can search by name, specialization, and city. Do not include every field in search indiscriminately. If a field contains service values, internal identifiers, or editorial notes, it can hurt relevance and surface odd matches to the user.

How not to break the user experience with filters

Filters should help people choose, not show off every possible field. For an archive with twenty entries, 2-3 criteria are usually enough. A large catalog can support more, but they should be grouped logically: type, location, price, date, and extra attributes. On mobile, a long filter sidebar often becomes awkward, so review the layout settings, button behavior, reset flow, and visibility of active parameters.

Be sure to configure Reset Button Text and a clear state after reset. The user should immediately understand that the filters have been cleared and the catalog has returned to its default set. If you enable shareable filter URLs or URL parameters, verify that another user opening the same link sees the same filtered state. This matters for real estate catalogs, events, products, and any other collections people may want to share.

Divi 5, native loop features, and the limits of Divi Machine

The Divi Machine documentation includes a dedicated comparison with Divi 5 capabilities. The point of that comparison is useful when making a decision: Divi 5 on its own is strong for regular templates, marketing pages, simple post lists, and basic dynamic content. Divi Machine becomes relevant when the project moves into catalogs, filterable archives, relationships, custom fields, repeaters, maps, modal cards, and more advanced queries.

It is a mistake to frame the choice as "Divi 5 or Divi Machine." The better question is: "Is native Divi sufficient for this specific data structure?" If you only need to display a blog, a simple project grid, or a few fields in a template, the built-in Divi tools may be enough. If you need a filterable archive, custom fields, ACF-based sorting, related entries, a search form, and multiple result states, Divi Machine becomes its own working layer on top of Divi.

When native Divi is usually enough

Native Divi is enough when you have one post type, a simple grid, very few fields, and no complex filtering. Examples include a blog with categories, a portfolio with a small number of projects, a news section, or standard service pages. In those projects, an extra plugin may create more settings than value. The fewer repeatable objects you have and the fewer selection conditions the user needs, the stronger the case for a simpler solution.

It also makes sense to start with Divi if the team has not yet figured out which data will be permanent. Sometimes a catalog looks complex at the idea stage, but after planning it turns out that only a few static sections and a form are needed. Installing a dynamic stack too early can result in an overbuilt structure that no one wants to maintain later.

When the full Divi Machine stack makes sense

The full stack is justified when the site includes several layers of selection. For example, the user is not just browsing "all items" but choosing by region, type, price, attributes, and sort order. Or the single page needs to show related entries, a gallery, a map, repeating blocks, and extra fields. In that case, what matters is not one feature but the whole chain: Custom Field Item displays the data, Archive Loop assembles the results, Filter Posts controls the output, Search Posts helps users find things, and the loop layout defines the repeatable card.

Divi Machine is also useful when editors will be adding new items regularly. On a static page, every new item requires manual layout work. In a dynamic structure, the editor adds an entry, fills in fields, selects terms, and the templates already know how to display it. That reduces design errors and makes the site more predictable.

The line between "possible" and "worth it"

Technically, Divi Machine can be used for smaller tasks too. But the real question is maintenance. Every extra layer requires understanding: where the data is stored, which module outputs it, which filter controls the loop, why cache should not break AJAX, and how editors fill in fields. If the project is small, that cost may not be worth it. If the project is growing, the time saved on templates, filters, and repeatable structure quickly outweighs the added complexity.

Rule of thumb: if an object exists on the site in dozens of instances, has repeatable fields, and needs to participate in search or filtering, Divi Machine is worth testing. If there are only one or two such objects, it is usually easier to build the page with standard Divi tools.

Advanced fields: repeaters, galleries, maps, and related entries

On a simple catalog, Divi Machine may look like a set of modules for displaying text, images, and filters. But its real value shows up in more advanced fields: repeaters, galleries, related objects, maps, oEmbed, files, buttons, user data, and conditional visibility. These features let you build more than cards. They let you build full object pages with different kinds of information.

The main rule is simple: an advanced field should answer a specific user question. A gallery matters when the object is chosen visually. A map matters when location affects the decision. A repeater matters when an entry contains a list of specifications, a schedule, stages, included items, or blocks that cannot be stored cleanly as a single text value. Related entries matter when one object should lead to another: an event to its speaker, a property to its agent, a course to its instructor, or a product to a collection.

Repeaters and tables

A repeater is useful for a set of uniform rows. For example, a course schedule might include day, topic, and time; a vehicle package might include component, condition, and comment; a real estate listing might include room, square footage, and floor; a recipe might include ingredient, amount, and note. In an archive, a repeater is almost always too much. At that stage, the user is still deciding which object to open, and a long list inside each card only slows scanning. On a single page, a repeater reveals detail and helps the user make a decision.

If you do use a repeater in a card, limit it to the 2-3 most important rows or display an aggregated value instead. For example, do not show every property amenity. Show "12 features" or 3 key labels and leave the full details for the single page. That keeps cards easy to scan without losing the underlying data.

Galleries and sliders

A gallery is useful for objects where visual comparison matters: real estate, cars, portfolios, case studies, recipes, locations, or products. But a gallery in every archive card can make the page much heavier. In most cases, it is better to show one main image in the archive and a full gallery on the single page. If you really need a slider in the archive, check the mobile view, speed, lazy loading, and behavior after AJAX filtering.

The Divi Machine changelog includes fixes for galleries, slider layouts, lightbox behavior, and carousels. That points to a practical detail: advanced visual modules should be tested after updates and again after filters are enabled. Do not stop at Visual Builder. Open the public page, apply a filter, cycle through the gallery, open the lightbox, and verify the image counter.

Maps and locations

A map is useful when distance or location affects the choice. For a car catalog, that may be the city or dealership lot; for real estate, the neighborhood; for events, the venue; for specialists, the office or service area. Before adding a map, decide what matters most: an exact point, a neighborhood, a city list, or distance-based filtering. Sometimes a "city" taxonomy and a text address already provide enough value without a heavy map layer.

If you are using ACF Map or a similar field type, check API keys, map-provider limits, consent requirements for external requests, and behavior when no key is present. Do not make the map the only way to access the address. The page should also include a text version of the location that is available to both users and search engines.

Related entries

Relationships help add depth to a catalog. An event can be related to a speaker, a car to a dealer, a property to an agent, a course to an instructor, or a knowledge-base article to a product. Archive Loop and Custom Field Item support relationship scenarios, but the relationship first needs to be stored correctly in the data. If it is stored in ACF Relationship or Post Object, make sure it is filled in on both relevant test entries and that the selected module understands the source.

Related entries are especially useful in blocks such as "Similar Listings" or "More from This Author." But they should be limited. A block of 3-6 related cards helps the user. A block of 30 turns into a second archive and starts competing with the main purpose of the page.

Practical scenario: a listing catalog with filters and a card layout

Let us go through a concrete example that can be adapted for a car catalog, specialist directory, project catalog, or events page. The goal is to create a page where the editor adds entries in the admin panel, and the visitor sees cards with filters and can open the single page for each item.

Goal

We want to build a catalog called "Objects" with cards. Each card will show an image, title, city, price, 2-3 attributes, and a button. Above the catalog, we will place filters for city, object type, and price range. On the single page, we will output expanded fields: a gallery, description, contact details, a map, or related objects if that data exists.

Preparation

Create a custom post type called Objects. Add taxonomies called City and Object Type. In ACF or another supported tool, create these fields: price as a number, area as a number, main_photo as an image, gallery as a gallery, contact_phone as a phone field, and location as either a map or a text address if the project does not use maps. Fill in at least 8-10 test entries with different values. That will give you enough variation to test filtering, sorting, and empty states.

Setup steps

1. Create a card in Divi Library or Loop Builder with an image, title, Custom Field Item for price, area, and city, and a View Post button.
2. On the catalog page, add Archive Loop and select the Objects post type.
3. Connect the saved loop layout or use a suitable card template for the first test.
4. Configure the number of entries per page, sorting, and the no-results layout.
5. Add Filter Posts to the same page and choose the same post type.
6. Create Filter Items for city, object type, and price, using taxonomies or fields as the sources.
7. Choose an update method. For testing, On button click is often easier because it makes changes easier to track.
8. Save the page, open the front end, and test filtering in a separate browser window outside builder mode.

Verifying the result

Your verification should be specific. Choose a city where you know several objects exist and make sure the catalog shows only those entries. Then add a second criterion, such as object type. If the result is empty, check whether there is actually an entry that matches both conditions at the same time. Reset the filters and confirm that the original set returns. Then open a card and check the single page: all fields should display in the correct format, images should use an appropriate size, and empty values should not leave visual gaps.

A detail people often miss

If the price or numeric filter behaves oddly, check the field type and the saved values. The number "100000" and the string "100 000 $" look similar to a person, but for sorting and range filtering they are completely different data. For filtering, store a clean number and add the currency symbol or unit in Custom Field Item through a prefix or suffix. That reduces the risk of incorrect sorting and makes future data migration easier.

Post-install settings worth reviewing separately

Once you get the first successful output, do not publish the page right away. Go through the settings that affect long-term support: search, empty values, pagination, loading behavior, mobile behavior, performance, no-results templates, and cache compatibility. Most problems in dynamic catalogs do not appear at the moment the feature is enabled. They show up later, after the site is filled with real data.

Search and search scope

If you are using Search Posts, open the Divi Machine search settings and decide which sources should be searchable. Do not turn on every field blindly. For a listing catalog, the most useful fields are usually title, description, city, type, and possibly a SKU or model. For events, it may be title, topic, speaker, and venue. For specialists, name, specialization, and city. The more precise the search scope, the fewer random matches you will get.

Pagination, Load More, and infinite loading

Archive Loop and its related filtering stack support several output approaches: standard pagination, Load More, and infinite-style loading. For a directory or catalog where users compare results, standard pagination is often easier to understand. For a visual card-based catalog, Load More may feel more natural. Infinite loading is not always the best option: it can interfere with footer access, complicate analytics, and create the feeling of an endless list with no orientation.

The Ajax Load More documentation recommends setting Post Count lower than the total number of entries so you can actually see the button in action. It is a simple but useful check. If the number of entries is below the page limit, the button will not appear, and that is not a plugin error.

Filters: On change or Apply button

On change works well for lightweight archives and one or two filters. But if a filter uses ranges, multiple checkboxes, a map, relationships, or a large dataset, it is usually better to start with On button click. The user selects the criteria and applies them in one action. That reduces the number of AJAX requests and makes the behavior more predictable on mobile devices.

Cache and dynamic pages

On sites with caching enabled, test filters as a normal visitor. Dynamic results, URL parameters, AJAX requests, and page caching can conflict if the cache saves state too aggressively. Do not disable the entire cache unless you have to. First determine which pages are genuinely dynamic, which AJAX endpoints must not be cached, whether filter parameters are preserved in the URL, and whether results change after reset. If the issue only appears when cache is enabled, configure exclusions for the catalog page or the relevant requests through your caching plugin tools.

Safe CSS enhancement for cards

Sometimes, after building a card layout, you may need to equalize block heights so the buttons do not jump around in the grid. That can be handled with a small CSS adjustment in a child theme or another safe location for custom CSS. Do not modify Divi Machine files. Before applying it, assign a class to the card or row in Divi, for example catalog-card, and scope the CSS to that area only.

.catalog-card {
  display: flex;
  flex-direction: column;
  height: 100%;
}

.catalog-card .catalog-card__action {
  margin-top: auto;
}

The verification is straightforward: open a grid with cards of different lengths, confirm that the buttons line up visually, then check the mobile version. Rollback is just as simple: remove the CSS or remove the class from the card. If your layout does not use the classes shown here, do not paste the code blindly - first assign your own classes in Divi Advanced and adjust the selectors.

Performance, SEO, and editor usability

A dynamic catalog can be fast and easy to use, but only if you avoid turning the page into an endless collection of heavy queries. Divi Machine gives you tools for output, filtering, sorting, carousels, maps, and galleries. The more of those elements you place on a single page, the more carefully you need to manage entry counts, images, cache, AJAX requests, and field structure.

Do not output everything from the entry in the archive

An archive card should help the user choose an item, not replace the single page. Show the main image, title, a couple of key attributes, and a button. Leave the long description, gallery, video, repeaters, and detailed specifications for the single template. That makes the archive faster, reduces card height, and keeps filtering easier to use.

Prepare your images

If the card shows thumbnails, use the appropriate image size rather than full-size originals. In Custom Field Item and related modules, pay attention to the Image Size setting. A large gallery in every card can slow the page down dramatically. For archives, one image or a lightweight thumbnail is usually enough. For single pages, a gallery or slider makes more sense.

SEO for archives and filters

From an SEO perspective, what matters is not just filtering itself, but which pages should actually be indexed. Primary archives and single pages should have clear titles, descriptions, and stable URLs. Filters with many combinations can generate a huge number of parameterized addresses. Do not assume every filter state should become a useful landing page. In most cases, it is more reasonable to index the main archives and important taxonomies, while using parameterized states mainly for user convenience.

For a catalog, readable term names, clean card titles, image alt text, and a solid single page all matter. Divi Machine helps output the data, but SEO quality still depends on which data you store and how you build the templates.

Editor usability

Editors should clearly understand which fields are required, which affect filters, and which are only used on the single page. Add instructions in ACF, use logical field group names, and avoid duplicates such as "city," "location," and "place" for the same purpose. If an editor fills in similar fields inconsistently, the front end will look unpredictable.

Catalog maintenance: updates, migration, and project growth

A dynamic catalog rarely stays in its first version. New fields are added, filters change, extra post types appear, editors ask for new card states, and visitors find scenarios that were not considered at launch. Because of that, Divi Machine should not be introduced as a one-time setup. It should be treated as a system that can be expanded safely.

How to add a new field without breaking the template

If you need to add a field, first decide where it will be used: only in the admin area, in the archive card, on the single page, in a filter, in sorting, or in search. These are different risk levels. A field used only on the single page is easier to add and verify. A field used in a filter requires test data, the correct field type, a clear name, proper empty-value behavior, and testing across multiple combinations.

Do not add the field everywhere at once. First create it in ACF, fill it in on several test entries, output it through Custom Field Item on a test page, and only then add it to the card or filter. This step-by-step approach makes it much easier to catch errors before they reach the public archive.

What to test after updates

After updating Divi Machine, Divi, ACF, your caching plugin, or after a major WordPress update, do not try to manually retest the entire site. Focus on the critical paths. For a catalog, that means: the initial Archive Loop output, one filter, a filter combination, reset behavior, search, Load More or pagination, the single page, the gallery, the empty state, and the mobile view. The Divi Machine changelog shows that updates often affect exactly these areas: builder loading, relationship loops, filters, carousels, galleries, lightbox behavior, sorting, cache, and custom loop layout output.

On a production site, it is best to test updates on staging first, especially if the catalog drives leads, sales, or serves as the main navigation method. A dynamic archive can look fine on the first page and still break after filtering or sorting. So do not stop at "the page opened." Test the full user flow.

Data migration and structural changes

The most painful rebuild is changing the structure after the site is already filled with content. For example, a "city" field may start as plain text and later need to become a taxonomy. Or "price" may have been stored as a string until range filtering became necessary. Or "instructor" may begin as text and later need to become its own related post type. Changes like these are possible, but they require data migration and careful verification of templates and filters.

Before a large migration, create a backup, build a test set, check how existing entries will be converted into the new values, and only then move everything over. This guide does not include risky SQL commands or bulk-edit scripts because every site's structure is different. It is safer to use standard import tools, ACF export tools, migration plugins, or a developer's help if the data already affects the public catalog.

Documentation for editors

After setup, create a short internal guide. It does not need to cover every Divi Machine feature. It should explain the exact workflow on your site: how to add an entry, which fields are required, which values should be selected from taxonomies, how to upload an image, what cannot be left blank, and how to verify the card after publishing. A good internal guide prevents more future errors than one more complex filter ever will.

If several editors are involved, agree on naming rules and units of measurement. Price, area, duration, location, date, and status should all be entered consistently. Divi Machine can only display data cleanly when the data itself does not contradict itself.

Common Divi Machine issues and how to diagnose them

Problems with Divi Machine are usually not caused by a single setting. More often, they come from the full chain: data, field source, loop, filter, cache, theme, Divi version, and third-party plugins. That is why troubleshooting should move from simple to complex. First verify that the data exists. Then check the output without filters. Only after that should you connect filters, sorting, and extra modes.

The field does not appear in the card or template

Symptom: the area for the field is empty even though the Custom Field Item module has been added and the page has been saved.

Possible causes: the field is not filled in on the current entry, the slug is incorrect, the wrong source is selected, ACF returns the value in a format that does not match the module setting, or the module is placed outside the correct loop context. Start by opening the entry in the admin panel and confirming that the value is saved. Then verify the field name and source. If the field is an image, link, or array, check the return format in both ACF and the module settings.

Fix: start with a simple text field and display it in the single template. If the text works, the issue is not the basic connection but the specific field type. For empty values, configure the module to hide itself or show fallback text so the card does not look broken.

Archive Loop shows the wrong entries

Symptom: regular blog posts appear in the catalog, the result is empty, or items from the wrong post type are displayed.

Check Post Type in Archive Loop. Archive templates can detect the current context automatically, but on a normal page it is safer to choose the required post type explicitly. Then review Include/Exclude, On Load limits, post status, and sorting. If the entries are still drafts, Archive Loop configured for published status will not show them to regular visitors.

Fix: temporarily remove all term and ACF restrictions and leave only the correct Post Type and published status. If the entries appear, add the restrictions back one by one. That will show you which setting is excluding the result.

Filters do not change the result

Symptom: the user selects a filter, but the grid stays the same, or a different block on the page updates instead.

Check that Filter Posts is on the same page as Archive Loop or the active Loop Builder loop. Filter Post Type must match the result post type. If the page has multiple loop blocks, set Target loop container with a clear CSS selector. Also verify that the standalone Divi Ajax Filter plugin is not active alongside Divi Machine.

Fix: create a temporary test page with one Archive Loop and one Filter Posts module. If the filter works there, the cause is likely the complex page structure, selectors, multiple loop blocks, or a cache conflict. If it still does not work, check the post type, filter item source, and whether any entries actually contain the required values.

Cards lose their styles after filtering

Symptom: the initial output looks fine, but after AJAX filtering the buttons, icons, images, or spacing change.

This can happen because of style conflicts, caching, lazy loading, third-party optimizers, or incorrectly applied classes in a custom loop layout. The Divi Machine changelog regularly includes fixes related to preserving styles and correctly rendering custom loop layouts after filtering, so the first thing to check is whether the plugin is up to date on a staging copy.

Fix: disable CSS/JS optimization for the catalog page, test the output without the caching plugin, and make sure classes are applied to stable elements rather than temporary builder wrapper blocks. If the issue still happens on the current version and a clean stack, prepare a concise report for support: URL, steps to reproduce, before/after screenshots, and a list of active plugins.

The number or price filter sorts incorrectly

Symptom: values are not ordered numerically, a price range returns strange results, or sorting places "100" next to "1000" in a way that does not make sense.

Check the field type and data format. If a number is stored as text with currency symbols, spaces, or units, sorting may treat it as a string. In Archive Loop, when sorting by an ACF Field, choose Numeric for numeric values. Store a clean value in the field and add the currency symbol through a prefix or suffix in the output.

Fix: normalize your test values into a single format, verify the field type, and review the sorting setting. On a live site, do not mass-edit data without a backup.

The page works in the admin area but breaks for visitors

Symptom: everything is visible in Visual Builder, but as a regular visitor the results are empty, filters do not update, or an old state is shown.

Check page cache, AJAX cache, record access permissions, private statuses, and field visibility. An administrator may see more data than a guest user. Also verify that Custom Field Item is not hiding the value through its Visibility settings.

Fix: test in a private window while logged out of WordPress. Temporarily disable cache only for the catalog page, check that the entries are published, and verify module visibility settings. If the issue disappears without cache, configure exclusions instead of disabling optimization globally.

How to verify the finished page before publishing

Before publishing the catalog, test it from three perspectives: editor, visitor, and administrator. The editor should understand how to add an entry. The visitor should be able to find an item quickly. The administrator should see that the page does not trigger errors, break cache behavior, or expose private data.

Data verification

• Create a new test entry and fill in all required fields.
• Leave one optional field empty and make sure the card does not break.
• Add an entry with an extreme numeric value, such as the highest price, and verify sorting.
• Add an entry with a different taxonomy term and verify the filter.

Front-end verification

• Open the archive while logged out of WordPress and verify the initial output.
• Apply one filter, then two filters at the same time.
• Reset the filters and confirm that the original list returns.
• Check the no-results state with a combination that has no entries.
• Open a card and verify the single template.
• Check the mobile view: filters, buttons, card width, and field readability.

Admin workflow verification

Ask an editor who was not involved in setup to add one entry using a short instruction. If they get confused, the issue may not be Divi Machine but the field structure. Rename field groups, add instructions, and remove unnecessary fields from the editor screen. A good dynamic system should be convenient not only for the visitor, but also for the person who maintains the site.

Final criterion: if you can add a new entry, see it in the archive, find it through a filter, open the single page, and safely hide empty fields, the basic setup is working.

Divi Machine FAQ

Can you use Divi Machine without ACF?

The Divi Machine documentation describes support for multiple custom field providers, including ACF, Secure Custom Fields, Pods, Meta Box, Toolset, ACPT, and other supported stacks. But for a first project, it is easier to start with ACF or Secure Custom Fields because the documentation and examples are more often built around that model. In any case, the field must be registered, filled in, and available in the correct context.

Do you need a separate Divi Ajax Filter plugin?

No, not if Divi Machine is installed. The official documentation and product page both state that Divi Ajax Filter functionality is included in Divi Machine. If the standalone Divi Ajax Filter plugin is already installed, it is recommended to disable it before launching Divi Machine to avoid conflicts.

Is the plugin suitable for Divi 5?

The current Divi Machine documentation is organized around Divi 5-first workflows and separately notes that the older Divi 4 module pages remain available for sites that have not migrated yet. For a live site, compatibility should always be tested on a staging copy, especially if you are using a pre-release or transitional Divi version, complex custom loop layouts, filters, and third-party optimization tools.

Why does the filter show no results even though entries exist?

Most often, the cause is a mismatch in post type, filter item source, target loop container, or data format. First confirm that Archive Loop displays the correct entries without any filter. Then check Filter Post Type, Target loop container, the filter source, and whether entries with the selected values actually exist.

Can you build WooCommerce filters?

The Filter Posts documentation mentions WooCommerce product filtering by price, attributes, and stock status. But each store still needs to be tested individually: the theme, cache, optimization plugins, custom attributes, and archive structure can all affect the result. For a store, always test filters on a site copy, and do not change checkout or payment flows just to improve catalog output.

What should you do if card styles change after AJAX filtering?

Check whether the plugin is up to date, disable aggressive CSS/JS optimization on the catalog page, make sure the custom loop layout uses stable classes, and confirm that the filter is controlling the correct loop. If the problem persists on a clean plugin stack, prepare a support report with the link, steps, screenshots, a list of active plugins, and a description of what changes after filtering.

Is Divi Machine a good fit for a small site?

If the site is mostly static, the plugin may be unnecessary. It is most useful when you have custom post types, fields, card templates, filters, search, relationships, and a catalog that is updated regularly. For a simple services page or a small blog, the standard capabilities of Divi and WordPress are often enough.

When Divi Machine is a strong choice

Divi Machine is worth using when a Divi site needs to function as a dynamic catalog, directory, database of listings, events, specialists, resources, or products with non-standard fields. The plugin is especially useful when you need to connect custom fields, Divi templates, archives, filters, search, sorting, and single pages without manually writing PHP templates for every entity.

Before publishing, evaluate the project honestly. If you have a clear data model, test entries, meaningful filters, a clean card layout, and a verified result while logged out of the admin area, you can move toward deployment on the live site. If the data structure is still unclear, it is better to refine the post types, fields, and taxonomies first rather than trying to compensate for chaos with module settings.

When you are ready to test the plugin on your own site, use the link on the product page to download the latest version of Divi Machine, install it on a staging copy, and repeat the basic workflow from this guide: field, card, Archive Loop, filter, and front-end verification. That sequence is safer than moving a complex catalog straight onto a live site.