Required Product Checkbox for WooCommerce: safe setup, failure cases, and rollback

Direct answer

To require a checkbox on selected WooCommerce products safely, render one labeled field inside the native product form and validate it again on the server through WooCommerce's add-to-cart validation path.

The browser's required attribute improves the experience, but it is not sufficient enforcement. The server must verify that the checkbox came from StoreFixKit's form for the exact product being added.

Required Product Checkbox for WooCommerce follows that boundary. Free enables one statement on explicitly selected products. Pro adds bounded category rules, wording versions, and a read-only report for one order at a time. It is not legal advice, a signature service, identity proof, or consent certification.

Browser validation alone is not enough

A visitor can submit a custom request, disable JavaScript, alter HTML, use a different add-to-cart button, or call another frontend. A checkbox that looks required in the browser may still be absent from the server request.

Public support reports show this visible failure. In one case a merchant needed a mandatory disclaimer on only two products and WooCommerce support confirmed there was no product-specific core checkbox. Other merchants reported that products could still be added with the checkbox unchecked until a custom theme button selector was supplied or that an age-confirmation field marked required still allowed the product into the cart.

These reports do not prove every plugin is broken. They expose a design problem: visual presence, browser validation, server validation, and form ownership are separate responsibilities.

Bind the confirmation to one exact product form

The official WooCommerce WC_Form_Handler source shows that add-to-cart requests pass through WooCommerce's server-side form handling. A focused helper can add one validation step without replacing the handler.

The rendered native form should contain:

• one labeled checkbox;
• a hidden marker containing the exact product ID;
• a nonce bound to that product;
• the normal WooCommerce Add to cart controls.

The server accepts the request only when all of these are true:

1. WooCommerce's previous validation already passed;
2. the product has a valid required statement;
3. StoreFixKit's field was present for that exact product;
4. the product-bound nonce is valid;
5. the checkbox value is the one expected value.

If validation fails on a supported StoreFixKit form, reject only that add-to-cart request with an actionable message. Do not empty the cart, change quantity, modify the product, or redirect checkout.

Fail passive on unsupported quick-add surfaces

A strict server rule can accidentally make a product impossible to buy if a theme, quick-add button, builder, headless Store API client, or custom form never rendered the checkbox.

The safe first-release boundary is:

This is a deliberate tradeoff. It avoids a false record and avoids trapping shoppers on a form the plugin does not own. The administrator should receive a compatibility warning during setup rather than a public storefront failure.

Do not solve unsupported surfaces with a free-form CSS selector. A selector can identify a button, but it does not establish server request semantics, product identity, variation state, or an authoritative confirmation.

Keep the statement plain and bounded

One statement up to 300 plain-text characters covers ordinary product acknowledgments such as:

• I confirm that I selected the correct size.
• I understand that this item is made to order.
• I confirm that the personalization text above is correct.

HTML, shortcodes, uploaded contracts, signatures, identity checks, geographic rules, and dynamic legal clauses turn the plugin into a form and compliance platform. They expand escaping, accessibility, storage, retention, jurisdiction, and support responsibilities.

Store the exact accepted words with the order item. If the merchant changes the statement later, an old order should still show what that shopper saw, not the newest product setting.

Record only what the store can prove

A valid supported submission can record:

• the exact bounded statement;
• a deterministic version derived from those words;
• a UTC acceptance timestamp;
• the existing order item that resulted from the purchase.

That record proves only that StoreFixKit's supported server path received the expected field and token at that time. It does not prove:

• the shopper read or understood the words;
• the shopper's real-world identity;
• a handwritten or electronic signature;
• legal sufficiency in a jurisdiction;
• informed consent;
• that a contract is enforceable;
• that an unsupported sales channel collected the same confirmation.

Do not market the plugin as a universal legal-compliance solution.

Category rules need an explainable precedence

Free supplies the complete per-product rule. Pro can reduce repeated setup with one bounded category layer and an individual override.

Use a fixed order:

1. Disable for this product turns the category rule off.
2. Require this product rule uses the product's own valid Free statement.
3. Inherit uses the product rule when valid, then the matching category rule.
4. No valid product or category statement means no StoreFixKit checkbox.

Limit the category selection to 50 categories. Resolve against the current product; do not scan or rewrite every matching product.

The official WooCommerce marketplace demonstrates willingness to pay for broader field systems through Product Add-Ons. That does not require rebuilding a general form builder. A focused checkbox can win by making one product-specific result easier to understand and safer to test.

Preserve the confirmation through cart and order

After server validation passes, keep the bounded record in the current cart item. Show the exact statement through native cart and checkout item-data surfaces. When WooCommerce creates the order line item, copy the statement, version, and timestamp into plugin-owned order-item metadata.

Do not store:

• IP addresses merely for this checkbox;
• browser fingerprints;
• payment details;
• uploaded identity documents;
• signatures;
• customer messages;
• remote notarization payloads.

The Pro order report should read one authorized order at a time. It should not bulk scan orders or export customer confirmation data by default.

Test the rejection and the off path

Then compare price, stock, variation, quantity, cart totals, coupons, shipping, tax, checkout fields, payment, order status, and customer permissions before and after. A one-checkbox plugin should not change any of them.

Security boundary

Product settings require permission to edit that exact product and a product-bound nonce. Pro category settings require WooCommerce-management permission, an active product-bound license, and a separate nonce.

On the public form:

• sanitize input;
• verify the exact product marker;
• verify the product-bound nonce;
• accept one expected checkbox value;
• escape all displayed statements;
• never trust browser required as server proof.

Reject malformed enabled rules during setup instead of publishing an empty required checkbox. If WooCommerce or the current product is unavailable, register no field or cart mutation and produce no fatal error.

Resource and rollback boundary

The supported path needs one bounded product-meta read when rendering or validating an applicable product, one small conditional stylesheet on product pages, and one small cart or order-item value after acceptance.

It needs no custom table, cron, product scan, telemetry, customer cookie, public remote request, signature provider, or sitewide JavaScript.

Deactivation immediately removes StoreFixKit rendering and validation. Rollback should preserve product settings and historical order-item records while changing no WooCommerce product or commerce data. Uninstall may remove current plugin-owned product rules, but historical order statements should remain unless the merchant deliberately chooses a separate retention policy.

The Required Product Checkbox documentation includes real screenshots, exact setup, unsupported-surface behavior, troubleshooting, rollback, uninstall ownership, and safe support evidence.

Beginner launch checklist

Choose one test product

Use a disposable simple product first. Record price, stock, quantity controls, cart behavior, and checkout before enabling the rule.

Write one short statement

Use plain language a shopper can understand. Ask qualified counsel about legal wording when the use case has legal consequences; the plugin cannot supply that advice.

Test unchecked and checked submissions

Use the real native product page on desktop and mobile. Confirm the exact rejection and successful cart item data.

Test every alternative buying surface

Check quick add, related products, product blocks, builders, headless clients, and custom buttons actually used by the store. Document which surfaces are supported and confirm unsupported ones do not create false records.

Complete one disposable order

Verify the exact statement, version, and timestamp on the order item and in the Pro per-order report. Remove customer details from screenshots.

Test deactivation and rollback

Deactivate Pro, deactivate Free, test the known baseline package, then return to the current version. Product and commerce truth should remain unchanged.

FAQ

Is the HTML required attribute enough?

No. It helps the browser experience, but the server must validate the checkbox, exact product marker, and product-bound token.

Why can an unsupported quick-add still add the product?

Because StoreFixKit did not render a field the shopper could confirm on that surface. The plugin fails passive and records no confirmation instead of trapping the shopper.

Does the recorded checkbox prove legal consent?

No. It records the exact statement received through the supported plugin form. It does not prove identity, understanding, legal sufficiency, or enforceability.

Can one rule cover a category?

Pro can apply one bounded statement to up to 50 selected categories with an explicit per-product inherit, require, or disable override.

What happens when Pro expires?

Every valid Free per-product rule continues locally. Category rules and the Pro order report require an active product-bound license.