I have been working on a question that kept coming up whenever I built a static site: could I keep the speed and simplicity of static HTML, but still have a proper shop behind it? I wanted real products, prices, stock, checkout, orders and customer accounts. I also wanted to use the same WordPress installation for several independent sites without turning every shop into a copy of the same front end.
That has become Static Cart, a small WordPress plugin that sits alongside FluentCart. I want to be clear at this point I have no intention of releasing static cart, I am testing it site by site, but the working model is now clear enough to explain. The static site is the shop window. FluentCart is where the products and commerce rules live. Static Cart connects the two.
How the pieces fit together
Each site is ordinary HTML, CSS and a small amount of site-specific JavaScript on its own domain. The pages load one shared browser script from the WordPress installation. That script calls Static Cart’s REST API using the site’s key, receives the products and configuration for that storefront, and fills the page. It also starts checkout and powers the customer account.
Inside WordPress, FluentCart remains responsible for the important bits: variation prices, billing, stock, tax, shipping, coupons, payment gateways, orders, subscriptions and downloads. Static Cart exposes the fields the public site needs and connects a checkout to a real FluentCart cart. It does not ask the static HTML to calculate a total or decide whether an item can be purchased.
A single WordPress installation can serve several storefronts and in testing I am not up to nine. Each has its own public site key, allowed origin, plan keys, branding, account URL and field mappings. The originating site key is kept with checkout and customer ownership data, so orders and account records stay with the right storefront even when two sites happen to use the same FluentCart variation.
The specification was agreed early on but there where some changes detailed below.
One of the guiding principles came out of a conversations myself and Vitalli from the brilliant https://craftformswp.com/ had about a secure WordPress backend our approaches differ but the idea is identical.
WordPress is brilliant at being WordPress it doesn’t have to be the frontend we can secure it, restrict access and do all the normal stuff but leave limited scope webhooks and rest-api routes open to allow functionality.
The mappings were the key
My first versions relied on more internal binding instructions. That became awkward as the sites grew. One site might put a product image above the title; another might use a gallery beside the variations. If the shared plugin knew either site’s CSS classes or layout, every new design would mean another plugin change.
Now the storefront has saved field mappings. Each mapping says which data field or action belongs to a selector in that site’s own HTML. For example, a Product mapping can put product.name into a heading, set the src of an image, or identify a button as the action for a variation. Product, variation, and gallery lists use direct-child HTML templates that the browser script clones when the catalog arrives.
{"scope":"product","type":"content","role":"",
"selector":".product-name","template":"{{ product.name }}"}
That row is only an example. The selector belongs to the static site, and a different site can use a completely different one. The plugin supplies the data and behaviour, while the page controls the presentation.
The mappings and storefront settings are exported as one complete JSON file. This was an important change. A site now has two things to move together: its static files and its matching import. The JSON includes the site key, allowed origin, plan-to-variation links, gateway choices, brand details and every mapping for the catalog, checkout and account. It is a complete replacement when imported, so adding eight Product mappings means keeping the existing Checkout and Customer rows too.
What testing taught me
HarborLink was a useful example of why this matters. The API had a product and three plans, but the page still said packages would appear when the product was connected. The missing piece was not more product data. The page needed its Product mappings so it knew where to put that data. A full JSON import with those mappings repaired the connection. Now I already knew this but as the project grew AI become more and more a part of it and as I was building and testing new sites I was refining my AI Builder instructions, it was easy for me to correct as the human and developer but why should i?
Atlas Supply pushed the idea further. Instead of a few fixed plan cards, I built it as a larger shop test with multiple products and variations, a catalog, product page, basket, checkout, and account. The catalog reads names, images, galleries, prices, compare-at prices, attributes, and stock from FluentCart. Draft products are omitted from the public catalog. Out-of-stock variations can still be shown, but their purchase buttons are disabled, and checkout checks availability again in case an old page or saved basket is out-of-date.
The account test found another gap. A customer had purchased a digital product and the order knew a download existed, but the static account page had nowhere to display it. Once I added a downloads repeater and the matching Customer mappings, the file appeared and could be downloaded. I have since tested Atlas orders containing both physical and digital products and confirmed the download path from the account. It was a good reminder that having the data in the API is only half the job: the static page also needs a mapped place and action for it and this again became an iteration of the AI Documentation.
Variation IDs were another lesson. An import can use 0 as a placeholder while creating a new storefront, but it cannot do that when replacing a live one. The live export and the actual FluentCart variation IDs have to be preserved. Otherwise, the new HTML may be perfect while the plans point at nothing useful.
Checkout still belongs to FluentCart
For a single product, the browser script starts checkout with a site key and plan key. For one-time products, it can also send a basket containing several mapped variations from the same storefront. FluentCart builds the native cart, supplies shipping methods when physical products need them, applies its coupon and tax rules, and calculates the final amount. Subscription variations use the separate single-plan flow rather than being mixed into that one-time basket.
The static checkout collects the customer details and presents the gateways enabled for that storefront. Payment, order creation and entitlement decisions remain on the WordPress side. Once an order is paid, the customer page can show orders, receipts, downloads and, where applicable, subscriptions and licences. Each storefront also carries its own customer-facing brand and email settings.
Building the next site with AI
Because every site has its own HTML and selectors, I wanted an AI builder to produce the site and its import in the same session. The documentation now gives it the API fields, supported mapping roles, required checkout and account hooks, JSON layout and a validation checklist. It should deliver the static pages, assets, and one complete format version 2 JSON import, then report any selectors or variation IDs it could not resolve.
The input still matters. I need to give it the exact static and WordPress hosts, the site key, brand, and design brief, product, and variation details, gateway choice, checkout requirements and the account features I want. For an existing site, I also need to supply the latest full export and current static files. The import configures a storefront; it does not create FluentCart products, media, shipping rules or payment credentials.
There is every chance in future it could with an MCP connection, the Video at the end of this article shows Codex building a site from a brief. All I needed to do, it was very little creating and mapping the 6no variants but an MCP could do that and with the right skill the mappings and gateway mapping too.
Where I was.
The architecture was working, and Atlas has given me a useful end-to-end test of a mixed physical and digital order. I am still testing the other storefronts and the less common paths: shipping classes, add-ons, coupons, failed payments, the other gateways, subscription actions and branded mail. A larger catalog will also need proper paging and category or brand filters, and I want a richer product page where selecting a variation changes the main image and gallery.
What I like about the approach is that I can change the shop design without teaching the commerce plugin a new layout. I can also improve the commerce side without rebuilding every static page. Getting there required more attention to imports, ownership and the account experience than I expected, but those were exactly the things the test sites were meant to uncover.
What I fixed next.
There was problem I couldn’t fix right now and that was payment separation, its all good and well having separate sites and email identity but the payment gateways where limited I began to work on this next.
I considered this an issue outside of static cart this has use outside of this project so was building it as ad don the same for a model checkout customise because they have applications beyond static cart.
I had a conversation while developing this with a developer Gaurav who’s extension I use for Woo and FluentCart and he said these where on his list of things to develop for his awesome GT-Extensions plugin. I was already mapping additional product information and checkout information from GT-Extensions in Static Cart it just makes sense.
So I shared what I had been working on with him and left him to cook his implementation hoping the research and prototyping I had done was useful and within about a day he had a beta of those modules for me to test.
So I now had separate repeatable gateways which means each store can have its own Paddle account for example, inbuilt support for Polar too.
I wasn’t sitting around either while this was being build I was perfecting the AI instructions and testing my first Astro Build using https://phantomstudio.app/ I finally got to the point where I could publish what had been achieved in a video.
This video shows you three AI built stores, all working from a single FluentCart Installation from an end user perspective they are three separate stores. Each needed a different level of integration from me to get working but they each do different things and have different products and requirements but they all work from that central still protected backend.
Every iteration of StaticCart has had my Thanet Digital lockdown Plugin in front of it every single time.
Which leads us to the now
I am pretty sure this experiment for me is pretty much coming to an end, I have set out to prove my theory to be the first truly static FluentCart Integration something to be celebrated especially given its only just 1 year old.
I have no intention on releasing StaticCart this sort of project needs a different type of developer. I have shared the source with Gaurav and maybe he will add it as a module to GT-Extensions, and I’d love to see a push by WPManageNinja to add it to core, and to be the one to inspire this. I set out to prove something was possible and kept building on it but I now need to leave it behind I have proven its ability and its worth and even how I would approach it. Will I use it? Maybe I will but I am not going to release it, it wouldn’t be fair for people to build a site on it without the support of a developer that has that time.
With my current level of free plugins, my paid work and my TechArticles videos and blogging I really don’t have the time to support such an integral piece of e-commerce infrastructure.
Ironically built for an AI world which will replace the very plugins I do make and support, improvements, and features for popular plugins. In an AI driven world there is just less need for what I produce but I don’t feel a pivot into technical support for a plugin of this nature is on the cards for me.
As a special treat for reading this you get to see what at this point I assume will be the last video in this series it shows me using Codex to make a full site with Static Cart, Publish it and make a purchase. I really hope to see someone take on the mantle of StaticCart and I have thoroughly enjoyed the work and pushing my ability along the way. I can now say I know FluentCart its APIs and its functions as well as I know SureCarts now.
So in closing a bleated happy birthday to FluentCart, I hope you enjoy what I’ve done here and thanks for the awesome developers that have assisted, and inspired me in getting this far with this experiment.
