Patterns normally live and die on the site where they were made. A patternbuilderwp.com account gives your patterns a home between sites: upload from one into a collection, install onto any other, images and all, and draw on the collections Twenty Bellows and partner studios publish. Everything happens inside wp-admin, and Pattern Builder is the only way to install anything from the cloud.
Connecting an account
Open the Uploaded tab on the Pattern Builder screen. If no account is connected it offers two forms: Sign in & connect for an existing account, and Create account & connect, which asks for an email address, a password, a display name and a handle — the permanent name your account publishes under, and the first part of the name of every pattern you share. Either way you never leave wp-admin. Every new account starts with one collection, Personal: private, and always there.
A connection belongs to a WordPress user on a site, not to the site. Two administrators on the same site connect their own accounts, and your account follows you to every site you work on. Disconnect, on the same tab, removes the connection from this site; the account and everything in it are untouched.
Under the hood, your credentials go to your own site’s server, which relays them to the service and keeps only the access token it gets back. The browser never talks to patternbuilderwp.com directly, credentials are never stored or logged, and every cloud request from then on passes through your site with the same nonce and capability checks as any other admin action.
Uploading a pattern
Once connected, every local pattern’s Pattern Source panel, in the details sidebar and in the editor, gains an Upload to the cloud button. Theme or user makes no difference: the pattern’s markup, metadata and images travel together, and the service stores its own copies of the images so the pattern never depends on the source site staying up.
Every uploaded pattern is in exactly one collection. With only Personal, nothing is asked. With more, the panel asks which one, offering the collection you used last and New collection… inline (collections of your own are a Pro feature; a free account has Personal); when the target is a published collection it says so, since the pattern will be listed the moment it passes the checks. A pattern stays in the collection it was uploaded into: its collection is part of its permanent name, so there is nowhere to move it to that would still be it. Want it somewhere else, upload it there.
After an upload the panel tracks the pattern. Edit it locally and the button becomes Update pattern on the cloud; leave it alone and the panel says the cloud copy is up to date. A pattern you installed from someone else’s collection is linked to its source but is never offered an update, since the cloud copy is not yours.
What can travel
- Images in JPEG, PNG, GIF or WebP, hosted on this site. Every reference is found: an image block’s URL, a cover’s background, a CSS
url(). An image on another host, or in a format the package cannot carry, stops the upload with that URL named, so nothing is published half-working. - Markup, not code. Attachment IDs and
wp-image-Nclasses are dropped on the way out, since they name nothing on another site. The service takes core blocks whose output comes from their own markup and attributes, and refuses anything that runs code or embeds somebody else’s page: the custom-HTML block, shortcodes, classic content, embeds, RSS and the widget blocks. A pattern file’s ownCategories:header travels along as classification for the inserter; which collection the pattern goes into is a separate question. - Headers, footers and whole pages. Blocks that render the site they land on travel too — the site title, logo and tagline, navigation, a page list, breadcrumbs, search — and so do the Query Loop and the post fields inside it. They show the destination’s own content, which is the point of putting them in a pattern: a header shows that site’s name, a loop that site’s posts. A navigation carrying no links of its own falls back to the site’s menu or its pages.
- Nothing that names a row on your site. A reusable block is a post ID and a template part is a slug in your theme, so neither resolves anywhere else and neither travels. For the same reason a navigation’s link to a menu you built, and the page IDs on its links, are dropped on the way up — the pattern keeps the links themselves, and the site it lands on decides what they point at.
- The WordPress a pattern needs. Some blocks are newer than others, so every pattern records the version it needs, worked out from the blocks it actually holds. Pattern Builder says so before you install one and refuses if the site is older, because an older WordPress does not merely fail to draw markup it does not know — it can strip it out, leaving a pattern that looks installed and is missing part of itself.
Upload is gated on validity
Markup that a block would not have written itself renders fine on the front end and reads as “unexpected or invalid content” the moment an editor opens it. Only a browser can tell, because a block’s save function is JavaScript, so Pattern Builder checks in the browser before uploading: it parses the saved markup with the editor’s own parser, and if any block is invalid the button is disabled and the offending blocks are named. Markup that is valid but in an older form (usually a missing block-supports class) gets a warning instead, since it renders, and a block this site does not have is left to the service’s allowlist.
Installing a pattern
Select a tile in the Uploaded tab, or open a collection in the Directory tab and select a tile there, and the details sidebar offers Save, with a choice of destination: Theme writes a pattern file into the active theme, User creates a database pattern. Images are fetched from the service and placed to suit: into the media library with the blocks pointed at the new attachments for a user pattern, or into the theme’s assets/images directory for a theme pattern, so the theme stays self-contained. The markup is sanitized again on the way in.
An installed pattern is an ordinary local pattern from that moment on: editable, convertible, deletable, with no live link back to the cloud. One installed from a directory collection also carries a local pattern category named for that collection, so the inserter and the Pattern Builder grid show where it came from. Select the same cloud pattern later and the sidebar recognizes it is already installed and offers Edit instead.
Installing a whole collection
A directory collection’s page has Save collection to this site. It asks once where the patterns should land, checks once which design tokens the whole collection needs that this site lacks, and then installs the patterns one after another with a running count. Patterns already installed from that collection are skipped; if one cannot be installed, the rest still are and the failures are listed at the end. A premium collection asks for Pro before any of it.
Design tokens
A pattern written against one theme’s palette and spacing scale may name presets this theme lacks — and a colour a theme has never heard of does not fall back to something sensible, it renders as no colour at all. So a pattern carries its tokens with it. On the way up, every preset the markup references is looked up in the site that wrote it and its value is packed alongside; on the way down, Pattern Builder compares that list against this site and shows you what is missing: colours, gradients, font sizes, font families, spacing.
Add tokens & save writes only the missing ones into the destination you already chose — the theme’s theme.json for a theme pattern, Global Styles for a user pattern. Tokens you already have are never touched, even when the incoming pattern defines the same slug differently: your primary stays your primary, and the pattern adopts it. That is usually what you want, and it is why an installed pattern looks like it belongs to your site rather than to the one it came from.
Block styles
Tokens are only one of the three layers a pattern can lean on. The second is a block style variation — a named look you pick from a block’s Styles panel, like a card treatment on a Group or an outlined variant of a Button. The markup only carries the class, is-style-card; the definition lives in the theme it was authored in. A pattern that travelled without it would arrive with the class intact and nothing styling it, which looks exactly like a broken pattern and is hard to diagnose.
So variations travel the same way tokens do. Pattern Builder collects the ones your markup actually applies — only the ones your theme defines, since a style that ships with the block itself is already on every site — and packs their definitions. On install they are written into the active theme as style files, and, as with tokens, only the ones the destination lacks: a variation you already have under that name is left alone.
Two consequences worth knowing. Variations always land in the theme, even when the pattern itself is going to the database, because that is the only place WordPress lets a theme register one. And a variation’s name is shared ground — two designers can both call something button-secondary — so a variation is renamed as it goes up, stamped with the account and collection it is published from, and the class in the markup is renamed to match. You author under the short readable name; the long one only exists on the cloud and on sites that installed from it.
A variation may also carry a little literal CSS, for the things a style panel cannot express: a hover state, a pseudo-element, a rule about the block’s children. That CSS is checked against a deliberately small, strict subset of the language three separate times — when you write it, when the service stores it, and again on the machine that will run it — and anything outside that subset is refused with the offending fragment named, rather than quietly stripped. If a variation arrives carrying CSS the destination refuses, the pattern still installs; you lose that one look and are told so.
Patterns that use other patterns
A page pattern is usually not one pattern. It is a hero, a feature band, a testimonial and a call to action placed one after another, with the page itself holding only the words. That is the point of building a site this way — change the feature band once and every page using it changes — but it means a page pattern on its own is an empty shell.
So the tree travels, both ways.
- Uploading takes what the pattern uses. Upload a page and Pattern Builder walks its references, and their references, and uploads all of them into the same collection, innermost first. The panel tells you before it starts — “Uploads 5 patterns”, and it names them — and where one already exists in that collection it says so, because updating a shared section changes every page in the collection that uses it.
- Installing takes them too. Install the page and its sections arrive first, so it renders fully from the moment it lands. Sections already on this site under the same name are skipped rather than duplicated, so a second page from the same collection is cheap.
- Sections land as theme patterns even when you send the page to the database, because a reference can only resolve to a theme pattern. The page goes where you asked; its parts go where they will work.
Everything is decided before anything is sent. An upload stops, having sent nothing, if a pattern references one you do not have locally, if two patterns reference each other in a loop, or if the tree would not fit in a Personal collection at its limit. You get one message naming the problem rather than half an upload to clean up.
Where a pattern came from
Install somebody else’s pattern and it is stamped with their name for it — an Origin in the pattern file, shown in the Pattern Source panel and on the pattern’s page here. It survives editing, converting between theme and user, and uploading your own version somewhere else, however many times that happens. A pattern is never stamped with your own account, so the line always credits somebody else’s work, and there is no button to clear it.
That is separate from the Cloud link, which records your copy of a pattern so the panel knows to offer Update pattern on the cloud rather than Upload. A pattern can have both: somebody else’s work that you have published a version of. Nothing about that link is remembered between sessions — Pattern Builder asks the service each time — so a pattern you deleted from the cloud, or a collection you removed, reads as not uploaded rather than leaving anything stale behind. Delete from cloud, in the same panel, removes the cloud copy and clears the link.
The directory
The Directory tab opens on collections: every published collection as a tile, with its publisher and how many of its patterns this site already has. Search shows matching collections first, then matching patterns, each naming its collection. Publishing is by invitation — Twenty Bellows and the partner studios it works with — so everything there is curated; Collections has the rules. This website shows the same collections at /collections/, for browsing; installing happens here, in Pattern Builder, never from the website.
Free and Pro
A free account keeps up to 25 patterns in Personal, connects as many sites as you like, and installs every free collection, pattern by pattern or all at once. Nothing you upload is ever public. Nothing is ever held hostage either: at the cap you can still browse, install and delete everything in Personal; you just cannot add a 26th pattern to it until you delete one, or upgrade.
Pattern Builder Pro — $9 a month or $89 a year — removes the cap on Personal, adds private collections of your own, and unlocks the premium collections. It is a subscription on your patternbuilderwp.com account, not a licence for the plugin, so it applies on every site you connect. The Go Pro and Manage billing links on the Uploaded tab go to your account. Cancelling keeps every installed pattern working (they are ordinary local patterns) and keeps your collections readable and installable; nothing more can be added to what is then over the free limits. See Pro for what it includes.
Without an account
Everything else in Pattern Builder works with no account at all. The cloud is an addition, and a disconnected plugin simply has two fewer tabs.