Storefront WooCommerce Guide: The Hooks, the Header Cart and Life After Purple

Made by the WooCommerce team, priced at nothing

Storefront entered the wordpress.org directory in November 2014 and, as of our October 2026 check, reports 90,000+ active installs. It costs $0 for unlimited sites, with no license key to lose and no renewal to miss. WooCommerce describes its integration with WooCommerce and popular extensions as bespoke, and in practice that means shop grids, single product pages, cart and checkout look the way WooCommerce's developers drew them, with very little reinvention layered on top.

That restraint is the store owner's real benefit. A theme that replaces fewer parts of WooCommerce has fewer places to disagree with WooCommerce on update day. The cost is design control: past colors and header options in the Customizer, changes are made in PHP. The Storefront review covers the theme as a whole; this page stays inside the shop.

The hook map a child theme works from

Storefront's shop is assembled from actions, and every piece has a name and a priority. That is why a developer can move the search bar, drop a homepage section or insert a trust badge with a line or two in a child theme's functions.php, without copying a template file. These are the store-related hooks in version 4.6.2, read from the theme's own files.

Storefront also removes WooCommerce's default content wrappers and the woocommerce_sidebar output, then supplies its own, so a plugin that expects WooCommerce's stock wrappers can land a few pixels off. To hide the header cart, for example, a child theme calls remove_action( 'storefront_header', 'storefront_header_cart', 60 ). Reordering the homepage is the same move with the homepage hook and new priorities. When a header half-draws after edits like these, Storefront header not showing is the checklist.

Customizer switches for the shop, and the edges of them

Storefront registers one WooCommerce section in the Customizer, called Product Page, with two settings: Product Pagination, which adds next and previous product links, and Sticky Add-To-Cart, which pins a buy bar to the screen as a shopper scrolls a long product page. Both are cheap wins on product pages with long descriptions. Everything else about shop layout is either a WooCommerce setting, such as catalog image sizes and shop page display, or code.

• The homepage template, template-homepage.php, draws product rows from the homepage hook. Assign it to a static front page and the rows appear; remove a row with remove_action.
• The handheld footer bar gives phones a bottom strip with account, search and cart links. Removing it is one line; restyling it is CSS in the child theme.
• The Handheld Menu is a separate menu location for phones. Forgetting to assign it is the classic cause of an empty mobile menu; see Storefront mobile menu not working.
• Block content inside pages is styled by a gutenberg-blocks.css file, and 4.6.0 added Appearance Tools support, but shop templates remain PHP and cannot be edited in the Site Editor.

If a child theme edit refuses to show, caching and stylesheet order are the usual causes, covered in Storefront CSS not updating. Our theme customization team writes and maintains these child themes for store owners who would rather not open functions.php.

Cart fragments: the speed cost Storefront chose on purpose

Storefront's file list is short: style.css, icons.css, gutenberg-blocks.css, a navigation script and a homepage script, plus Source Sans Pro from Google's font servers. The store-specific item is wc-cart-fragments, which Storefront enqueues so the header cart shows a current count. Since WooCommerce 7.8, core loads that script only where the cart widget appears; Storefront brings it back on every page because its cart lives in the header. The result is a background request on page views where nobody is shopping.

Whether that is worth it is a business call. A store where shoppers browse many products before buying benefits from a live cart count. A store whose traffic is mostly blog readers pays for it on every article. A developer can unhook storefront_header_cart and dequeue the wc-cart-fragments script on content pages, then measure. Check the result with a logged-out test add to cart, because a stale header cart costs more trust than a few milliseconds.

The heavier truth is shared with every theme. WooCommerce's documentation says to exclude Cart, Checkout and My Account from page caching, so those pages run the full stack on each view. A lean theme helps there, which is one honest argument for Storefront. Font hosting and the fragments decision are walked through in the Storefront speed guide.

What critical-fix-only means for a live shop

Storefront's repository carries a status file saying the theme is in active development, then limiting work to critical bugs, bugs with broad impact, compatibility and release-process fixes. Most enhancement requests and feature pull requests are closed. Releases have slowed to about one a year: 4.6.1 in January 2025 and 4.6.2 in December 2025. Its readme still says tested up to WordPress 6.5 and WooCommerce 8.8, while current releases are WordPress 7.1.3 and WooCommerce 11.1.2.

None of that breaks a store on its own. It does change who does the testing. The recent fixes show the pattern: price-filter slider color, sale-price contrast raised to AAA, coupon error styling, and a 4.6.2 fix for product pages timing out with a 504 on WordPress 6.9 when neighboring products shared publish dates and were hidden. The repair came, after a core release found the fault.

1. 1

   Keep a staging copy

   A recent copy of the store, with real products and the same plugins, on the same PHP version as live.

2. 2

   Update WooCommerce there first

   Then check WooCommerce, then Status, for template warnings from your child theme.

3. 3

   Walk the purchase path

   Shop grid, product page, cart, checkout and the order email, on desktop and a phone.

4. 4

   Ship, then watch

   Update live, then watch orders and error logs for a day before the next change.

When the walk turns up a broken grid or product page, Storefront WooCommerce layout broken is specific to this theme and WooCommerce layout broken explains the general mechanism. A checkout that stops taking orders goes to WooCommerce checkout not working, and stubborn timeouts to 504 gateway timeout.

Purple, WooCommerce's block theme, seen from a Storefront store

On September 15, 2026 WooCommerce announced a beta of Purple, which it calls its first official block theme, available on GitHub and a preview site and planned for the Theme Directory and the Marketplace. It ships block templates for WooCommerce pages, ten color palettes, ten font pairings and an ecommerce pattern library covering product grids, filters, collections, calls to action and product pages. The announcement tells testers to run the latest WordPress and WooCommerce.

The post compares Purple directly with Storefront, which it calls the classic flagship theme. It notes that Storefront users may have needed extensions for things like product hero designs, custom homepages, product galleries, a mini-cart or a more advanced header and footer, and argues a good block theme gets those from the editor instead. It says nothing about retiring Storefront, and we found no WooCommerce statement telling stores to switch.

Either way, nothing hook-based transfers. A move to Purple means rebuilding the header, homepage and child theme changes as blocks, so do it once, after a stable release, on a copy of the store.

Past the theme: when the store outgrows the stack

Storefront is rarely what limits a store. The limits arrive as plugins: subscriptions that miss renewals, HPOS order tables out of sync with a reporting extension, checkout extensions that each add a script to the slowest page on the site. If renewals are failing, see subscriptions not renewing; for order table trouble, HPOS sync issues. Live store faults beyond the theme go to WooCommerce website repair.

Storefront does exactly what WooCommerce asks of it. The question is whether WooCommerce is still what the business should ask.

When the answer is no, compare before redesigning. Storefront vs Next.js weighs the theme against a custom build, WooCommerce vs Next.js for ecommerce covers the engine, and WooCommerce to Next.js maps products, customers and order history. The theme-specific steps are in Storefront to Next.js. Sites we build run on Athena CMS, with built-in e-commerce, plain product fields and every version kept. Other store themes, including Flatsome with WooCommerce, are reviewed under WordPress themes.