DJIA BuilderWooCommerce · 4 of 4

Fast cart conditions

For simple products the runtime can keep the cart in a cookie and price it from its own product data, so adding, changing and removing items never starts WordPress. It does so only while its numbers are exactly WooCommerce's; every other cart request goes to the WooCommerce Store API with the shopper's own session.

What this does

The cart elements, the mini cart and the cart page talk to the runtime's cart API under /djia-api/v1/cart. For each shopper the runtime decides once per request whose cart it is. A fast cart lives in the djb_cart cookie (product ids and quantities, nothing personal) and is priced from the builder's product data, the same prices the shop pages show. A WooCommerce cart lives in WooCommerce's session, and every change is forwarded to the Store API.

WooCommerce stays the cart of record where it matters. The checkout page first copies the fast cart into the shopper's WooCommerce session in one Store API batch, so shipping, taxes, coupons, payment and the order are WooCommerce's own. After every copy the runtime compares WooCommerce's line amounts and fees with its own; if they differ, the fast cart switches itself off for the whole store.

When the store can use it

Condition	Why
"Fast cart" is on	Under Settings → Performance, section Loading; on by default.
Cart and checkout templates are published	Both are needed: the fast cart exists only where the runtime renders the cart and the checkout.
Taxes are off in WooCommerce	WooCommerce calculates taxes with its own rates and rounding.
No other code on WooCommerce's cart hooks	A plugin, theme, must-use plugin or PHP snippet with a callback on a hook that changes prices, fees, totals, cart contents or quantity rules (such as `woocommerce_before_calculate_totals`, `woocommerce_cart_calculate_fees` or `woocommerce_add_to_cart_validation`) could change what the cart costs.
The hooks were measured	The callbacks are listed during a Store API request, once per set of active plugins, theme, WooCommerce and builder version, and separately for guests and logged-in customers. Until then that kind of visitor gets the WooCommerce cart.
No mismatch was found	After a mismatch the fast cart stays off until the WooCommerce version, its tax or shipping settings or the measured callbacks change, a week at most.

Which products and carts stay fast

A simple, purchasable product with one price; no subscription data and no variation choices.
The price on the product page is its stored price (no filter changes it) and there is one price for every visitor.
Quantities start at 1 and go up in steps of 1, and no scheduled sale date has passed since the product was last saved.
Nothing to ship (a virtual product), or shipping is off, or WooCommerce hides shipping costs until an address is entered and a logged-in shopper has no saved billing or shipping country.
At most 20 different products in one fast cart.

The shopper moves to the WooCommerce cart, with the fast cart copied there whole, on: adding a product outside these rules (variable, grouped, a bundle, a subscription) or a 21st product; a coupon; the shipping calculator or an address change; choosing a shipping rate. The djb_cart cookie is then deleted. When a WooCommerce cart changed elsewhere, through a plain ?add-to-cart= link, a page WordPress renders or another plugin, the runtime notices WooCommerce's cart hash and takes WooCommerce's cart. Once that cart is empty, the next product can start a fast cart again.

When nothing needs shipping and taxes are off, the checkout itself can stay local: the address goes with the order and Place order is one Store API batch. WordPress still refuses an order whose total is not the one the shopper saw.

Steps

Check the switch and the templates.
Open DJIA Builder → Settings → Performance and confirm Fast cart is on. Publish a Cart and a Checkout template.
Let the hooks be measured.
Add a product to the cart once as a guest and once logged in. Each first request uses the WooCommerce cart and lists the callbacks while it runs.
Read what blocks it.
The result is the option djb_fast_cart_guard: guest and user say what was measured, blockers lists each callback as "hook: origin (callback)".
terminal
```
wp option get djb_fast_cart_guard --format=json
```
Test as a shopper.
In a private window add a simple product: the browser now has a djb_cart cookie. Add a variable product: djb_cart disappears and WooCommerce's cart cookies take over.
Turn it off if you prefer.
Switch Fast cart off and click Save changes. Every cart is then WooCommerce's.

What you should see

djb_cart cookiepresent while the shopper's cart is a fast cart
Cart API answersX-Djia-Runtime: PRIVATE and Cache-Control: private, no-store, max-age=0 in both modes
PHP error log"DJIA Builder fast cart switched off: …" with the product and both amounts when WooCommerce disagreed

Limits

The fast cart never shows an amount WooCommerce would not show; when it cannot be exact, the shopper simply gets the WooCommerce cart.
Any store with taxes enabled uses the WooCommerce cart for everyone.
A blocking callback blocks the whole store, even if it only touches products the fast cart never takes. Developers can remove such entries with the filter djb_fast_cart_blockers; the hooks are measured again after a plugin or theme change, an update or a saved PHP snippet.

If it doesn't work

No djb_cart cookie ever appears. Go through the store table: both templates published, taxes off, blockers empty, the visitor kind measured. Then check the product: simple, one price, quantity step 1, nothing to ship before an address is known.
It worked and stopped. Look for "DJIA Builder fast cart switched off" in the PHP error log: a plugin or setting made WooCommerce price the same items differently. Fix the cause; the fast cart returns when the setup it depends on changes, or after a week.
The total grows at checkout. Expected: once the address is known, WooCommerce adds shipping, and coupons and fees are WooCommerce's own.

Last verified 2026-10-20 · tested with DJIA Builder 1.0.20.15
To confirm Verified against the plugin code; run the steps on a test site before launch