Module 1 · 1.2

English

Nederlands English Deutsch

How WooCommerce works

Module 1: Before you start · Reading time: 10 minutes

Learning objective: After this lesson you can explain how WooCommerce works inside WordPress and where products, orders, the basket and the scheduled tasks are kept.

Key concepts: product type, product post type, orders (HPOS), shop pages, session and basket, Store API, REST API, Action Scheduler, transactional emails, extensions

A plugin that turns your site into a shop

In the WordPress course (lessons 1.2 and 1.3) you saw how a page is built: the web server passes the request to PHP, PHP loads WordPress, the plugins and the theme, fetches data from the database and turns it into HTML. WooCommerce fits into that process as one large plugin. It brings four things:

Data: products, orders, customers, tax rates, shipping zones.
Pages: the shop, the basket, the checkout and My account.
Processes: a basket for each visitor, payments through a payment provider, emails, stock updates, scheduled tasks.
Entry points for programs: the Store API and the REST API.

If you know where these parts live, you can track down a fault much faster later on. So let's look at them one by one.

Products: a post type of their own

WordPress has post types: pages and posts are two of them (WordPress course lesson 4.2). WooCommerce adds the post type product. So a product, just like a page, is stored in the posts table, with its extra details (price, SKU, stock, weight) as metadata. Product categories and tags are separate taxonomies, independent of those of your blog.

Every product has a product type. The core types are simple, grouped, external (a link to another shop) and variable. You can also tick the boxes virtual (nothing to ship) and downloadable (a file after payment). A variable product has variations, such as a teapot in three colours; each variation is an item of its own with its own price and stock. Module 3 goes into this in more depth.

Orders: tables of their own (HPOS)

WooCommerce used to store orders as posts as well. In busy shops that became slow, because orders and blog posts shared the same large table. That is why HPOS (High-Performance Order Storage) was introduced: orders in tables of their own, such as wc_orders, wc_order_addresses and wc_orders_meta (with your site's table prefix in front). Since WooCommerce 8.2 (October 2023), HPOS is switched on in every new installation. An older shop stays on the old storage until you switch over yourself under WooCommerce > Settings > Advanced > Features.

Why do you need to know this? For three reasons:

Backups: orders are not in your files but in the database. For a shop, a backup without the database is worthless (lesson 6.2).
Extensions: an older extension that still reads orders as posts does not work properly with HPOS. WooCommerce shows a warning next to the plugin if it is not compatible.
Restoring: if you restore yesterday's backup, today's orders disappear. For a shop that is far worse than for a blog (lesson 6.2).

The basket: different for every visitor

An ordinary page is the same for every visitor. The basket is not. As soon as a visitor puts something in the basket, WooCommerce starts a session: a cookie (wp_woocommerce_session_ followed by a code) in the browser and a row in a sessions table in the database. That way the shop knows, at the next request, which basket belongs to this visitor.

Two consequences you will come across later:

The basket, checkout and My account must never end up in a page cache, or one visitor will see another visitor's basket. WooCommerce itself sends headers on those pages that forbid caching (lesson 6.4).
A shop that starts a session for every visitor, even without a basket, makes the page cache of the whole site useless. This is a common mistake in themes and extensions.

The shop pages and the blocks

During installation WooCommerce creates four pages: Shop, Basket, Checkout and My account. Since version 8.3 (November 2023), new installations use blocks for the basket and checkout; older shops often still use shortcodes. Both work. The difference matters for extensions: an extension that adds something to the checkout must support the variant you use. Lesson 2.2 shows you how to check this.

Two entry points for programs: Store API and REST API

WooCommerce has two programmable entry points, and the difference matters for security:

	Store API	REST API
Address	`/wp-json/wc/store/v1/...`	`/wp-json/wc/v3/...`
For whom	The shop itself (the blocks in the browser) and other shop front ends	Integrations: accounting, stock, apps
Key needed?	No, public: anyone can read products and prices	Yes, an API key with read or write permissions
What it contains	Products, prices, stock status, the current visitor's basket	Also orders, customers, reports

The fact that the Store API is public is not a leak: it is exactly what every visitor sees in the shop, just in a form that programs can read. Try it with your own shop: open https://shop.example.com/wp-json/wc/store/v1/products in your browser (with your own address) and you will see your products as JSON. The REST API, on the other hand, should be closed without a key. Lesson 2.4 checks both.

Behind the scenes: Action Scheduler and emails

A lot of the work in a shop does not happen while the customer waits, but later. WooCommerce uses the Action Scheduler for this: a queue of scheduled tasks, such as cancelling an unpaid order after the time you set, sending webhooks or updating reports. You can see the queue under WooCommerce > Status > Scheduled Actions. These tasks run on WP-Cron, which only runs when there are visitors. In a quiet shop, work can therefore pile up; lesson 7.3 shows how a real cron solves this.

WooCommerce also sends transactional emails: an email to you for a new order, and emails to the customer when an order is received, shipped or refunded, or when a new account is created. If these do not arrive, the customer thinks something has gone wrong. Lesson 6.1 sorts out deliverability.

In practice: this is how it looks in WooCommerce

After installation, three new menus appear in the WordPress dashboard of Theehuis Example: WooCommerce (orders, customers, settings, status), Products and Analytics (in recent versions sometimes under WooCommerce). Under WooCommerce > Status you will find the server environment, the database tables, the scheduled actions and the logs. You will need that screen often. The steps are the same with every hosting provider, because they are part of WordPress itself.

Summary

WooCommerce brings data, pages, processes and two programmable entry points.
Products are a post type of their own; in new shops, orders are stored in tables of their own (HPOS, the default since 8.2).
The basket works with a session for each visitor; that is why the basket, checkout and My account must stay out of the cache.
The Store API is public and shows what every visitor sees; the REST API should be closed without a key.
Scheduled tasks run through the Action Scheduler and WP-Cron; emails are part of the ordering process.

Quiz

Exercise

Exercise A1.2: Does this site run on WooCommerce? Enter a domain, choose yes or no, and write down what evidence you saw (for example "generator" or "wc/store/v1"). The program fetches the homepage, reads the REST index (/wp-json/, only the list of namespaces) and requests /wp-json/wc/store/v1/products?per_page=1. It recognises WooCommerce by a meta generator mentioning WooCommerce, the namespace wc/store/v1 in the REST index, a working Store API, files from /wp-content/plugins/woocommerce/ or the body class woocommerce. Green: your choice is correct and your evidence appears in the headers, the HTML, the REST index or the Store API response; you will then also see the number of products and the currency. Orange: your choice is correct, but we cannot find your evidence. Red: your choice is not correct. Try it on your own shop first and then on a shop you know. Nothing is added to a basket and nothing is sent.

Cookies at WebOké

Cookie settings

Necessary

Marketing