17. Storefront: go live, and your own store

You will: deploy in the safe order, and learn what carries over to another store.

Deploy in this order

1. Prepare the site. Give it its own PHP pool and user, and remove what doesn't belong on a public site, as in step 8. Turn off page caches that ignore DONOTCACHEPAGE. Our demo also turned cash on delivery off: it takes no real orders.
2. Renderer first. An older renderer leaves the plugin's new section markers on the page. Check /health lists the page types you need, and that an unsigned request gets a 401. /health can look the same on old and new code, so also check something only the new code does: our check looks for section markers left on a page.
3. Plugin, with a key used only by this site, and FLX_MODERNIZE_WOOCOMMERCE.
4. Verify through the origin, not your CDN: each page's marker, private, no-store, no Set-Cookie, and everything that must stay native.
5. A real cart, once. Add an item with a cookie jar, then check the page is Flx and identical to a no-cart page, and that the fragments request still shows the item. Run the same script in CI, so the one you run live is already tested.
6. Then a theme (FLX_RENDER_THEME), and then the shell opt-ins. Each is its own step, and each can be undone alone.

Rollback, fastest first:

• Shell: remove the two constants. Pages are native at once.
• Theme: remove the variable and redeploy.
• Everything: deactivate the plugin. Every visitor gets normal WordPress.

What the measurements say

Flx showed no speed advantage on Storefront. Against the same pages served by WordPress, on the same server:

(Lighthouse 12.6.1, median of 3; curl, median of 20. Measured with no theme, before the shell existed.) WordPress does the same work and then there's a call to the renderer on top. The reason to do this is that JavaScript developers can write the pages. Measure your own site before saying anything about speed.

Your own store

Almost certainly, your store is not plain Storefront with default templates. What carries over:

Today, the plugin renders store pages only on Storefront. Other themes stay native, so it's safe to install, but a different theme needs code changes first.

Start with the site conversion checklist. Then, for a store, also:

• Template overrides. List the theme's woocommerce/ folder. Each one sends that page to native until reviewed.
• Plugins. Which print into cards, product pages, or the head and footer? Which read the visitor's data in a hook?
• Anything that varies per visitor, such as role or geolocation pricing, or a currency switcher. Cookies are hidden from hooks during the build, but a plugin reading the visitor's IP address or other headers still can, and what it prints goes in the page data. These need another approach, or those pages stay native.
• Other forms on Cart or My account. The form-action 'self' policy can block a plugin that posts to another site, such as a social login.
• Payment gateways. Before the Checkout opt-in, test each gateway's own flow. PCI DSS and similar rules may apply to what appears on a payment page: ask the merchant's payment provider or assessor.
• The renderer's account. Whoever can change it can change what the shop's visitors run. See Before using this on a real store.