Two WooCommerce stores redesigned on Bricks, every email redone

Mississippi Mane & Co. was one of my first clients. Joseph makes beard oils, balms and washes by hand in Mississippi, and around 2018 he let me build his online store. It had aged since: the Divi theme, WooCommerce's stock emails, and a Mailchimp list over its free limit with sending paused. He didn't ask for a redesign. I built one anyway and surprised him with it.

The new store runs on Bricks and Automatic.css, on the WooCommerce that already held his products, orders and customers. It's designed as a field guide, in light and dark: every scent gets a numbered plate and its notes.

Asking the server on every keystroke took up to a second a letter, so search now loads the catalog once and searches it in the browser, in 1 to 5 milliseconds. It matches scent notes too: type cedar and five products come up, none named cedar.

Every store email was rebuilt to match. The list moved to SureContact, where my agents built a nine-email welcome series through its MCP server; it's ready but not switched on yet. The Mississippi Mane & Co. case study has before-and-after sliders.

AK Operators Union, live on Sunday

AK Operators Union Local 47-74 sells AK optics, mounts, parts and union gear. I built its last site on Kadence. The new one runs on Bricks and Automatic.css, on the same WooCommerce and its 79 products.

The design is called Surplus Crate: categories are numbered crates, and every product wears its stock number like a tag. It also has shop filters, search with photos and prices as you type, a new logo and every store email redone.

Rob, who runs the store, asked for one change: the order number and date at the top of order emails, where he looks when making shipping labels. I built it all on a copy of the store so the live one kept taking orders, and it went live on November 8. More in the AK Operators Union case study.

A full code cache, and a server-first update

Working on that copy, I noticed it was sluggish. PHP keeps compiled code in a cache, OPcache, shared by every site on the same PHP version on a server, and the live store shares its server with the staging copy. The cache was full at 128 MB, all of it staging's code, so the live store compiled its code on every request, at 221 MB of memory each. At 512 MB, the hit rate went from 43% to 97%, and a live request dropped to 36 MB.

That's why the Site Speed Pack 1.1.0, out Sunday, is server first: before any speed plugin, it checks PHP's code cache, the database, the object cache and PHP's worker pool. A plugin measured on a starved server looks better or worse than it is, and all three WordPress servers I checked this month had a full cache.

The Site Speed Pack, and the end of a course

The pack launched on November 6 on Heavy Artillery Skills, for $39. It makes your AI coding agent measure first, change one kind of thing at a time, and prove after each change that the phone menu still opens on the first tap and the layout holds, on WordPress or a code-built site.

I built it from a speed pass on holygrailwp.com, my WordPress site speed course, where mobile Lighthouse scores on seven pages went from 67–90 to 94–100. That course, which I built a few years ago, will be retired soon. Its principles all still hold. I just don't think doing all that testing by hand is a good use of my time, or anyone's, when an agent can run it far faster.

Novamira HQ on every WordPress site

Novamira is the plugin my AI agents use to work inside WordPress. Each site used to have its own connection on an application password. Now more than 50 sites and staging copies connect through Novamira HQ instead, and the old passwords are revoked and tested. Sites I'm not actively working on are in read mode: an agent can look but can't change anything until I turn writing on.

A WAF inventory across Cloudflare

A read-only script now reads the firewall rules on all 64 zones in my Cloudflare account, so I can see each site's rule stack, whether it's WordPress, a site that isn't WordPress or a web app with a database, and how those differ. The rules came from Troy Glancy's free Cloudflare WAF Rules V3 guide. If you run sites on Cloudflare, start there, and look through the rest of his resources too.

8G and staging copies

When I first set up 8G in watch mode, I could see one problem coming. It hit the first time I moved a production site to staging: GridPane's staging copy takes a site's two 8G files without the rules they load, and nginx shut down. 8G Helper's GridPane guide now warns about it, checks nginx's config first, and has a read-only check and a fix, tested on a reproduced copy.

New on Matchless Web

Two posts went up on Matchless Web: Is Your Website Agent-Friendly? A 10-Point Checklist on Monday, and ChatGPT SEO: How to Get Your Business Recommended on Sunday evening.

What's next

The rural health clinic site I mentioned last week was held back. It should go live this coming week, with its case study a little later.