Direct answer
To change WooCommerce's Add to cart wording safely, filter the native shop/archive label and native single-product label separately. Replace only a valid plain-text string. Return WooCommerce's exact incoming label when the setting is empty, the product is missing, or the product type is unknown. Do not change the URL, add-to-cart handler, product type, purchasability, quantity, cart, checkout, or order.
StoreFixKit's Change Add to Cart Text for WooCommerce follows that boundary. Free supplies one shop label and one product-page label. Pro adds product-type, category, and individual product wording while keeping the complete Free result independent of billing.
A button has words, an action, and a destination
These are different things:
- Words tell the shopper what to expect.
- Action decides whether WooCommerce adds an item, opens a product, asks for options, or visits an external seller.
- Destination is the URL or form target.
A text plugin should own only the first item.
WooCommerce's current simple-product code applies the woocommerce_product_add_to_cart_text filter to its own native label. A variable product can naturally use Select options, and WooCommerce's variable product implementation applies the same loop-label filter after deciding whether the product is purchasable. Grouped and external products have different native meanings.
That is why replacing every button with Buy now is unsafe. A variable product may still need a size choice. A grouped product may open several child products. An external product may leave the store. The words can change, but the underlying WooCommerce decision must remain intact.
Treat shop and product pages as separate surfaces
The product archive and the single-product page do not necessarily ask for the same label at the same point.
A useful store-wide setup therefore has two fields:
- Shop button text for native product lists.
- Product page button text for the native single-product button.
This is simpler and safer than a global search-and-replace. It also explains a common symptom: the product page changes while a shop, table, or block keeps other words.
A public support report describes custom text not appearing for product variations. Another reports text changing on a product page but not in a product table. These individual reports do not prove one universal defect. They show why every visible surface needs an identified owner.
Product type matters even when the plugin changes only text
WooCommerce's current classes provide different default labels because the customer action differs:
- simple products can add directly;
- variable products usually need option selection;
- grouped products open a group;
- external products follow the merchant's external button text or use a buy-product fallback.
The external-product code exposes separate URL and text filters. A focused wording plugin must not confuse them.
Before launch, test:
| Product case | What to confirm |
|---|---|
| Simple and in stock | Custom words appear and the same product reaches the cart |
| Variable | Shop wording does not bypass required variation choices |
| Grouped | The button still opens the group rather than adding a wrapper |
| External | The external destination remains unchanged |
| Out of stock | Wording does not make a product purchasable |
| Empty custom field | WooCommerce's exact original words return |
The table is more important than a generic "works with WooCommerce" claim.
Use bounded plain text
An Add to cart label rarely needs more than a short sentence. A plain-text limit of 80 characters is enough for common wording such as:
- Add this item
- Choose your options
- View the collection
- Order this sample
- Buy from our partner
Allowing HTML, shortcodes, dynamic tokens, JavaScript, or remote content would turn one field into a content-rendering system. That would increase XSS, layout, translation, caching, and compatibility risk without improving the basic job.
WordPress's plugin review guidance requires input to be sanitized and validated and output to be escaped. The Common Issues guidance also warns against processing broad request data when only a few owned fields are needed.
Do not force compatibility with CSS or JavaScript
A product table or builder can:
- call WooCommerce's native PHP label filter;
- read product data through REST;
- render a JavaScript component;
- print its own saved text;
- use a copied template;
- replace the button after page load.
Only the first case is automatically inside a native-label plugin's contract.
When a custom surface bypasses WooCommerce's filter, the safe result is to remain silent and document the boundary. Replacing every matching DOM node can change the wrong button, miss screen-reader text, run after a shopper clicks, or break when a theme changes one class name. Replacing templates creates a larger update burden.
Keep accessible behavior under WooCommerce ownership
Visible words are only one part of a button's accessible output. WooCommerce can also supply descriptions and state-specific messages. A text-only plugin should not rewrite those adjacent systems without a separate specification and test matrix.
After changing the label:
- tab to the button with a keyboard;
- confirm the visible focus remains;
- listen to the accessible name with a screen reader or browser inspector;
- choose required variations;
- add the product;
- confirm WooCommerce's live cart message remains accurate.
The goal is clearer wording, not a second accessibility implementation.
Make precedence understandable
Free solves the ordinary problem with two store-wide fields. Pro should add only bounded placement:
- an explicit product Use native text choice;
- an individual product label;
- a native product-type label;
- one selected-category default;
- the Free store-wide label.
The closest valid choice wins. An empty closer field falls through. An explicit native choice returns WooCommerce's incoming words instead of another StoreFixKit fallback.
This order avoids a condition builder. A merchant can explain why a label appeared without reading code or tracing twenty rules.
Localization needs a deliberate decision
A saved custom label is merchant content. It is not automatically translated just because WooCommerce's original string was translated.
For a multilingual store, decide whether:
- one label is acceptable in every language;
- the translation plugin can translate the saved option;
- different language sites need different settings;
- native WooCommerce wording is safer for selected products.
Do not claim automatic multilingual support without testing the actual translation owner and cache.
Resource and failure boundary
For a native WooCommerce render, the product and native label already exist. The focused helper needs only bounded settings and, for Pro, the current product's type, categories, or owned metadata.
It needs no:
- custom table;
- cron job;
- catalog scan;
- product write on a public request;
- frontend JavaScript or stylesheet;
- customer cookie;
- telemetry;
- StoreFixKit request from the storefront.
Missing WooCommerce, invalid settings, an unknown product type, inactive Pro, or an unavailable license service returns the previous WooCommerce label. Free remains local.
The Change Add to Cart Text documentation includes screenshots, exact setup, compatibility limits, troubleshooting, rollback, uninstall ownership, and support evidence.
Beginner launch checklist
Establish a baseline
Open one example of every product type before changing anything. Record the shop label, product-page label, URL, and resulting action.
Save one surface at a time
Change the shop label, test it, then change the product-page label. This makes ownership mistakes easier to see.
Test empty values
Clear each custom field. Confirm WooCommerce's native wording returns exactly.
Test purchasing truth
Check stock, variation selection, quantity, cart contents, checkout totals, and a disposable completed order. Text must not change any of them.
Test custom surfaces
Open the real theme archive, product page, search result, product block, quick view, and table. Record which surfaces use WooCommerce's native filter.
Test rollback
Deactivate Pro and confirm Free continues. Deactivate Free and confirm native words return. Reinstall the previous package and verify owned settings remain.
Security and support evidence
Only a user allowed to manage WooCommerce should save global and Pro rules. Product fields require product-edit permission. Every write needs a nonce, capability check, bounded sanitization, and late escaping. WordPress's nonce documentation is explicit that a nonce is not authorization; capability checks are still required.
Useful support evidence includes the product ID and type, shop or product URL, native incoming words, saved StoreFixKit words, actual result, Free and Pro versions, WooCommerce version, theme/table/block owner, cache/CDN, and screenshots. Remove credentials, customer data, payment details, and full license keys.
FAQ
Can this make a variable product add directly from the shop?
No. It changes words only and preserves WooCommerce's variation requirements.
Can it change the button URL?
No. URL and text ownership are deliberately separate.
Why did a product table keep its old label?
The table may render its own text or bypass WooCommerce's native filter.
Can I use HTML or an icon in the label?
No. The field is bounded plain text.
What happens when Pro expires?
The two Free store-wide labels continue locally. Product-type, category, and per-product labels require an active product-bound license.
Focused plugin
Use the one-job implementation.
Change WooCommerce's native shop and product-page Add to cart wording without changing button links, product behavior, carts, checkout, or orders.