Catalog index, types and relations

What the denormalised catalog index holds and whether the storefront is actually reading it. in_use false with built true is normal, not broken: in the default auto mode the index is only joined when a sale, a price list or a search term needs it, so a store running no promotions answers its listings with live queries on purpose. Read this before rebuilding, and read pending to see how many products are waiting for the next background tick. A store that sells in more than one currency also gets a currencies object: state is ready, off, unbuilt or missing, missing lists the currencies added since the last full rebuild (shoppers in those cannot sort or filter by price until one is run), and rows counts the prices the index holds across every extra currency.

Rebuild the denormalised index every listing, facet count, sort and search reads. Without full it drains only the products already marked dirty, which is what you want after saving a sale and not wanting to wait for the next background tick. With full it throws the index away and rebuilds it from the catalog — the right call after a bulk import that wrote products around the API, or after restoring a database. Chunked and resumable; complete false means the catalog is larger than one call can walk and bin/plugin kahunacart index --rebuild should finish it.

The merchant's own search vocabulary: each row is a word shoppers type and the words it should also find. Expansion is one-way and applied at query time, so a row saying jumper finds sweater does not also make a search for sweater find jumpers — add that row too if you want it — and a new row takes effect on the next search rather than after a catalog rebuild.

Replace the whole synonym table with the rows you send. A whole-table write rather than per-row edits, because that is what the screen is: omitting a row deletes it. Terms and synonyms are folded the same way the search index folds product text, so case, accents and punctuation do not matter. Validated before anything is written, so one bad row leaves the merchant's table exactly as it was.

Every kind of thing this store can sell: the four core types (physical, digital, grouped, external) plus any an installed add-on registers. Each carries what the cart does with it — whether it ships, whether it holds stock, whether it can be bought on its own, and whether adding it adds itself or its declared children — plus the extra product fields the type asks for and how many products currently wear it. A type with registered: false is one whose plugin is switched off: its products are still in the catalog and still editable, and they are refused at the cart door until it comes back. Call this before setting a product's type_code, because a code no type declares is refused.

List the products a merchant hand-picked to sit beside this one, in the order they picked them, split into the three kinds: related ("you might also like"), cross_sell ("goes well with this") and up_sell ("consider this instead"). Nothing here is derived from categories or tags — an empty list means nobody has curated one.

Replace one product's curated lists. Send each kind as a list of product ids in the order they should render; a kind you leave out is left exactly as it was, and a kind you send as an empty list is cleared. Ids naming no product are dropped, and the answer says what was actually stored. This replaces rather than appends — send the whole list.

Orphan every cached relation block in the store and delete relation rows pointing at products that no longer exist. Cached blocks hold product ids only, never prices, so this is about which products appear rather than what they cost. Use it after bulk changes to the catalogue.