WordPress Intermediate/Advanced's own capstone closed with an honest scope note: no WooCommerce, no e-commerce — a genuine, deliberate gap left open for exactly this course to fill. This chapter assumes both WordPress Fundamentals and WordPress Intermediate/Advanced are already familiar territory, and starts from the single idea everything else in this course builds on: WooCommerce is not a separate platform bolted onto WordPress. It's a plugin.

Still Just a Plugin — Nothing New to Install Around It

Every mechanism WordPress Fundamentals already taught for installing and running plugins applies to WooCommerce unchanged: it's found through Plugins → Add New, it activates the same way, it lives in the same wp-content/plugins/ directory, and it can conflict with other plugins or themes exactly the way WordPress Fundamentals 6's own plugin-vetting chapter warned about. There is no separate login, no separate database, no separate hosting requirement.

What WooCommerce Actually Adds: A Custom Post Type Called product

WordPress Intermediate/Advanced 4 covered register_post_type() as the mechanism behind custom content types. WooCommerce doesn't invent a new concept here — it calls that exact same function, once, to register its own product post type, conceptually equivalent to this:

Every product is, underneath, a row in the same wp_posts table every page and post already lives in — with post_type = 'product' instead of 'post' or 'page'. Product-specific data — price, SKU, stock quantity — is stored as post meta in wp_postmeta, the identical mechanism WordPress Intermediate/Advanced 4 already covered for custom fields on any post type.

Installing WooCommerce & the Setup Wizard

Installation itself is unremarkable — Plugins → Add New → search "WooCommerce" → Install Now → Activate, exactly the flow WordPress Fundamentals 6 already covered. Activating it launches a guided setup wizard that this course will return to, piece by piece, rather than rushing through now:

What This Course Covers

Products and inventory, store design, the cart/checkout flow, payment gateways, shipping and tax, security specific to e-commerce, extending WooCommerce with hooks, and performance at scale — closing with a capstone that builds and hardens one complete store end to end. Chapter 7's own security chapter is where this course pays off the exact gap WordPress Intermediate/Advanced's capstone named explicitly: nonces, escaping, and $wpdb->prepare() applied specifically to checkout and account forms, where the stakes are real money and real customer data rather than a defaced blog post.

Hands-On Exercises

Chapter 1 established that a product is, underneath, a post of type product with its price and stock stored as post meta. This chapter goes one level deeper: WooCommerce doesn't have just one kind of product, and one of those kinds — variable products — quietly relies on a second custom post type this course hasn't named yet. Then it covers the two pieces of data every product type shares: SKUs and stock.

The Four Product Types

Every product is assigned exactly one product type, chosen from a dropdown on the product's edit screen. This single setting changes which fields appear on the rest of the screen and how the product behaves at checkout.

Variations: A Second Custom Post Type, Hiding in Plain Sight

A Variable product first defines one or more attributes — for example, Size with values Small/Medium/Large, and Color with values Red/Blue. Each specific combination you choose to sell (Small/Red, Medium/Blue, and so on) becomes its own variation, with its own price, SKU, and stock quantity.

Practically, this means a Variable product with 6 size/color combinations is really 7 posts in wp_posts: one product post (the parent, holding the shared title, description, and images) and six product_variation child posts (each holding its own price, SKU, and stock in its own postmeta).

SKUs — Your Own Inventory Identifier, Meeting WooCommerce's

A SKU (Stock Keeping Unit) is a code you assign yourself — WooCommerce doesn't generate or require any particular format. Its only real constraint is that, if you set one at all, it must be unique across every product and variation in the store; WooCommerce will refuse to save a duplicate.

• SKUs are optional at the WooCommerce level, but rarely optional in practice — they're the identifier most shipping carriers, accounting software, and inventory systems expect to integrate against
• A Simple product has one SKU; a Variable product's parent typically has none, since each of its variations carries its own SKU instead
• A sensible SKU scheme (e.g. TSHIRT-RED-M) pays off directly once Chapter 6 covers shipping classes and Chapter 9 covers reporting at scale — an unplanned or missing SKU scheme is a real, common source of later confusion in a growing store

Stock Management

Stock tracking is opt-in per product, under the Inventory tab of the product editor:

Hands-On Exercises

Chapters 1 and 2 covered what a product is underneath. This chapter covers how it actually gets shown to a shopper — WooCommerce's own theme-override system, the official Storefront theme, page-builder compatibility, and the store-specific shortcodes and blocks used to place shop content anywhere on the site.

WooCommerce's Own Template Override System

WordPress Intermediate/Advanced 2 already covered the WordPress template hierarchy — how single.php, page.php, and similar theme files decide how content renders. WooCommerce extends that same idea with its own parallel hierarchy: every page it renders (Shop, single product, Cart, Checkout, My Account) comes from a template file bundled inside the WooCommerce plugin itself, under woocommerce/templates/.

A theme can override any of these by copying the file into an identically-structured woocommerce/ folder inside the theme, and editing the copy:

Storefront — The Official WooCommerce Theme

Storefront is a free theme built and maintained by Automattic (the same company behind WooCommerce itself), designed specifically around WooCommerce's own template structure rather than adapted to it afterward. It isn't the only theme that works with WooCommerce — any reasonably modern WordPress theme will render a store in some form — but it's the reference implementation worth understanding first.

Page Builders & WooCommerce

Popular page builders (Elementor, Beaver Builder, and similar) generally offer dedicated WooCommerce widgets — a product grid, an "Add to Cart" button, a mini-cart — built specifically to read real store data rather than treating a store as static content. Elementor's own paid "Pro" tier, for example, includes a full WooCommerce Builder for customizing the product and archive templates visually, instead of copying and editing PHP template files by hand.

Store-Specific Shortcodes & WooCommerce Blocks

Two separate mechanisms exist for placing store content on any ordinary page — a legacy shortcode system, and the newer WooCommerce Blocks built for the Block Editor WordPress Fundamentals 4 already covered in depth.

Hands-On Exercises

Chapter 3 covered the pages a shopper sees — Cart and Checkout, whether rendered by shortcode or block. This chapter covers what actually happens behind those pages: how a cart is tracked before any order exists, what checkout genuinely does at the moment it's submitted, and the full status lifecycle an order moves through afterward.

The Cart Is a Session, Not Yet an Order

Adding a product to the cart does not create an order, or any row in wp_posts at all. WooCommerce tracks cart contents as session data — tied to the shopper's own browser session, not to any permanent database record representing a purchase.

A practical consequence: an abandoned cart — items added, checkout never completed — leaves no order anywhere in the store's order list. It exists only as a session row, and WooCommerce automatically expires and cleans up old, inactive sessions after a configurable period.

Checkout: Where a Cart Actually Becomes an Order

Submitting the checkout form is the one moment a session's cart contents become a real, permanent order — a row WooCommerce can report on, email, and track, independent of whether that specific browser session still exists.

1. WooCommerce re-validates the cart — checking each item's current stock and price against what's actually configured right now, not what was cached when the item was added
2. Shipping and tax are calculated (Chapter 6's own territory) based on the shipping address entered
3. A new order is created — a shop_order post, or an HPOS order row per Chapter 1's own note on order storage — with an initial status of pending payment
4. The chosen payment gateway (Chapter 5) takes over to actually collect payment
5. Once payment is confirmed, the order's status changes automatically, and stock is reduced (see below)

Order Statuses — The Full Lifecycle

Stock Reduction Timing

Chapter 2 covered what stock management tracks; this is when WooCommerce actually decrements it, a setting under WooCommerce → Settings → Products → Inventory:

Hands-On Exercises

Chapter 4 named a payment gateway as the piece that "takes over to actually collect payment" once an order is created, without saying how. This chapter covers that mechanism in real detail — and, more importantly, the single distinction that determines whether a store takes on a light or a genuinely heavy compliance burden.

What a Payment Gateway Plugin Actually Does

A payment gateway is its own separate plugin — WooCommerce Stripe Gateway, WooCommerce PayPal Payments, and similar — built against WooCommerce's own Payment Gateways API. Once activated and configured with API credentials, it adds itself as a selectable payment method at checkout and takes responsibility for one specific job: actually collecting payment for the order Chapter 4 already described being created.

Hosted & Tokenized Processing — The Distinction That Matters Most in This Chapter

Every reputable modern gateway is built around the same principle: the store's own server never sees the customer's raw card number. Two common ways this is achieved:

• Fully hosted / redirect — the customer is sent to PayPal's own site (or a fully-hosted Stripe Checkout page) to enter payment details, then returned to the store once payment completes. Card data never touches any page the store itself serves.
• Embedded, tokenized fields (Stripe Elements) — card input fields appear directly on the store's own checkout page, but they're rendered inside an isolated frame served by Stripe itself, not the store's own code. Stripe's own JavaScript (Stripe.js) converts the entered card details into a one-time token before anything is sent to the store's server at all.

Notice what's missing entirely: at no point does this code — or anything else running on the store's own server — ever read, log, or store an actual card number. The token stands in for it.

Why This Distinction Sets the Store's Own PCI-DSS Compliance Burden

PCI-DSS (the Payment Card Industry Data Security Standard) applies to any system that stores, processes, or transmits cardholder data. Compliance is self-assessed against one of several Self-Assessment Questionnaires (SAQs), and which one applies depends directly on how much a merchant's own systems are actually exposed to raw card data.

Test Mode — Never Skip It

Every major gateway provides a sandbox environment with separate test API keys and dedicated test card numbers (Stripe's own 4242 4242 4242 4242 is the best-known example) that simulate a full, realistic checkout with no real money ever moving. WooCommerce's own gateway plugins expose a Test mode toggle that swaps live API keys for sandbox ones.

Multiple Gateways, One Checkout

A store isn't limited to one gateway — Stripe and PayPal can both be enabled simultaneously, letting the customer choose at checkout. WooCommerce records which gateway processed a given order, along with that gateway's own transaction ID, as order meta — the same underlying mechanism Chapter 2 already covered for storing a product's price or SKU, applied here to an order instead of a product.

Hands-On Exercises

Chapter 4 named shipping and tax as line items calculated during checkout, deferred to this chapter. Both are configured through the same underlying idea — rules matched against a customer's own address — but the real-world complexity behind each is genuinely different, and worth being honest about rather than glossed over.

Shipping Zones — Geography-Based Rate Rules

Under WooCommerce → Settings → Shipping, a store defines one or more zones — named regions (e.g. "Domestic," "Europe," "Rest of World") matched against a customer's country, state, or postcode. Each zone has its own independent, ordered list of shipping methods: Flat rate, Free shipping, Local pickup, or a real-time carrier-calculated rate via an extension.

Shipping Classes — Per-Product Rate Variation Within a Zone

A single zone's Flat Rate method doesn't have to charge every product the same amount. Shipping classes — assigned per product, on the Shipping tab of the product editor Chapter 2 already covered — let a Flat Rate method define a different cost for, say, a "Heavy" class versus the default "Standard" class, within the very same zone.

Tax Classes — Standard, Reduced Rate, Zero Rate

WooCommerce ships with three built-in tax classes — Standard, Reduced rate, and Zero rate — assignable per product on the same Shipping/General product tabs. Each class maps to its own rate table under WooCommerce → Settings → Tax, with rates entered per country, state, or postcode, mirroring the zone-based matching shipping already uses.

Real-World Complexity: Nexus

Deciding where a US-based store must actually collect sales tax at all is not simply "wherever the store is located." Nexus is the legal connection between a business and a taxing jurisdiction that creates an obligation to collect tax there.

Real-World Complexity: VAT

Selling into the European Union introduces a different model. VAT (Value Added Tax) is generally charged at the buyer's own country rate, not the seller's — meaning a single EU-facing store may owe tax at dozens of different rates depending on where each individual customer is located. Since July 2021, the EU's One Stop Shop (OSS) scheme (building on an earlier 2015 scheme limited to digital services) lets a seller report and remit VAT for sales across the entire EU through a single registration, rather than registering separately in every member state.

Automated Tax Calculation

Given that complexity, most real stores don't maintain their own rate tables by hand. WooCommerce Tax (a free extension from the same team behind WooCommerce) and third-party services like Avalara or TaxJar automatically calculate the correct rate for each order based on the customer's address and current rules, and update as rates or thresholds change — removing the need to manually track a rate table across every jurisdiction a store might sell into.

Hands-On Exercises

WordPress Intermediate/Advanced 8 taught four mechanisms — capability checks, nonces, output escaping, and $wpdb->prepare() — as WordPress's own concrete implementations of general security principles this site already covered in depth. Nothing in this chapter is a new vulnerability class. What's new is the stakes: applied to a checkout page or an account form, the same four mechanisms stand between an attacker and real money, real payment metadata, and real customer PII — not a defaced blog post.

HTTPS: Non-Negotiable for a Store

HTTPS/TLS Fundamentals already covered why encryption in transit matters generally. For a store, it stops being a best practice and becomes a hard requirement: Chapter 5's own tokenized payment fields (Stripe Elements, PayPal) require a secure context to function at all — modern browsers block or restrict the APIs these gateways depend on over plain HTTP, and PCI-DSS itself requires TLS for any transmission of payment-related data. A store running checkout over HTTP isn't taking a small risk; in practice, its payment gateway simply won't work correctly.

XSS on Reviews & Account Fields

XSS — Cross Site Scripting's general lesson — encode output for its specific context, never trust rendered user input — applies directly to two store-specific surfaces: product reviews (user-submitted text, rendered back to every visitor of that product page) and account fields like a saved shipping address (rendered back to the customer, and often to store staff processing the order).

CSRF on Checkout & Account Actions — Nonces Again

CSRF — Cross-Site Request Forgery's general defense — a token proving a request genuinely originated from the expected page — is exactly what protects "Place order" and account-changing actions. WooCommerce's own checkout form includes a nonce field (commonly named woocommerce-process-checkout-nonce), verified server-side before an order is ever created — the same wp_nonce_field()/wp_verify_nonce() pair WordPress Intermediate/Advanced 8 already covered, doing real work at the single most consequential form on the entire site.

SQL Injection in Custom Order Queries

SQL Injections and Defences's general defense — never concatenate user input into a SQL string — applies directly the moment a store adds any custom feature that queries orders by user-supplied criteria, such as an "order lookup by email" tool.

Broken Access Control: Viewing Another Customer's Order

A customer's own My Account → Orders page correctly shows only their own orders, because WooCommerce's own code checks that the logged-in user actually owns each order before displaying it. Custom code that adds an order-lookup feature — say, a URL like /order-status/?order_id=482 — can easily reintroduce exactly the gap WordPress Intermediate/Advanced 8's own capability-check material warned about, if it fetches order #482 and displays it without confirming the currently logged-in user actually owns order #482.

A Compromised Checkout Page Is a Fraud Vector, Not Just a Defacement

The Synthesis: Same Vulnerabilities, Store-Specific Stakes

Hands-On Exercises

Chapter 3 warned that copying a template file forks it, permanently losing that file's future WooCommerce updates — and pointed forward to hooks as the lower-risk alternative. This chapter is that payoff: WordPress Intermediate/Advanced 5's own actions-and-filters material, applied to WooCommerce's own large, separate set of hooks.

Actions vs. Filters, Recapped for WooCommerce

This is exactly the mechanism WordPress Intermediate/Advanced 5 already taught — nothing new conceptually. What's new is the specific set of hooks: WooCommerce fires hundreds of its own action and filter hooks throughout the cart, checkout, product display, and order lifecycle, entirely separate from WordPress core's own hooks.

Finding the Right Hook

WooCommerce publishes an official hook reference documenting its own actions and filters by name and by the data each one provides. In practice, confirming a hook actually fires when and how expected is often done directly and quickly — temporarily adding a logging line inside a candidate callback while testing is a normal, standard part of the workflow, not a sign of doing it wrong.

A Real Example: A Bulk-Discount Pricing Filter

A common, genuinely useful customization: automatically discounting a cart item once its quantity reaches a threshold. The standard, reliable pattern for adjusting cart-item prices hooks into woocommerce_before_calculate_totals — an action, despite modifying a price, because it acts on the whole cart object rather than returning a single filtered value.

$cart_item['data'] is the product object for that line item — the same product object WordPress Intermediate/Advanced 4 already covered as a custom post type instance, reached here through the cart rather than a direct query. Calling set_price() on it changes the price used for totals, tax, and the order eventually created at checkout, without ever touching the product's own stored price in wp_postmeta.

A Real Example: An Action for a Side Effect

Not every customization changes a value — some just need to do something at a specific point. Notifying an internal fulfillment system once an order is marked complete is a genuine action, not a filter:

wc_get_order() returns a full order object — the same underlying order data Chapter 4 described being created at checkout, now available inside a hook triggered by that same order's own status change.

Where to Put This Code

WordPress Intermediate/Advanced 5 already made the case for a small custom plugin over a theme's own functions.php — a plugin survives a future theme change, functions.php doesn't. That reasoning applies here without modification.

Hands-On Exercises

WordPress Intermediate/Advanced 9 already covered caching and mapped it to Performance & Core Web Vitals's own LCP/INP/CLS metrics — for an ordinary page, that material applies to a WooCommerce store unchanged. This chapter covers the one genuine complication e-commerce adds: some of a store's own pages can't simply be cached the way a blog post can, and WooCommerce has a specific, real mechanism for handling that.

Why Full-Page Caching Can't Simply Be Applied Everywhere

Full-page caching, as WordPress Intermediate/Advanced 9 covered it, works by serving one pre-generated copy of a page's HTML to every visitor — genuinely safe and effective for a blog post, whose content is identical no matter who requests it. Cart, Checkout, and My Account pages break that assumption entirely: their content is different for every single visitor, by design.

WooCommerce's Own Solution: Cart Fragments

The naive fix — excluding Cart, Checkout, and My Account entirely from caching — solves the data-leak problem but still leaves one gap: the small "mini-cart" widget (an item-count icon in the header, for example) commonly appears on every page, including the Shop and product pages that are otherwise perfectly safe to cache. If those pages are cached, that widget's cached HTML would show whatever cart count happened to exist when the page was cached — wrong for almost every subsequent visitor.

WooCommerce solves this with Cart Fragments: after a cached page finishes loading, a small AJAX request (wc-cart-fragments.js, built on the woocommerce_add_to_cart_fragments filter) fetches just the visitor-specific pieces — the mini-cart's own current markup — and swaps them into the already-loaded page. The surrounding page stays fully cacheable; only the small fragment that genuinely needs to be personal is fetched fresh.

Object Caching at Catalog Scale

WordPress Intermediate/Advanced 9's own object-caching material (Redis/Memcached, avoiding repeated identical database queries within and across requests) matters more for a store than for an ordinary blog, simply because of how much more repeated data lookup a store's own pages generate — product data, stock status, and pricing are read constantly across the Shop page, product pages, and the cart itself, often for the very same products, request after request.

Core Web Vitals on Product Pages Specifically

Performance & Core Web Vitals's three metrics apply to a store with their own specific, common failure points:

Hands-On Exercises

Nine chapters have built the pieces, one at a time. This capstone assembles them into one real, working store — Wick & Ember, a small candle business — from catalog through a hardened, launch-ready checkout, closing this course and the WooCommerce/e-commerce gap WordPress Intermediate/Advanced 10's own honest scope note deliberately left open.

1. Installing WooCommerce & Building the Catalog

WooCommerce is installed and activated the standard plugin way (Chapter 1), and the setup wizard's store details are filled in. The catalog is built from both product types Chapter 2 covered:

2. Store Design

The Storefront theme is activated (Chapter 3), and the homepage places a Products block configured to show the store's featured items — the modern equivalent of the [products] shortcode Chapter 3 also covered, chosen here since the homepage is being built in the Block Editor.

3. Verifying the Cart & Checkout Flow

Before connecting real payment, a full test purchase confirms Chapter 4's own order lifecycle end to end: adding items creates only session data in wp_woocommerce_sessions, submitting checkout creates a real order at Pending payment, and — since Wick & Ember sells physical, shippable candles rather than downloads — the order is expected to pass through Processing before reaching Completed, exactly the gap Chapter 4 explained that status exists to represent.

4. Configuring Payment: Stripe in Test Mode

The Stripe gateway plugin is configured with Test mode enabled (Chapter 5) and a full checkout is run using Stripe's own 4242 4242 4242 4242 test card. Chapter 5's own PCI-DSS material is confirmed directly: Stripe's embedded fields tokenize the card before anything reaches Wick & Ember's own server, keeping the store's compliance burden at the lighter SAQ A tier rather than the heavy SAQ D tier a custom card form would require.

5. Shipping & Tax

A single "Domestic" shipping zone is configured with a Flat Rate method, plus a "Heavy" shipping class (Chapter 6) applied to the Signature Scent Trio's larger candles, priced higher than the Standard-class single-wick candle. Tax rates are configured for Wick & Ember's own home state, with a note — per Chapter 6's own honest disclaimer — to confirm actual multi-state nexus obligations with a real accountant before expanding sales significantly beyond that state.

6. Hardening a Custom Order-Lookup Feature

Wick & Ember wants a simple order-status lookup page for customers who checked out as guests, without a My Account login. Built naively, this is exactly Chapter 7's own broken-access-control example — fixed here with an explicit ownership check, alongside escaping and a parameterized query:

Every guest order lookup now requires both a valid order ID and the matching billing email — an attacker guessing sequential order IDs alone can no longer view another customer's order status.

7. A Wholesale Bulk-Discount Hook

A local gift shop wants to buy candles wholesale, 5 or more at a time, at a 10% discount. Chapter 8's own bulk-discount filter is added, unchanged, via a small site-specific plugin rather than the theme's functions.php — guarded, per Chapter 8, against firing outside a real cart context:

8. Verifying Caching & Core Web Vitals Before Launch

• The caching plugin is configured to exclude Cart, Checkout, and My Account entirely, per Chapter 9's own data-leak warning
• The mini-cart's Cart Fragments are confirmed working — adding an item from a cached Shop page updates the header's item count without a full page reload
• Product photos are confirmed compressed and appropriately sized, addressing Chapter 9's own LCP concern before launch
• The Signature Scent Trio's variation-selector area is confirmed to reserve stable space for price/stock text, avoiding the CLS risk Chapter 9 named for Variable products specifically

Chapter Attribution

Honest Scope Note

Hands-On Exercises