Divi BodyCommerce - WordPress Plugin

A Practical Guide to Setting Up Divi BodyCommerce for a WooCommerce Store

Divi BodyCommerce is not just for "dressing up" a couple of WooCommerce buttons. Its real purpose is to build a controlled shopping flow inside Divi: the product page, store archive, filters, cart, checkout, account area, emails, and additional features like wishlists, product comparison, and order bumps. In this guide, we will look at how to approach the plugin as a serious store-building tool rather than a random collection of modules.

This guide is written for site owners, Divi developers, and WooCommerce store managers who already understand the basics of WordPress but want to safely introduce more flexible store pages. It does not cover buying the plugin, activating a license, or bypassing limitations. The focus here is on installing an existing ZIP package, preparing the site, configuring features, building a practical workflow, troubleshooting issues, and deciding when the plugin is actually the right fit.

Special attention is given to the areas where problems happen most often: conflicts with Divi Ajax Filter, mixing default WooCommerce pages with custom templates, Ajax add to cart with non-standard product types, filters combined with caching, load more behavior, block-based cart and checkout pages, and visual compatibility with the theme and caching plugins.

What Problem the Plugin Solves in a Divi and WooCommerce Setup

Standard WooCommerce provides a solid foundation: products, cart, checkout, account pages, emails, order statuses, and system pages. Divi adds visual building and styling, but the store often ends up partly native WooCommerce, partly built in Divi, and partly patched together with separate plugins. Divi BodyCommerce is designed to close that gap. It adds modules, modifications, and settings that let you manage key WooCommerce areas inside the Divi environment.

Based on the official product page and feature list, Divi BodyCommerce covers several major groups of functionality: product pages, archives and categories, Ajax filtering, custom loop templates, galleries, variation swatches, cart, checkout, mini cart, custom checkout fields, WooCommerce emails, account pages, login, wishlist, product compare, product badges, search results, and transient caching to speed up filtering. That does not mean you should enable everything at once. On the contrary, the safest approach is to enable features along the actual purchase flow and test each one on a real product.

The plugin is especially useful when the store is built around Divi’s design system and the default WooCommerce pages feel out of place. For example, a brand may already have polished product pages, category layouts, trust elements, and a consistent visual language, while checkout, account pages, and emails still look like the default template. In that situation, BodyCommerce does more than just change colors. It helps bring the store into a single design system.

At the same time, Divi BodyCommerce does not replace WooCommerce logic. It does not take over payments, shipping, taxes, inventory, email notifications, or product structure. Those parts need to be configured in WooCommerce first, and only then should you layer visual and functional improvements on top. If the core WooCommerce pages are not assigned, product attributes are inconsistent, payments have not been tested, or themes and plugins are conflicting, BodyCommerce will not automatically "fix" the store.

Where the Product Delivers the Most Practical Value

The first major strength is the product page. Using product page modules, you can build a layout with a gallery, featured image, price, rating, tabs, related products, upsells, cross-sells, breadcrumbs, stock status, add to cart, and other blocks. This matters for stores where the default product page does not explain the product well enough: clothing with variations, electronics with specifications, cosmetics with usage instructions, digital products with license terms, or bundled products with recommendations.

The second area is archives, categories, and search. A store with a few dozen products can survive without advanced filtering, but a large catalog quickly runs into navigation problems. Divi BodyCommerce uses Ajax Filter capabilities for filtering by categories, attributes, price, stock status, and custom fields, along with list/grid switching, sorting, and custom loop layouts. The result is not just a storefront, but a controllable catalog.

The third area is checkout and the post-purchase flow. The plugin lets you work with custom checkout layouts, multiple checkout styles, order bumps, custom checkout fields, thank you pages, email templates, and account pages. This is where mistakes become more expensive: every change should be tested with a sample order, test payment mode, emails, mobile layout, and required field behavior.

Who Divi BodyCommerce Is For, and Who May Be Better Off Taking Another Route

The plugin is a good fit for sites where Divi is the main interface-building tool. If the store is already built on Divi Theme or Divi Builder and the team is comfortable working inside Visual Builder, BodyCommerce brings store-specific blocks into that familiar environment. That reduces the need for manual CSS and helps a designer or Divi developer make WooCommerce pages feel consistent more quickly.

It also works well for agencies that build Divi stores regularly. The same tasks tend to repeat across projects: displaying products in a custom loop, setting up attribute-based filtering, changing the mini cart, making checkout better match the brand, adding wishlist or compare, styling emails, and improving the account area. Instead of relying on a stack of separate extensions, you can keep one larger tool. But that requires discipline: document the features you enable and avoid turning each site into an experimental build.

Divi BodyCommerce may not be the right choice if the store does not use Divi as its primary theme, or if the project is built on a block-based WooCommerce theme and the team wants to use Site Editor and WooCommerce Blocks without Divi. It is also not the best choice if you only need one small feature, such as a wishlist or a mini cart, and the rest of the site has no dependency on Divi. In that case, a focused plugin may be easier to maintain.

Stores with heavy custom product types also deserve extra evaluation: composite products, product add-ons, complex subscriptions, bookings, B2B pricing, multi-currency setups, and role-based pricing. The official FAQ notes that Ajax Add-to-Cart is tested with core WooCommerce product types, subscriptions, and bundles, while other product types may behave differently. That means before enabling Ajax add to cart on a live site, test your specific product types, not just a simple product.

Quick Decision Matrix

What to Check Before Installation and Initial Activation

Before installing the plugin, do not start with design. First, make sure the store works as a normal WooCommerce site. WooCommerce should have separate Cart, Checkout, and My Account pages assigned, because the official WooCommerce documentation warns about problems when those roles are assigned to the same page. The shop, cart, checkout, and account pages should all open correctly without custom BodyCommerce templates. If the base flow is broken, customization will only make troubleshooting harder.

The second step is dependency readiness for Divi and WooCommerce. Divi Engine’s official documentation lists WordPress, Divi Theme, Divi BodyCommerce, and WooCommerce as required prerequisites. In practice, that means updating core, theme, WooCommerce, and related extensions in a safe order, making a backup, and testing on a staging site. Do not install a major store plugin for the first time directly on a live checkout.

The third step is the Divi Ajax Filter conflict. Divi Engine’s installation docs explicitly state that Divi BodyCommerce includes the Divi Ajax Filter codebase, so if Divi Ajax Filter is already active, it should be disabled to avoid conflicts. This is one of the most important preparation steps. If you use the standalone Divi Ajax Filter elsewhere on the site, make a list in advance of which filters and loop layouts need to be migrated or retested after disabling the separate plugin.

The fourth step is reviewing active store extensions. Pay especially close attention to plugins that affect product pages, variations, cart, checkout, order fields, discounts, multi-currency, subscriptions, bundles, product add-ons, quick view, wishlist, and caching. You do not need to disable everything up front, but you do need to understand where conflicts may appear. A good practice is to enable BodyCommerce on a copy of the site and then test features one by one.

Pre-installation mini check: open a simple product, a variable product, a category page, the cart, checkout, My Account, and an order email. Save screenshots or notes so you can compare what actually changed after enabling BodyCommerce.

Minimal Risk Map

• If Divi Ajax Filter is already installed on the site, disable it before testing BodyCommerce and recheck all filtered pages.
• If checkout contains third-party fields, test them first without a custom checkout layout, then apply BodyCommerce styling.
• If the store uses variable products, test swatches, the gallery, and Ajax add to cart on a product with real attributes.
• If page caching is enabled, exclude cart, checkout, account pages, and dynamic Ajax areas according to your caching plugin’s rules.
• If the store is multilingual, test filters, URL parameters, result counts, emails, and custom text separately.

Installing with Minimal Risk and Running the First Check

Installation in WordPress is technically standard: upload the ZIP package through the admin panel under Plugins -> Add New -> Upload Plugin, then install and activate it. This matches both the general WordPress documentation on plugin management and Divi Engine’s installation documentation for BodyCommerce. If your server does not allow archive uploads through the admin panel, use your hosting provider’s normal safe deployment process, but do not modify WordPress core, WooCommerce, Divi, or the plugin files themselves.

After activation, do not turn on every mode right away. First, open the admin area and confirm that the BodyCommerce menu is available and that the site is not showing fatal errors. Then walk through a short customer flow: shop page, simple product, add to cart, cart, checkout, My Account. At this stage, the goal is not a finished design. The goal is to confirm that the plugin is active, the basic WooCommerce flow is still intact, and there are no conflicts severe enough to break the site.

If you are working on a staging site, add a sample variable product along with several categories and attributes. For BodyCommerce, this is more useful than testing with a single simple product. Ajax filters, swatches, galleries, compare, and order bumps only show their real behavior when the data resembles an actual catalog.

Initial Validation Order

1. Check that the default WooCommerce pages are assigned and do not duplicate each other.
2. Make sure the standalone Divi Ajax Filter is disabled, if it was active.
3. Activate Divi BodyCommerce and open the public site in incognito mode.
4. Test a simple product, a variable product, a category archive, and search.
5. Add a product to the cart the normal way, then test the cart and checkout.
6. Place a test order in a safe payment test mode, if one is configured.
7. Check the order email and the My Account page after the order.

Once that check is complete, you can move on to configuration. If an error appears before any specific BodyCommerce feature has been enabled, record it separately. It may be tied to the base WooCommerce setup or another extension.

Post-Install Setup: From Core Page Mapping to Divi Modules

The biggest mistake people make with Divi BodyCommerce is trying to configure the entire store as one screen full of switches. In practice, it is much easier to work through the customer journey. First assign and verify the system WooCommerce pages. Then decide which areas BodyCommerce should replace or extend. After that, configure the Divi modules, test the mobile layout, and only then enable interactive or performance-oriented features like Ajax add to cart, transient caching, and load more.

Step 1. Make Sure WooCommerce Pages Are Assigned Correctly

Open WooCommerce -> Settings -> Advanced and check the cart, checkout, account, and terms pages. Under WooCommerce -> Settings -> Products, verify the shop page. This is not a BodyCommerce setting, but without it, custom checkout, custom cart, and the account builder may behave unpredictably. If any pages are missing, WooCommerce can recreate them through WooCommerce -> Status -> Tools -> Create pages.

There is another important detail for Divi sites: do not mix multiple ways of controlling the same page. If checkout is built at the same time with the WooCommerce Checkout block, a shortcode, a custom Divi layout, and an additional checkout plugin, troubleshooting becomes difficult. Choose one primary method and test that method properly.

Step 2. Separate Global Modes from Project-Specific Modules

BodyCommerce includes both large modular features and separate modifications. Modules are used when you are building a page inside Divi: product elements, loops, breadcrumbs, galleries, sharing, related products, notices, search, and other blocks. Modes affect WooCommerce more broadly in terms of behavior or appearance: badges, form fields, cart icons, custom checkout fields, default images, shortcodes, custom CSS/JS, and similar settings.

A practical rule is this: if a feature belongs inside a specific layout, use a module; if it changes store behavior globally, look for the appropriate mode or setting. For example, product tabs on a product page can be planned as part of the product layout, while custom checkout fields affect order data and emails and therefore need stricter testing.

Step 3. Style Form Elements Without Breaking Accessibility

Styled Form Fields can bring site forms into a consistent visual style. That is useful for quantity fields, dropdowns, and checkout fields, but it is important not to lose readability, focus visibility, contrast, or error messaging. Do not just check whether a screenshot looks nice. Test keyboard behavior too: moving through fields with Tab, seeing which field is active, reading placeholders, spotting required-field errors, and recognizing disabled states.

If the focus state becomes hard to see after styling, you can add a small, safe CSS adjustment in a child theme or in the standard additional CSS field. It does not depend on internal BodyCommerce classes and works with core WooCommerce fields:

.woocommerce-checkout .input-text:focus,
.woocommerce-checkout select:focus,
.woocommerce-checkout textarea:focus {
  outline: 2px solid #7f54b3;
  outline-offset: 2px;
}

.woocommerce-checkout .woocommerce-invalid .input-text {
  border-color: #b00020;
}

After adding it, open checkout, move through the fields using only the keyboard, and intentionally leave a required field empty. If the focus outline and error state are both clear, the adjustment is doing its job. If your theme already provides strong focus styling, you do not need this CSS. Rolling it back is simple: remove the snippet from wherever you added it.

Step 4. Enable Ajax Features Only After Basic Testing

Ajax add to cart, Ajax filtering, load more, and transient caching make the site feel faster, but they also make debugging harder. First confirm that products, filters, and cart behavior work without Ajax enhancements. Then enable interactivity and run the same scenario again. If enabling Ajax causes the price to stop updating, the variation gallery to break, the mini cart counter to desync, or the layout to break after load more, you immediately know where to look.

Product Pages: Gallery, Variations, Tabs, and Purchase Confidence

The product page is the most natural place to use Divi BodyCommerce. The official feature page lists product page modules such as gallery, featured image, title, short description, price, add to cart, rating, tabs, reviews, sharing, related products, upsells, cross-sells, stock status, notices, and more. The goal is not to place every module on one page, but to support the customer’s decision process in the right order.

For a physical product, customers usually want to see images, options, price, availability, shipping details, specifications, reviews, warranty, or instructions. For a digital product, the key information is usually the description, usage terms, compatibility, support, and file access. For products with variations, swatches and a gallery that changes when a color, size, or other attribute is selected are critical. BodyCommerce lets you make those elements part of the Divi layout, but the actual content still needs to be prepared in the WooCommerce products.

How to Approach Galleries and Variations

Enhanced Product Gallery Sliders in BodyCommerce support different gallery styles and interaction with variations. This is useful when a product is sold through visual selection: clothing colors, furniture materials, image sets for cosmetics, or technical detail shots for equipment. But if a product has only one image and no variations, a complex slider may be unnecessary. In that case, a simple large gallery with more space for the description may be the better choice.

Variation Swatches replace standard dropdowns with clearer buttons, colors, images, or label-based swatches. When configuring them, check three things: is it obvious which option is selected, are unavailable options clearly shown, and do the gallery and price update after selection? If another variation plugin from a different developer is already active, do not enable two swatch systems at once. Keep one, or selection behavior may become unpredictable.

Tabs and Supporting Information

Custom Product Tabs are not meant to hide all content under tabs. They work best when they separate different types of information: description, specifications, care instructions, shipping, materials, size chart, instructions, files, or product questions. If you end up with too many tabs, start with the three most important ones and check how they work on mobile. A customer should not need to open five tabs just to find sizing details or return terms.

For products that share recurring reference information, it is better to create a common structure: a size chart tab for clothing categories, a storage conditions tab for cosmetics, or a documentation tab for a digital product. That reduces manual work and makes product pages more predictable.

Badges, Stock Status, and Social Sharing

Custom Product Badges can highlight "sale," "new," or other statuses, but badges quickly turn into visual noise. Use them only where the status genuinely helps the customer make a decision: new arrival, limited edition, discount, bestseller, or preorder. Stock status matters when availability affects the purchase decision. Social sharing makes sense for products people naturally share: gifts, visually driven products, limited collections, or educational products. For a standard B2B catalog, sharing may be secondary.

Archives, Filters, and Custom Loop Layouts

Store archives help customers find products before they ever open a product page. In BodyCommerce, this is the area of custom loop layouts, the product category builder, dynamic product sorting, Ajax product filtering, list/grid switching, pagination, and tailored search results. If the product page helps sell one product, the archive helps narrow the selection quickly. That means not only attractive cards, but sound data logic.

Before configuring filters, clean up your product attributes. A filter by "color" will not help if some products use the Color attribute, others use a custom field, and others mention color only in the description. A price filter will be useless if variations and discounts are configured inconsistently. Dynamic sorting by rating or price also depends on correct WooCommerce data.

Using a Custom Loop Layout Instead of the Default Grid

A custom loop layout lets you output product cards using Divi Library and BodyCommerce modules. That is powerful because you can decide what information belongs in the archive: image, badge, price, short description, rating, stock, add to cart, compare, wishlist, or quick product notes. Do not turn the archive into a full product page. The archive should support selection, not overload the screen.

For a clothing catalog, image, product name, price, swatch previews, and wishlist may be enough. For electronics, short specs, compare, and stock can be more useful. For digital products, category, compatibility, a short description, and a details button may matter most. There is no universal answer, which is why BodyCommerce should be configured around the catalog itself, not around a generic "nice-looking grid" template.

Ajax Filtering and Transient Caching

Ajax Product Filtering updates the product list without a full page reload. The official features section mentions filtering by categories, tags, attributes, stock status, price, and custom fields, along with settings for how empty results behave. The changelog shows that the developer regularly fixes filter edge cases involving pagination, load more, WPML/Polylang, URL parameters, sorting, loop layout styles, and pages with multiple loops. That is useful, but it also shows that filtering is a technically sensitive area.

Transient caching in BodyCommerce, Divi Ajax Filter, and Divi Machine is meant to reduce repeated database queries during filtering. It is worth considering for large catalogs or pages with heavy queries. But caching should not be enabled "just in case" if the catalog is small and filters are already fast. After enabling it, check whether results update after product changes, whether the cache can be cleared manually, and whether role-based pricing, multi-currency logic, and out-of-stock rules still behave correctly.

List/Grid Views, Sorting, and Pagination

List/Grid Switcher is useful when products can be browsed in different ways. Visual products usually work better in a grid, while a technical catalog can be easier to scan in a list. Dynamic sorting should match real user behavior: price, relevance, date, rating, and possibly ACF fields if those are used in the catalog. Test pagination, load more, and infinite scroll beyond the first page. Problems often show up on the second load, after resetting filters, or when sorting already loaded products.

Cart, Checkout, Order Bump, and Order Fields

Checkout is the riskiest area to customize because design directly affects whether the order gets completed. BodyCommerce offers custom cart modules, custom checkout pages, several checkout styles, custom checkout fields, mini cart, Ajax add to cart, and order bumps. Each of these features can be valuable, and each one needs separate validation.

Mini Cart and Ajax Add to Cart

Dynamic Mini Cart displays cart contents in a dropdown instead of forcing a visit to a separate page, and Ajax Add to Cart adds a product without a reload. For customers, that means less waiting and fewer interruptions. For the store owner, it means more dynamic states that need to be tested.

Test a simple product, a variable product, a product with quantity changes, an out-of-stock product, and a product that cannot be purchased until an option is selected. The mini cart counter should update, the subtotal should be correct, removing a product should stay in sync with the cart, and notices should not disappear. If the store uses non-standard product types or third-party product add-ons, enable Ajax add to cart carefully and keep the option to disable it for specific products if the setting allows it.

Custom Checkout Pages

The official feature set describes different checkout styles: Shopify style, multi-step, accordion, and one-page. The right choice depends not on trend, but on order complexity. A one-page checkout works well for simple stores with short forms. Multi-step layouts can help when you want to separate contact details, shipping, and payment. Accordion layouts keep everything in one flow, but they can hide errors if the sections are not clearly highlighted.

After changing the layout, always place a test order. Check required fields, shipping zones, coupons, taxes, payment methods, order creation, customer email, and admin email. If the store uses a redirect-based payment gateway, test the return to the thank you page. If legal consent checkboxes are required, make sure they did not disappear in the custom layout.

Order Bumps Without Aggressive Selling

Order Bump in BodyCommerce shows an additional offer at checkout near the payment area. According to the official description, the bump can be tied to the first product in the cart, disappear when the parent product is removed, and use product selection methods such as specific, up-sell, or cross-sell. A good bump should not get in the way of payment. It should be relevant: a watch strap for a watch, a skincare item for cosmetics, a warranty package for electronics, or an extra file for a digital product.

Test three scenarios: the product with the bump is added, the parent product is removed, and the customer changes the quantity. Make sure the discount, totals, taxes, and order email all match WooCommerce logic. If the bump creates confusion around the order total, it is better to disable it and simplify the offer first.

Custom Checkout Fields

Custom Checkout Fields let you add text fields, date fields, checkboxes, placeholders, required states, custom error messages, and display that data in the order or email. This is useful for shipping details, product personalization, B2B company information, or order comments. But every extra field increases friction. Only ask for data that is actually needed to process the order.

Check where the field is stored: in the order, in the email, in the admin panel, in exports, or in integrations. If a field is only useful to a manager, do not make it required for every customer. If it collects personal data, make sure storage is aligned with your privacy policy and avoid collecting anything unnecessary.

Account Pages, Login, Emails, and the Post-Purchase Experience

Many stores stop customizing at checkout, but the customer experience continues after the order. BodyCommerce adds My Account Builder, Custom Login Modules, Custom Password Reset Layout, Custom Thank You Pages, and Custom WooCommerce Emails. These features help make the post-purchase journey clearer and better aligned with the brand.

My Account Builder is useful when the account area needs to be more than just an order list. In a digital product store, it may include instructions, file links, renewals, or support blocks. In a B2B store, it may need quick reorders, documents, company info, or saved items. In a fashion store, it may focus on wishlist and recommendations. But do not overload the account area with marketing blocks if the user came there to check an order or download a file.

Login and Password Recovery

Custom Login Modules let you style login, registration, lost password, and reset password forms. Error messaging and accessibility are especially important here. Test an incorrect password, a non-existent email, a successful reset, signing in again, the mobile screen, and browser autofill. A visually polished login form is useless if users cannot tell why they failed to sign in.

WooCommerce Emails

Custom WooCommerce Emails make it possible to align emails with the brand, change layout, colors, fonts, and fixed content, and use preview functionality. But emails are not regular web pages. They are read in different mail clients, on phones, and sometimes in dark mode. That means the design should stay simple. The main order details, address, products, totals, and actions should always remain easy to read.

Before going live, send test emails to multiple inboxes. Check the subject line, sender, logo, text, products, buttons, account link, and display of custom checkout fields. If the layout breaks in even one client, simplify it.

Practical Example: Building a Clothing Catalog with Filters, Swatches, and Checkout

Imagine a clothing store built with Divi. The goal is to give the customer a smooth path: choose a category, filter products by size and color, open a product page, pick a variation using swatches, add the item without a page reload, see the mini cart, and complete a simplified checkout. This is a strong use case for Divi BodyCommerce because it combines the product loop, Ajax filters, variation swatches, gallery, mini cart, and checkout layout.

Goal and Preparation

The target is a "Jackets" category where customers can filter products by size, color, and availability, switch between list and grid views, and then choose a product with variations. Prepare several products with the same global WooCommerce attributes: size, color, and season. Add variation images, prices, stock status, and categories. Without that structure, filters and swatches will not show their real value.

Check that Divi, WooCommerce, and BodyCommerce are active, and that the standalone Divi Ajax Filter is disabled. Make sure the default shop, cart, checkout, and account pages are assigned. On the staging site, enable a test payment method or another safe way to place orders without real payment.

Setup Steps

1. Create or choose a Divi layout for the category archive. Add a product loop or the appropriate BodyCommerce module to display products.
2. Configure the loop card: image, title, price, sale badge, stock status, wishlist, or compare if those help with selection.
3. Add Ajax filters for category, size, color, price, or availability. Do not enable every filter at once. Start with the two most useful ones.
4. Add a list/grid switcher if the products are genuinely easier to browse in both modes. Check that the layout stays intact after switching.
5. Configure the product page: gallery, featured image, price, add to cart, stock status, tabs, related products, and variation swatches.
6. Enable the mini cart and confirm that adding a product updates the counter and subtotal without a reload.
7. Set up the checkout layout. For a simple store, start with a one-page layout or a clean multi-step flow, then add fields only when necessary.
8. Place a test order: select a variation, add the product, check the cart, checkout, email, and order record in the admin panel.

Validating the Result

On the front end, the result should be obvious: filters update products without a full reload, selected swatches change product state correctly, the gallery does not lose variation images, the mini cart stays synchronized with the cart, checkout preserves all required data, and the order email contains the correct products and totals. If transient caching is enabled, edit a product and make sure the filters do not keep showing outdated data.

Practical scenario note: if products lose styling after filtering or start repeating after load more, temporarily disable extra performance optimizations and check the changelog. Recent BodyCommerce and Ajax Filter updates include many fixes specifically around loop layouts, load more, pagination, and Divi 5 builder contexts.

Checking Performance, SEO, and Technical Stability

Divi BodyCommerce is not an SEO plugin and should not replace proper technical optimization for the store. But it does affect elements that matter for search visibility and user behavior: product card structure, archive text, filtering speed, product availability, internal navigation, breadcrumbs, related products, search results, and the checkout experience. That is why you should run not only a visual check after setup, but a technical one as well.

What to Check on the SEO Side

Make sure custom loop layouts have not removed important headings or links to product pages. Each product page should still have a readable title, price, description, attributes, availability, and reviews if those are used. Product tabs should not hide critical information so deeply that users cannot find it. Related products, upsells, and cross-sells should be relevant, not random.

If filters add URL parameters, check how your SEO plugin handles them. You do not need every filter combination indexed without a strategy. For large catalogs, it is important to decide which categories and landing pages should be visible to search engines, and which filtered states should remain purely user-facing navigation.

What to Check for Speed and Caching

Test the category page before and after enabling Ajax filters, custom loop layouts, and transient caching. Compare not only the first page load, but also filtering, reset filters, load more, sorting, and repeat visits. If the site uses Redis, Memcached, or another object cache, transient caching may help with repeated queries. If the catalog is small, the benefit may be hard to notice.

Do not cache checkout, cart, and account pages as static pages. If a caching plugin or server-side cache stores dynamic blocks too aggressively, the mini cart and checkout may show stale data. The right strategy is to exclude critical WooCommerce pages and optimize archives, images, CSS, fonts, and queries instead.

What to Check for Accessibility

Filters, swatches, the mini cart, accordion checkout, and custom fields should all be understandable without a mouse. Test keyboard navigation, focus states, contrast, error messaging, and readability on mobile. If an element looks nice but it is unclear whether it is selected, that is an interface problem. Pay especially close attention to swatches: the selected color or size should be visible not just through color, but through state, border, text, or another clear cue.

Common Problems and Troubleshooting

Problems with Divi BodyCommerce usually do not come from one switch alone. They tend to come from the interaction between WooCommerce, Divi, caching, Ajax, another store extension, and the product data itself. That means troubleshooting should be systematic: identify the symptom first, narrow down the affected area, and then disable only the likely causes.

BodyCommerce Conflicts with Divi Ajax Filter

Symptom: filters behave inconsistently, duplicate settings appear, filtered pages break, or Ajax requests return unexpected results.

Cause: the official installation documentation states that BodyCommerce includes the Divi Ajax Filter codebase, and running the standalone Divi Ajax Filter alongside BodyCommerce can cause conflicts.

What to check: the list of active plugins, filtered pages, custom loop layouts, filter settings, and the browser console.

How to fix it: disable the standalone Divi Ajax Filter on a staging site, clear cache, test the filters again, and migrate the needed settings into the BodyCommerce setup. If the site depends heavily on the separate filter in non-WooCommerce areas, map those pages first so you do not lose functionality.

Ajax Add to Cart Does Not Work for a Specific Product

Symptom: the product does not get added without a reload, the mini cart does not update, or you see a variation selection error or a third-party field error.

Cause: Ajax add to cart is best tested on core WooCommerce product types and confirmed scenarios. Complex third-party product types, product add-ons, or composite logic can change the add-to-cart flow.

What to check: a simple product, a variable product, a product with a required third-party field, and any subscription or bundle products used on the site.

How to fix it: disable Ajax add to cart for the problematic product type if the setting allows it, or temporarily return to the standard add-to-cart flow. If the problem disappears, keep the standard flow for complex products and use Ajax only where it is stable.

Product Cards Lose Styling or Products Repeat After Filtering

Symptom: after filtering, pagination, or load more, product cards look different, duplicates appear, the load more button disappears, or the wrong product set is returned.

Cause: these symptoms are often tied to the loop layout, Divi style cache, Ajax responses, sorting, pagination, or multiple loops on the same page. The BodyCommerce changelog contains many fixes in this area, so it is important to keep the plugin updated and test the exact scenario.

What to check: a page with one loop, then a page with multiple loops, filtering before and after load more, sorting after filtering, and the current cache/minification state.

How to fix it: simplify the page to a single loop, clear the Divi cache and site cache, disable JavaScript minification during troubleshooting, and check for updates. If you have an enhanced load more option or similar behavior in your setup, disable it for testing and compare the result.

Checkout Looks Fine but the Order Does Not Go Through

Symptom: the customer cannot complete the order, a required field is not visible, an error appears in a hidden step, or the payment gateway is not receiving the required data.

Cause: a custom checkout layout may hide a system field, change the order of blocks, or conflict with shipping, payment, tax, or custom checkout field extensions.

What to check: guest checkout, logged-in checkout, different shipping zones, coupons, taxes, required checkboxes, test payments, emails, and the order in the admin panel.

How to fix it: temporarily switch back to the default checkout or a simpler layout. Disable custom fields one at a time. If the problem is tied to a specific payment gateway, do not adjust checkout blindly. Check the gateway documentation and WooCommerce logs first.

Wishlist, Compare, or the Account Page Is Not Visible to the User

Symptom: the wishlist button does not appear, the compare table is empty, or the user cannot find saved products in the account area.

Cause: the feature may be enabled, but the module is not added to the right layout, the account page is missing the required block, the user is not logged in, or the button is hidden by CSS.

What to check: Wishlist/Compare settings, whether the module is present on the product page and archive, the My Account page, user state, mobile layout, and the theme’s CSS.

How to fix it: add the module to the correct layout, check permissions and the guest user scenario, clear cache, and simplify button styling. If compare is only useful for a technical catalog, do not show it on every product by default.

A Similar Option and When It May Be More Convenient

How to Manage Changes So the Store Stays Easy to Maintain

Divi BodyCommerce is rarely rolled out in a single day. Teams often start with the product page, then move on to archives, then checkout, and later add wishlist, compare, custom emails, and extra fields. If those decisions are not documented, within a few weeks nobody remembers why a certain mod was enabled, which layout controls a category, where the CSS was added, or why a specific Ajax switch should not be touched. That is risky for a store: an issue can appear after a WooCommerce, Divi, BodyCommerce, or neighboring plugin update, and the team ends up troubleshooting blindly.

The simplest maintenance system is a plain project change log. Record the date of the change, the page, the BodyCommerce feature, the related Divi layout, what was tested, and how to roll it back. There is no need to turn this into bureaucracy. A line like "Archive /shop/jackets: custom loop enabled, size/color/stock filters added, pagination and reset filters tested, rollback = restore default shop layout" is enough. This kind of log is especially useful for agencies that hand sites off to clients or maintain multiple Divi stores.

What to Record After Each Configuration Change

• The name of the area: product page, category archive, mini cart, checkout, My Account, order email, or filter.
• Which Divi layout is used and where it is assigned.
• Which BodyCommerce modules were added to the page and why they matter to the customer.
• Which global modes are enabled: swatches, badges, custom checkout fields, Ajax add to cart, transient caching, custom emails.
• Which third-party plugins affect that area: payment gateway, shipping plugin, SEO plugin, cache plugin, multilingual plugin, product add-ons.
• Which test was completed: simple product, variable product, filter, load more, coupon, shipping, order, email, mobile screen.
• How to roll the change back quickly if an issue appears after an update.

Rollback Without Panic

A rollback does not always mean removing the plugin completely. More often, it is enough to temporarily disable one mod, restore the default checkout layout, remove a custom field, turn off Ajax add to cart, or replace a custom loop with a simpler product output. That is why it helps to leave "checkpoints" during setup: duplicate layouts in Divi Library, notes on enabled settings, a list of cache exclusions, and a short description of the test order.

If a problem appears after an update, do not start by mass-disabling every plugin on the live site. First reproduce the symptom on a staging copy. Then check the BodyCommerce changelog and the changelogs of nearby extensions. After that, disable features one at a time: Ajax add to cart, transient caching, load more, custom checkout fields, a third-party checkout plugin, JavaScript optimization. This approach is slower than "turn everything off," but it gives you an answer instead of only hiding the symptom temporarily.

Documentation for the Client or the Team

If the store is being handed off to a client, do not leave them with only admin access and a plugin list. They need a short operating guide: which pages should not be edited like normal pages, where the layouts live, how to update products, how to test filters, what to do after changing attributes, and where to look when checkout breaks. It is especially important for the client to understand that changing product attributes can affect filters, and deleting a layout from Divi Library can break an archive or product page.

For the development team, it helps to add a separate "do not touch without testing" section. That usually includes the checkout layout, custom checkout fields, Ajax add to cart, transient caching, the product loop query, multilingual settings, and cache exclusions. This is not a ban on improvements. It is protection against accidental edits in areas where a mistake can immediately affect sales.

Practical takeaway: Divi BodyCommerce gives you a high level of control, so the success of the project depends not only on the initial setup, but on how clearly the enabled features, tests, and rollback path are documented.

When Divi BodyCommerce Is the Right Choice

Divi BodyCommerce is worth using if your store truly lives inside Divi and your needs go beyond a single button or a single widget. The plugin is especially strong when you need to build a complete shopping flow: a product page with swatches and gallery, an archive with filters and a custom loop, a mini cart, a checkout layout, an order bump, an account page, emails, and reliable Ajax behavior.

Do not enable everything at once. Start with one area where the customer benefit is obvious: the product page, a category archive, or checkout. Then add adjacent features and test the result. That approach works better than trying to "configure the entire plugin at once," because store logic is sensitive to data, payments, shipping, caching, and third-party extensions.

If, after reading this guide, you now understand which pages need improvement, which features you actually need, and how you will test the outcome, you can move on to the product file: download the ZIP package and test the plugin on a staging copy of the store. Before going live, save a list of enabled modules, place a test order, and keep a rollback path for every potentially risky feature.