Guide · Product editors

Product editors

Opening a product from the Catalog shows everything BigCommerce reports for it, grouped by the thing it belongs to. Four of the six tabs can write. Each one refuses certain changes, and every refusal below exists because BigCommerce would otherwise lose data or answer an error that names nothing useful.

Variants

Only the cells you actually change are sent, so an untouched field is left out of the file entirely and BigCommerce keeps whatever it has. Variants are matched by their id, which means renaming a SKU updates the right variant instead of adding one.

Also refused, before anything is sent:

• Two variants given the same SKU — BigCommerce's own error does not say which rows clashed, so the check happens here.
• A "purchasing disabled" message on a variant that stays orderable — BigCommerce only stores that message while purchasing is disabled and drops it silently otherwise.
• Nothing can be created here. Rows say UPDATE and name a variant id. A product update rejects inline variants outright — BigCommerce answers "Missing Required Fields: id" — so an update can only touch variants that already exist. Adding one needs its own call, and BigCommerce will not invent the option for it.

Options and swatches

An option can be drawn as a dropdown, radio_buttons, rectangles or a swatch. Switching between the first three is unremarkable. Switching to a swatch is not.

• Up to three colours per value, for a multi-tone chip.
• A value no variant uses cannot be styled at all, because the colour travels on a variant row.
• A product with no SKU cannot be styled either — variant rows attach to their parent by SKU.
• A swatch image is only set when the value is created. BigCommerce re-hosts it, so its URL can never be compared with yours and pushing it on every run would duplicate it. Colours are compared and updated.
• Hex is stored upper-cased by the API, but a colour set by hand in the BigCommerce admin comes back exactly as typed — so both sides are compared upper-cased, or a hand-set value would be rewritten on every run.

Image order and the thumbnail

• The whole list must be supplied. Positions are absolute, so an omitted image would end up sharing a position with whatever took its place. Leaving one out is refused, naming it.
• Positions are renumbered 1..N. The order you chose and the thumbnail are exactly what you asked for, but the absolute numbers are not preserved.
• The thumbnail can only be promoted. BigCommerce clears the flag on the previous thumbnail itself, so only "make this the thumbnail" is ever sent — asking for the opposite would leave the product with no thumbnail at all.
• The list re-reads a couple of seconds after saving. Image writes are asynchronous on BigCommerce's side; reading immediately returns the old list.
• Matching is by BigCommerce's own image id, so a reorder can never move the wrong picture — which a filename-based match sometimes would.

Metafields and custom fields

This tab submits the complete set the product should end up with, and the file expresses that as REPLACE. That shape is forced by the format rather than chosen: a file carries one command per field type, so "set these and delete those" cannot go in one file, while the whole desired set can.

• A metafield is identified by namespace + key; a duplicate pair is refused by BigCommerce, so writing one upserts.
• Two custom fields with the same name are refused. BigCommerce allows them, but only the first could ever be addressed by a column, so the second would be left behind invisibly.
• Removing the last field is a delete naming it, not an empty replace — an empty set is a no-op.

What this screen cannot do

Adding a variant, creating a modifier, adding a quantity break, adding an image and creating a product all need a CSV import — see the Products import guide. The editors here are for changing what already exists on one product.