Product tables and order forms Pro

A saved view is a query plus a presentation: which products, which columns, whether shoppers can search, sort, page and tick multiple lines. Build it once under StoreMaster → Product tables and place it anywhere with a shortcode.

[storemaster_table view="0198a1b2-c3d4-7e5f-8a9b-0c1d2e3f4a5b"]

Choosing the products

Filter by category, tag, product type, stock and sale status, or name specific products to include or exclude.

One source is worth calling out: previously ordered. It builds the view from the signed-in customer’s own order history, which turns a table into a reorder form — the single fastest path for a repeat trade buyer. It combines with the other constraints rather than replacing them.

Columns

Image, name, SKU, price, availability, categories, tags, description, weight, dimensions, rating, lead time, a quantity box and a buy control. You choose which appear, in which order, and you can override any heading.

The price column shows the price that shopper would pay: it comes from the same pricing pipeline as the product page, so a trade customer sees their trade price in the table without you configuring anything twice.

The order form

Turn on multi-add and each row gains a checkbox and a quantity box, with a single Add selected to basket button.

Every line goes through exactly the same validation a single add-to-cart does — quantity rules, access, stock, purchasability. When a line fails:

• it is named, so the buyer knows which one and why;
• the other lines are added anyway, unchanged;
• nothing is silently adjusted. A buyer who asks for 7 of something sold in sixes is told, not quietly given 6 or 12.

Products with variations

A product with choices still to make can be shown three ways, and you pick which when you build the table.

Link to the product page is the default, and what every table did before this setting existed. The row gets a "Choose options" link instead of a buy button, because the real form and its validation live on the product page.

One row per variation gives each purchasable variation its own row — its own name, SKU, price and Add button — so a buyer who already knows the size they want adds it without leaving the table. This is usually what you want for a trade order form.

Choices in the row keeps one row per product and puts a menu in it for each thing to choose — size, colour, whatever the product varies by. Pick from the menus, type a quantity, add. This is the one to use when a product has several attributes and a row per variation would run to dozens of lines.

It works with JavaScript turned off: the menus are part of the form, and the choice is matched to a variation when you submit. If a menu is left unanswered, or the combination does not exist, that line is not added and the product is named so you know which one to go back to — the rest of the order goes through.

Two things worth knowing about the one-row-per-variation mode:

• Rows per page counts products, not rows. A page set to ten products can draw forty rows if each has four variations. The page is longer than the number suggests; it is not showing you more products than you asked for.
• A variation that cannot be bought is not given a row. If a product has no purchasable variation at all, it keeps a single row of its own and offers the link, so nothing you put in the table disappears without explanation.

Search, sort and paging

All three are plain links and a plain form, so they work with JavaScript off, they are crawlable, and a filtered table can be linked to.

Two tables on one page do not interfere: each namespaces its own query parameters.

Accessibility

A real <table> with a caption stating what it contains and how many rows, column headers scoped correctly, sortable headers announcing their direction, and a labelled checkbox per row naming its product. The buy button’s accessible name includes the product, so a screen-reader user hears "Add Trade Bracket" rather than forty buttons all called "Add".