Custom Fields

Every catalogue eventually outgrows name-price-description. A bookshop needs an ISBN, an electronics store needs wattage, a gift shop needs an engraving line at the point of sale. Solidshop answers all of these with Joomla’s own Custom Fields — the same system you may already use on articles — wired into four places a shop needs them:

  • Products — specifications shown on the product page, in structured data, in search and in CSV.
  • Checkout — order-level questions: a gift message, a delivery slot, a PO number.
  • Addresses — a VAT number, a buzzer code, on the shipping side, the billing side, or both.
  • Order lines — per-item input asked on the product page: an engraving, a recipient’s name.

Because the engine is Joomla’s, everything about a field’s behaviour comes from Joomla itself: all 19 field types, required and regex validation, per-field view levels, field groups, ordering and language assignment. Nothing about your fields lives in a Solidshop-only format. Solidshop adds exactly one thing to the field edit screen — a Solidshop tab that decides where in the shop the field appears.

Defining a field

Go to Solidshop › Custom fields (or Field groups to organise them). These open Joomla’s standard Custom Fields screens; the selector at the top switches between the five Solidshop contexts — Product, Category, Address, Order and Order line — which is what determines where a field belongs. Type, label, default value, required, validation, access level and grouping all work exactly as they do for article fields.

The Solidshop tab on each field then controls shop placement, and its options differ per context — they are covered section by section below.

Product fields

Product field values are edited on the product itself: the product edit screen grows one tab per field group. Values save and roll back with the product, and variants share their parent product’s fields. Where a value then goes is up to three switches on the field’s Solidshop tab:

  • Show in Specifications tab — renders the field on the product page in a Specifications tab, grouped the way you grouped it in the admin. Fields with no value are skipped, and the tab hides itself when a product has nothing to show.
  • Include in structured data — adds the field to the product’s Schema.org JSON-LD as an additionalProperty, so search engines and AI answer engines can read your specifications. Best for factual attributes: material, capacity, dimensions.
  • Include in CSV export — gives the field its own column in the product CSV, named Field: {name}. Import reads the same column back, and a blank cell leaves the stored value alone — a price-only file never wipes a field. See Import & export.

Two more surfaces come from Joomla options rather than switches:

  • Smart Search — the per-field Search index option (on the field’s Options tab) indexes the value into Joomla’s site-wide search, exposes it as a search facet, or both.
  • Inline placeholders — and render a field’s value inside a product description, exactly as in articles. This works because product descriptions now pass through Joomla’s content plugins; if your descriptions contain literal {…} braces a plugin would consume, turn off Options › Run content plugins on product descriptions.

Checkout fields

Fields in the Order context are your point-of-sale questions. With Ask at checkout enabled, they render in an Additional information panel on the checkout page. Required and pattern rules come from the field definition and are enforced on the server, before the order is created — a rejected value never becomes an order.

Turn Ask at checkout off for a field you only want to fill in yourself: it stays available on the admin order screen as an internal field. Two further switches control display: Show on the order (order screen, the customer’s order detail page and the invoice) and Show in order emails (the confirmation and other order emails). The value is always stored on the order either way — these only control display.

Staff can edit captured values from the order screen, with the same validation the shopper’s form used; every change is recorded on the order timeline.

Address fields

Fields in the Address context appear on every address block: the customer’s address book, the admin customer screen and both checkout address forms — for guests and logged-in customers alike. The Ask on option restricts a field to the shipping side, the billing side, or asks it on both, so nobody types a VAT number twice.

One permission to know about — values entered at checkout are frozen onto the order and need nothing. But values on a customer’s saved address are stored live, so for customers to fill those in from their own address book, grant their user group the Edit Custom Field Value permission — exactly the rule Joomla applies to user profile fields.

Order line fields

Fields in the Order line context are asked on the product page, once per item, before it goes in the cart — an engraving, a recipient’s name, a delivery date. Use the field’s standard Category assignment to decide which products ask for it; there is no Solidshop-specific targeting to maintain.

Two of the same product with different answers stay two separate cart lines, so both get made as asked; two with identical answers merge and bump the quantity, exactly as an item with no fields does. Shoppers can edit what they entered straight from the cart, without removing and re-adding the item.

Three switches control display: Show in the cart (next to the item in the cart, mini-cart and checkout summary), Show on the order, and Show in order emails — the confirmation email and the shipment email both list line values under each item, so the person packing the box sees the engraving too.

Frozen onto the order

Everything a buyer enters — checkout fields, address fields, line fields — is snapshotted onto the order at the moment it is placed, labels and all. Rename a field, change its type, or delete it outright: every order placed before the change still renders exactly as it was placed. An order never depends on a field definition that may no longer exist. (Product field values are the opposite, deliberately: they are live data, shared by every page that shows the product.)

Field types at checkout

Buyer-facing contexts render only the types that are safe to put in front of an anonymous visitor: text, textarea, list, radio, checkboxes, calendar, integer, number, URL and colour. Admin-trust types (editor, media, SQL, user, subform) can be defined but are never displayed at checkout. There is no buyer file upload — a deliberate decision, not a gap.

What is not built (yet)

  • Product listings cannot be filtered or sorted by a custom field value — Smart Search facets cover narrowing inside search results.
  • Variants share their product’s fields; there are no variant-level fields.
  • Category fields are editable in the admin but not yet displayed on the storefront.
  • Field values have no per-language axis — for a multilingual attribute, create a per-language field definition, which is Joomla’s own answer.
  • An order-line field cannot change the item’s price — use product options for priced choices.
  • Order-line fields print on the order and in emails, but not on invoice PDFs.