Product Subtitle for WooCommerce: safe setup, failure cases, and rollback

Direct answer

Store one short plain-text subtitle on the product and render it as a separate escaped element immediately after WooCommerce's native product title. Do not filter or replace the product name. Use the product-summary hook on single-product pages and the post-title loop hook on shop and archive cards.

Product Subtitle for WooCommerce follows this boundary. Free adds one 160-character field and two display locations. Pro reuses the same text in cart, checkout, order details, and WooCommerce emails without creating another title system.

A subtitle is not the product title or short description

These three fields have different jobs:

Changing the product name to contain a separator and subtitle can leak promotional copy into breadcrumbs, orders, feeds, menus, and SEO output. Copying the short description below every loop title can make cards unstable and duplicate much more content than the shopper needs.

The smaller design is one separate field with one visible purpose.

Use documented WooCommerce locations

WooCommerce's current template-hook reference places the native product title at priority 5 inside woocommerce_single_product_summary; price, rating, excerpt, metadata, and sharing use their own priorities. The WooCommerce template-hook reference documents that order.

For product loops, WooCommerce's content-product template calls woocommerce_shop_loop_item_title and then woocommerce_after_shop_loop_item_title. A subtitle can therefore remain independent from the title while still occupying a predictable native location.

This ownership split matters:

• WooCommerce keeps the product name and template flow.
• The theme keeps typography and layout.
• The subtitle plugin owns one escaped paragraph and its one product value.
• An SEO plugin keeps SEO titles and schema.

Deactivating the subtitle plugin should remove only that paragraph.

Store a bounded field, not arbitrary markup

WordPress supports registered metadata with explicit type, sanitization, authorization, and REST exposure. The register_meta() reference documents sanitize_callback, auth_callback, single, type, and show_in_rest.

For a beginner-facing product subtitle:

1. Register one string only for the product post type.
2. Limit it to 160 characters.
3. Strip HTML and shortcodes.
4. Authorize against the exact product ID, not only a broad editor role.
5. Validate before overwriting the last valid value.
6. Escape again at output.

The WordPress Plugin Handbook summarizes the same security sequence as sanitize, validate, and escape in its common plugin issues guide.

Support both familiar product editors without hiding the first step

The classic WooCommerce editor still presents product fields inside Product data. WooCommerce 8.9 also expanded custom-field support in the new product editor, as described in the WooCommerce 8.9 release notes.

A subtitle feature fails its beginner promise when users cannot find its first field. The safe implementation exposes the same bounded meta through the normal classic product panel and a labeled block-editor sidebar control. Both surfaces must save the same value and enforce the same authorization and length rules.

A current WordPress.org support report describes a user who could not find a subtitle field in the block editor. That report demonstrates the discoverability problem; it does not prove that every subtitle plugin or editor configuration fails in the same way.

Diagnose a missing subtitle

Another support thread reports a subtitle that appeared in the shop but not on the single-product page. The useful lesson is to test each promised location separately, not to assume that one visible archive proves the product page.

Keep Pro additive

Free should complete the first useful job: save one subtitle and show it on the storefront. Pro can add bounded reuse, not make Free dependent on a license server.

A safe Pro layer can:

• provide one fallback only when the product field is empty;
• append the same escaped text to cart and checkout item names;
• snapshot the resolved text into one private order-line field;
• show that snapshot in order details and WooCommerce emails.

It should not rename products, rewrite historical orders from current product data, alter cart quantities, change checkout, or make public storefront requests.

Test the invariants, not only the happy screenshot

Use this release checklist:

1. A valid 160-character-or-shorter subtitle saves in both supported editors.
2. An oversized or markup-only submission does not destroy the last valid value.
3. Product and archive switches operate independently.
4. The original product name remains byte-for-byte unchanged.
5. Draft, deleted, mismatched, or empty products render nothing.
6. Desktop and mobile have no overlap or horizontal overflow.
7. Free works with Pro removed and with the license API unavailable.
8. Cart and checkout reuse the correct product or variation subtitle.
9. A new order snapshots the subtitle once; later product edits do not rewrite it.
10. Deactivation removes output immediately.
11. Update, downgrade, rollback, and uninstall do not change product names, prices, stock, carts, customers, or orders.

Resource boundary

The Free storefront path needs one owned product-meta read and one escaped element in an eligible location. A block-editor helper belongs only in the authorized editor. There is no reason for a catalog scan, custom table, cron, queue, telemetry, sitewide asset, or StoreFixKit storefront request.

Pro can read its small local option and reuse the same subtitle in named WooCommerce contexts. A license or update request belongs only behind authenticated administrator actions.

Common mistakes

Putting the subtitle inside the product name

This changes identity everywhere the name is reused. Keep supporting copy in a separate field.

Accepting page-builder HTML

It expands security and compatibility scope. A one-line subtitle should remain plain text.

Using a CSS selector as the insertion point

Selectors vary by theme. Prefer documented WooCommerce hooks and fail quietly when the required context is absent.

Making Pro the source of truth

A billing outage should not remove a merchant's Free storefront subtitle. Free data remains authoritative.

Deleting historical order subtitles on uninstall

That rewrites the meaning of old order output. Preserve historical snapshots even when optional current-product data is explicitly removed.

Market boundary

Current paid and free subtitle products show that this category exists, but they do not prove demand for StoreFixKit. Public evidence captured during product selection included an incumbent with thousands of active installs and a separate paid listing with public sales. Those figures belong to other products and must not be presented as StoreFixKit traction.

The commercial hypothesis is narrower: a nontechnical merchant will pay for reliable additional locations and order-time stability after Free solves the visible product-page job. Validate that hypothesis with measured installs, completed subtitle setup, trials, conversions, support volume, refunds, and renewal behavior.

FAQ

How do I add text below a WooCommerce product title?

Store one plain-text subtitle on the product and render it as a separate element after the native title through WooCommerce's documented hooks.

Does a product subtitle change the SEO title?

Not in this design. Product identity and SEO metadata remain with WooCommerce and the site's SEO component.

Can the subtitle contain HTML or shortcodes?

No. Plain text keeps output predictable and avoids turning a small field into a page builder.

Can the same subtitle appear in cart and email?

Yes, as a bounded Pro feature. Snapshot it when the order line is created so later product edits do not change old orders.

What happens when Pro expires?

Free product-page and archive subtitles continue locally. Only Pro fallback and extra contexts stop applying.