Store Setup and Launch

The Settings screens ask for facts that are hard to change once orders exist, so settle these first. They are generic store-planning questions (the books about WooCommerce spend most of their pages on them) and the Pocket Coffee answers show what a decision looks like.

None of this is legal or tax advice. The tax rates, the VAT scheme for sales to other EU countries (the One Stop Shop scheme) and the legal pages depend on where the business is established; the page uses the standard Spanish rate of 21 % as an illustration only.

Activating WooCommerce starts the Core Profiler in the browser (it replaced the Setup Wizard of the 3.x era). It collects store details and offers recommended extensions and a theme; the answers are stored in the option woocommerce_onboarding_profile, and the WooCommerce home screen then shows a task list. The tasks are classes under src/Admin/Features/OnboardingTasks/Tasks/ in 11.2.1 with the ids store_details, products, payments, tax, shipping, marketing, appearance (the theme step), extend-store, launch-your-store and get-mobile-app, plus further ids (customize-store, review-shipping, woocommerce-payments, shipping-recommendation, tour-in-app-marketplace) that the source defines for some configurations. A task is only a link to the screens below, so skipping the Core Profiler loses nothing that cannot be set by hand.

The flow needs a browser, an administrator session and, for some of its offers, a connection to a WordPress.com or Woo account; it was not run for this page. The scripted route below does not depend on it. The legacy class WC_Admin_Setup_Wizard still ships in includes/admin/class-wc-admin-setup-wizard.php, and books that describe a page-by-page wizard (location, currency, payments, shipping, recommended extras) describe that older flow.

Source: WooCommerce: configuring WooCommerce settings

All store settings live under WooCommerce > Settings. In 11.2.1 the tab ids and labels, read from WC_Admin_Settings::get_settings_pages(), are general (General), products (Products), tax (Tax), shipping (Shipping), checkout (Payments), account (Accounts and Privacy), email (Emails), integration (Integration), site-visibility (Site visibility), point-of-sale (Point of Sale) and advanced (Advanced). The Tax tab only exists when tax calculation is on (woocommerce_calc_taxes is yes). The tab id is the value of the tab parameter in the URL: /wp-admin/admin.php?page=wc-settings&tab=shipping&section=options.

Every setting is a WordPress option whose name is the field id, so a value can be read and changed from WP-CLI with wp option get and wp option update, and the same fields are exposed by the REST API under /wp-json/wc/v3/settings (listing a group, then reading or updating one field; the REST settings route was not exercised for this page). Changing an option directly skips the screen’s validation and, for a few settings, the side effects that run on save, so use WP-CLI for the simple fields below and the screen when a setting has dependencies.

Tax is where a launch usually goes wrong, so the decisions are explicit. With woocommerce_prices_include_tax set to yes the price you type is the price the customer pays and WooCommerce extracts the tax from it; with no tax is added on top. woocommerce_tax_based_on decides which address selects the rate: shipping (the default), billing or base (the shop address). Rates are rows of country, state, postcode, city, rate, name, priority, compound and shipping (whether the rate also applies to shipping), grouped by tax class. A product’s Tax status (taxable, shipping only or none) and Tax class choose the class; the classes after install are Standard rate, Reduced rate and Zero rate.

Pocket Coffee sells with tax included and one Spanish rate:

The same data goes through Settings > Tax > Standard rates > Insert row or the import CSV (sample-data/sample_tax_rates.csv in the plugin shows the columns). Rates entered by hand are not a tax-compliance system: they do not know about EU One Stop Shop thresholds, VAT numbers for business customers or changing rates. Extensions or the automated tax calculation of the WooCommerce Shipping & Tax extension (it needs a connected account and was not run here) cover that, and the Taxes, Coupons, Currencies and i18n page goes through the calculation.

Source: WooCommerce: setting up taxes in WooCommerce

Products live under Products. The classic product editor is the editor in 11.2.1: the block-based product editor was deprecated in 10.9.0 and removed in 11.0.0, and old guides that show its screens no longer match. The product types are simple, variable, grouped and external (affiliate); virtual and downloadable are checkboxes on a simple or variable product. A product has a name, description, price, SKU, stock, weight and dimensions, categories, tags, attributes, a tax class, a shipping class and images; the Products and Product Types page covers each tab. A variable product has attributes flagged "used for variations" and one variation per combination; each variation has its own SKU, price, weight and stock.

Pocket Coffee’s catalogue is one simple product and one variable product with three attributes (origin, grind, size), 18 variations, per-variant stock and the SKU pattern PC-<ORIGIN3>-<GRIND3>-<SIZE>. The prices are 8.90 EUR for 250 g and 29.90 EUR for 1 kg, with Ethiopia 1.00 EUR dearer per 250 g. Created from WP-CLI (the loop at the end of the script below creates the variations):

(The middle rows of the real 18-row table are omitted.) Three rules save trouble. Custom attributes (typed in the product) are private to that product, while global attributes (Products > Attributes) create taxonomy terms that the shop can filter on, so the "origin" attribute that Pocket Coffee wants to filter by should be global; the script uses product-level attributes to stay short. A variation’s attributes must name the exact attribute and option strings of the parent, or the variation is created but never matches a selection. And creating hundreds of variations through the editor is slow; use the CSV importer (Products > Import, a Type of variation and a Parent SKU) or the batch REST endpoint for large catalogues.

Source: WooCommerce: products

A shipping zone is a set of locations (countries, states, postcodes) with shipping methods attached; a customer gets the methods of the first zone, in the zone order, that matches the address, and the built-in "Locations not covered by your other zones" zone is the fallback. Methods are Flat rate, Free shipping and Local pickup in core; carriers' methods come from extensions. The facts below were measured on the Pocket Coffee zones.

Source: WooCommerce: setting up shipping zones

The calls to WC_Shipping_Zone are needed because the wp wc shipping_zone_location group only has list (there is no create or update command); the REST route PUT /wc/v3/shipping/zones/<id>/locations does the same with a JSON array. Four behaviours are worth knowing before they surprise a customer.

The output is from the first test site after its two methods were reordered; the order is the method_order column of wp_woocommerce_shipping_zone_methods. The setting Hide shipping rates when free shipping is available (woocommerce_shipping_hide_rates_when_free) removes the other rates once the free one qualifies, which makes the default question moot; Pocket Coffee leaves it off so that customers can still choose a faster method later.

Core has no per-parcel weight limit. The 5 kg limit of the Pocket Coffee spec is therefore expressed through the structure of the catalogue (a shipping class for bulky items, quantity-based cost formulas) or an extension; it cannot be set as a single number on the flat-rate method. Local pickup, shipping classes and the rate pipeline are covered on the Shipping Methods page.

Source: WooCommerce: setting up shipping zones

A gateway is an object that decides which payment methods the checkout offers and what happens to the order afterwards. In the core install there are three, and none talks to a provider:

Source: WooCommerce: payments

Enabling a gateway sends the administrator an e-mail through the admin_payment_gateway_enabled message, so the command printed sendmail: can't connect to remote host (127.0.0.1): Connection refused on a machine with no mail server; the gateway was still enabled. bacs takes the account details shown to the customer on the order confirmation and in the e-mail, and an order paid by bank transfer is created as On hold until you mark it paid. cheque behaves the same way. cod needs a shipping method that supports it: a checkout with cod before any shipping zone existed returned woocommerce_rest_checkout_payment_method_disabled. For card payments, the choices are the WooPayments plugin (the official one, with an in-context onboarding since 9.9.0 that needs a WooPayments account), other provider plugins from the WordPress.org directory or the Woo Marketplace, and a hosted payment page. Their onboarding was not run for this page. Prefer a provider whose card fields are hosted by the provider (hosted fields or a redirect): then card numbers never reach your server, which keeps the PCI DSS burden at the lightest self-assessment. A gateway must also support the Checkout block; the Payment Gateways page explains how, and why an old gateway that only registers a classic payment method does not appear in the block checkout.

The setup is tested with a real order. The Store API request below uses the same endpoints as the block checkout, with a guest cart, the coupon and bank transfer; the shipping and totals are computed by WooCommerce, not by the script:

Source: WooCommerce docs: Store API checkout endpoint

The order is then placed with a POST to /wc/store/v1/checkout carrying the Cart-Token and Nonce headers and a body with billing_address, shipping_address and payment_method set to bacs. The order that came out:

Order 35 is the same cart without the coupon (83.80, shipping 0.00 because the cart qualifies for free shipping); order 36 has the Coffee Club coupon (see the next section) and a total of 77.82. Both are on-hold because bank transfer waits for the payment.

Source: WooCommerce: payments

Pocket Coffee wants "10 % off beans for Coffee Club members, applied automatically". WooCommerce core has no customer groups and no automatic role-based discounts. What it offers:

WooCommerce stores coupon codes in lower case (coffeeclub), whatever case you typed. Two behaviours of the e-mail restriction came out of the tests: applying the coupon to a guest cart whose customer has no e-mail returned Please enter a valid email at checkout to use coupon code "coffeeclub", and applying it after update-customer had set the billing e-mail to ada@example.test worked. The restriction is therefore checked against the e-mail the customer has entered, not against a login. A coupon restricted to the Beans category did nothing to a cart with only the starter kit (coupon is not applicable to selected products).

The figure shows the verified cart: 59.80 of beans plus the 24.00 kit is 83.80; the coupon takes 5.98 from the beans only (4.94 plus 1.04 VAT); that leaves 77.82. With the flat rate preselected the customer would have paid 77.82 plus 5.93 = 83.75 although free shipping was available, which is why the order of the methods matters.

Source: WooCommerce: coupon management

WooCommerce sends transactional e-mails from classes registered in WC()->mailer(). In 11.2.1 the registered classes are:

Settings > Emails sets the sender (woocommerce_email_from_name, woocommerce_email_from_address), an optional reply-to (woocommerce_email_reply_to_enabled, woocommerce_email_reply_to_name, woocommerce_email_reply_to_address), the header image and its width and alignment (woocommerce_email_header_image, woocommerce_email_header_image_width, woocommerce_email_header_alignment), the font and footer text (woocommerce_email_font_family, woocommerce_email_footer_text) and the colours (woocommerce_email_base_color, woocommerce_email_background_color, woocommerce_email_body_background_color, woocommerce_email_text_color, woocommerce_email_footer_text_color, with woocommerce_email_auto_sync_with_theme to take them from the theme). Each e-mail then has its own screen under the same tab with an enable switch, the subject, the heading, additional content and the e-mail type (plain or HTML). The new e-mail templates and the block e-mail editor sit behind the feature options woocommerce_feature_email_improvements_enabled and woocommerce_feature_block_email_editor_enabled, both no in 11.2.1.

The sender address must belong to a domain whose mail you control (SPF, DKIM and DMARC records for that domain), or providers flag the order e-mails as spam; WordPress’s default wp_mail() uses PHP mail() and often fails on containers and cheap hosts. Delivery is a hosting decision (an SMTP or transactional-mail plugin); in the test stack there was no mail server, so no e-mail left the machine (sendmail: can't connect to remote host), and the e-mail bodies were read from the templates, not from an inbox. A mail catcher (a local SMTP server with a web inbox) is the way to read them in development. The Emails page covers templates and WC_Email.

Source: WooCommerce: e-mail settings

A theme decides the look and the templates; extensions add behaviour. Both are choices you live with, so the checks below matter more than the demo.

Theme. A new WordPress 7.1.3 site comes with the default block themes (Twenty Twenty-Five 1.5, Twenty Twenty-Four 1.6, Twenty Twenty-Three 1.7) and the first one was active in the test site. WooCommerce works with block themes through theme.json and the Woo block templates, with classic themes through PHP templates, and the Cart and Checkout blocks work in both. Storefront 4.6.2 (2025-12-09) is the long-standing classic theme from the WooCommerce team; Purple (version 1.0.3, updated 2026-10-09) is the block theme and needs WordPress 7.1 or newer. Prefer a block theme for a new store, keep customisations in a child theme or in the Site Editor, and expect a classic theme’s yourtheme/woocommerce/ template overrides to break when WooCommerce bumps a template version (WooCommerce > Status lists outdated overrides). The theme section of the Themes: Block and Classic page covers this in detail; the books' advice to design around a Customizer and widget areas describes the classic era.

Extensions. WooCommerce core is deliberately small, so most stores add a few extensions. Before installing one, check:

wp wc hpos compatibility-info is the quick HPOS check; a plugin that has not declared compatibility makes WooCommerce warn before HPOS is enabled. Keep the number of extensions small, remove the ones you stop using instead of deactivating them, and test updates on a copy of the store first. Advice that named specific plugins in the books (SEO, security, backup, caching) is dated; evaluate current options with the checks above.

Source: WooCommerce docs: extensions

The script below assembles the commands of this page into one file that creates the settings, tax rate, shipping zones, payments, catalogue and coupon. It was run on a clean WordPress 7.1.3 and WooCommerce 11.2.1 site, finished in about 45 seconds and produced the zones, the 18 variations (with the IDs, SKUs and prices of the table above), the tax rate and the coupon listed in this page. It uses an administrator called shopadmin and WP-CLI as $WP.

Source: WooCommerce docs: WP-CLI and the development environment

The script is not idempotent: run twice, it creates a second tax rate, second zones and a second catalogue. For repeatable environments, create the site from scratch (a fresh container or wp db reset --yes) each time, as the local-environment page describes. The coupon code is taken by the first run, and a second shop_coupon create for the same code fails with a duplicate-code error.

Most store compromises come from outdated or untrusted plugins and weak administrator accounts, not from WooCommerce core; Patchstack’s 2026 report counts 91 % of the new WordPress vulnerabilities of 2025 in plugins and 9 % in themes (a third-party source). The routine below is what a small store can sustain. The commands were run on the test site.

Automatic updates for WooCommerce are a trade-off: security releases arrive fast (the July 2021 SQL injection was patched in a forced update within a day), but an automatic update can break a customised checkout, so many stores enable them for core and security releases and test major updates by hand. DISALLOW_FILE_EDIT removes the theme and plugin editors from wp-admin, which stops an attacker with an administrator session from writing PHP there. WordPress’s cron runs on page visits; a store with low traffic or a caching layer should call wp-cron.php or wp cron event run --due-now from the system cron and set DISABLE_WP_CRON, because Action Scheduler (orders, e-mails, subscriptions) rides on it.

WooCommerce > Status > Tools offers maintenance actions that are safe to run when a symptom matches. The ids in 11.2.1 (shown by wp wc tool list --user=<administrator>) include clear_transients, clear_expired_transients, delete_orphaned_variations, clear_expired_download_permissions, regenerate_product_lookup_tables, repair_coupons_lookup_table, recount_terms, reset_roles, clear_sessions, clear_template_cache, install_pages, db_update_routine, verify_db_tables, regenerate_product_attributes_lookup_table, clear_woocommerce_analytics_cache, hpos_legacy_cleanup and, destructive, delete_taxes and delete_custom_orders_table. A tool runs with wp wc tool run <id> --user=<administrator>; read the description before you run the destructive ones. The Status > System status report is what support asks for first: it lists versions, active plugins, database tables, outdated template overrides and the HPOS state.

Payment security. A store that never sees card numbers (hosted fields or redirect) completes the lightest PCI DSS self-assessment; a store that handles card data itself takes on the full burden. Keep API keys and gateway secrets out of the code and rotate them after any suspected compromise. The incident history, the 21-release security backport window and hardening beyond this routine are on the Performance and Security page, and the developer-side checklist is in the official security best practices (PHPCS and Semgrep clean code, WordPress hardening, 2FA, data protection).

Source: WooCommerce docs: security best practices

WooCommerce can hide the store until you are ready. Settings > Site visibility (the option names are woocommerce_coming_soon and woocommerce_store_pages_only) has two modes: coming soon for the whole site, or for the store pages only, so that a blog or marketing site stays public while the shop is private. In the 11.2.1 source, woocommerce_coming_soon set to yes with woocommerce_store_pages_only not yes puts the whole site in coming-soon mode, and both set to yes limits it to the store pages; administrators and shop managers (manage_woocommerce) always see the real site. A scripted install leaves woocommerce_coming_soon unset, so the store is live from the moment it is installed; check the setting before you point a domain at the site.

On a test site, with the whole site in coming-soon mode, an anonymous request to the home page returned HTTP 200 with the header Cache-Control: max-age=60, and the page head contained <meta name='woo-coming-soon-page' content='yes'> and a robots meta of max-image-preview:large. The coming-soon page is therefore a normal 200 response, not a 503, and it carried no noindex directive; search engines can index it if they find it. WordPress’s own Discourage search engines from indexing this site switch (Settings > Reading, option blog_public) is a separate control. A page cache in front of the site keeps serving the page for as long as its own lifetime, so purge it when you switch the mode.

Search and marketing are launch topics in every book: use readable permalinks (the default product base is /product/ and the product category base /product-category/, both editable in Settings > Permalinks), give each product a unique title and description, keep one URL per product (variations use query parameters on the same URL), and let WooCommerce emit its product structured data. Analytics and advertising pixels must respect consent rules in the countries you sell to, so add them through a consent-aware plugin and mention them in the privacy policy. The order of the final steps is: finish the content, run the test orders, switch the site visibility to live, purge caches, place a real order yourself, and watch the first days of orders and e-mails.

The books on this subject describe an older WooCommerce and are background only. Sims (2018, WooCommerce 3.x and WordPress 4.9) walks the Setup Wizard, the Customizer and widget areas of Storefront, shortcode-based Cart and Checkout pages and PHP 5-era hosting; today the Core Profiler and the task list replace the wizard, block themes replace the Customizer for new stores, the Cart and Checkout blocks are the default and PHP 7.4 is the floor (PHP 8.3 is recommended). Rauland (2015, WooCommerce 2.2 and 2.3) edits the checkout with woocommerce_checkout_fields and enforces HTTPS on the checkout only; those filters do not affect the Checkout block and HTTPS now belongs on every page. Ravensbergen (2015, WooCommerce 2.4 and 2.5) builds a Storefront child theme with storefront_* hooks and shortcodes and refers to WooThemes and Simplify Commerce, which no longer exist as described. The store-planning, launch, security, backup and maintenance advice survives, which is why it is rewritten above for the current screens, options and commands.