Building a template
A template is data, not code
The single most important thing to know: a template is a structure of blocks, not a bundle of code. You build it in the site builder, and what ships is a description of the page — which blocks, in what order, with what styling — rather than HTML and JavaScript you wrote.
That is a deliberate limit, and it is the reason strangers can install your work on a live business's website at all. A template cannot run code on a buyer's site, because there is nowhere for code to live. Nobody has to read your JavaScript and hope.
It also means some things you might reach for in a hand-built site are not available here, and asking for them will not help:
- no
<script>, no custom JS, no third-party widget embeds - no external stylesheets, and no
@import - no linking images or fonts from another host
This is not a rule we plan to relax. Everything else about the marketplace — one-click install, review that completes in hours rather than days, a buyer trusting an unknown creator — rests on a template being unable to execute anything.
What you build with
Layout and content blocks — boxes, headings, text, images, buttons and links. These are the ordinary building blocks of a page, and most of a template is made of them.
Connected blocks, which are the ones that make a template worth buying. These read or write the buyer's data:
| Block | What it does on the buyer's site |
|---|---|
| Contact form | Posts to the buyer's own forms |
| Saved form | A form the buyer already built |
| Sign in / Sign up | The buyer's own customer sign-in |
| Account status | What the signed-in customer sees |
| Notification banner | The buyer's announcements |
You place these like any other block. Do not try to point them at a specific form or site — leave them unbound. They are connected to the buyer's own resources when the template is installed, which is what makes one template work for every buyer.
A submission that arrives with a form id already filled in is rejected rather than cleaned up, because the only way to have one is to have taken it from somewhere.
Images and files
Every image has to be a file you upload with the template. You cannot link to an image on your own server or a CDN.
The reason is that a buyer's published site would then quietly make a request to your
host on every page view — which is a tracking signal they did not agree to and cannot
see. The same applies to url(...) in any styling, at any depth.
Upload the file, reference the upload. It is checked, including inside nested styling, so there is no version of this that slips through by being buried.
Styling
Style your template normally. On install, your classes are renamed to ids unique to that
buyer's site and merged into their stylesheet, so your .hero can never collide with
their .hero or with another template's.
You do not have to prefix anything defensively. Two different templates can both use
.hero and both keep their own styling.
Pages, navigation and the homepage
A template can ship as many pages as it needs, each with a path like /about or
/services/roofing.
Two things to expect on install, because they protect the buyer:
- An existing page is never overwritten. If they already have
/about, your page lands at/about-2and they are told. Links inside your template follow it automatically, so nothing breaks. - An existing homepage is never replaced. If you mark a page as the homepage and they already have one, yours is added as a normal page and they are told. They can promote it themselves.
Build it to be edited
Whoever installs your template is going to change the copy, swap the photos, and rename
things. Write placeholder copy that reads like a real sentence rather than Lorem ipsum,
and give blocks labels that say what they are.
A template is judged on what it looks like after a buyer has spent twenty minutes in it, not on how it looks in your demo.