GenerateBlocks 5.8 Changes

GenerateBlocks has a new release and it talks about “design tokens” for me a token is an alternative to a real coin. You buy a token to activate the vending machine because they do not want to keep changing the mechanism to cope with price changes. What does a token mean in a website context.

Your vending machine analogy is spot-on. In web design, a design token works under the exact same principle: it acts as a fixed stand-in (a label or token) so you don’t have to rebuild or manually update every element when an underlying value changes.

In a website context, a token is a human-readable nickname for a raw design value—like a specific hex color code, font size, spacing measurement, or shadow effect. Design tokens map visual style values to reusable names, AI generated

Design tokens map visual style values to reusable names. Source: Contentful

How It Works in Practice

Instead of hardcoding a raw value like #1770E5 or 16px across dozens of buttons, headings, and cards, you give that value a standard name (a token).

Raw Value	Traditional Approach	Design Token Name
`#1770E5`	Hardcode `#1770E5` on every button	`color-primary`
`16px`	Set `font-size: 16px` on body copy	`font-size-md`
`24px`	Set `margin-bottom: 24px` everywhere	`spacing-lg`

The “Vending Machine” Benefit in GenerateBlocks

Just like changing the value of a physical token lets you adjust prices without modifying every vending machine’s inner coin mechanism:

One Central Update: If you decide to rebrand and change your primary color from blue (#1770E5) to green (#00A86B), you only update what color-primary stands for in one place.
Automatic Cascade: Every block, button, header, and container set to use color-primary updates instantly across your entire site.
Consistency: Designers and developers don’t have to remember exact hex codes or pixel numbers—they just select the relevant token.

In GenerateBlocks, design tokens let you manage global styles centrally, ensuring site-wide consistency and making future style tweaks fast and safe.

I would call a design token a class and if you only wanted to use it once ID is this just a name change for classes?

No, design tokens are not just a name change for CSS classes or IDs. While both classes and tokens help manage styling, they exist at different levels of design architecture and serve completely different roles.

The Core Difference

Think of it like building a house:

Design Tokens are the Raw Materials (e.g., Red Brick, Oak Wood, Tempered Glass). They define what values are available.
CSS Classes are the Components/Blueprints (e.g., Sidebar, Primary Button, Feature Card). They define how elements are constructed using those raw materials.

Design Token (Raw Value)
  └── color-primary = #1770E5
        │
        └── Used inside a CSS Class (Component)
              └── .btn-primary { background: var(--color-primary); }
                    │
                    └── Applied to HTML Elements
                          └── <button class="btn-primary">

Token vs. Class vs. ID Comparison

Feature	CSS ID (`#header`)	CSS Class (`.btn`)	Design Token (`--color-primary`)
What it is	A unique element identifier	A bundle of styling rules	A single design value/variable
Scope	Targets 1 specific element	Targets a group of elements	Extends across styles, classes, theme options, and design tools
Content	Multiple CSS properties	Multiple CSS properties	Exactly ONE value (color, spacing, font size, etc.)
Reusability	Unique (1 per page)	High (applies to many HTML tags)	Universal (can be used inside classes, inline styles, or global settings)

Why Classes Alone Aren’t Enough

If you rely solely on CSS classes, you run into three main limitations:

1. Classes Bundle Multiple Properties Together

A class like .card might contain background color, padding, border radius, and font sizes. A design token represents a single atomic variable (e.g., spacing-md = 16px). You can use the spacing-md token inside .card, inside .btn, and inside .nav-item.

2. Tokens Connect Design Software to Code

In tools like Figma, designers don’t use CSS classes—they set color palettes, typographic scales, and grid spacings. Design tokens act as a shared language that syncs directly between visual design tools and code (like GenerateBlocks or CSS variables).

3. Tokens Power Block Builders Beyond CSS

In GenerateBlocks and modern WordPress block builders, tokens feed into UI pickers. When you select a color or spacing setting in the sidebar editor, you are choosing a token value directly rather than typing raw CSS class rules.

No, changing the design token on your second site will not affect the first site automatically, because each WordPress website operates on its own separate database and file structure.

Here is how design tokens actually behave across multiple website installations:

1. Each WordPress Site is an Independent “Container”

When you use a base site/template (wpbase) to set up Site A (domain-a.com) and then later set up Site B (domain-b.com), you create two completely separate copies.

Site A (domain-a.com): Has its own database, its own GenerateBlocks settings, and its own set of design tokens.
Site B (domain-b.com): Has its own independent copy of those same settings.

                  [ wpbase Template ]
                   /               \
                  v                 v
      [ Site A: domain-a.com ]   [ Site B: domain-b.com ]
      color-primary: Blue        color-primary: Blue
              │                          │
      (Change to Red)             (Remains Blue)
              │                          │
              v                          v
      [ Site A is now Red ]      [ Site B stays Blue ]

2. What Happens When You Change the Token Value

If you go into the GenerateBlocks settings on Site A and change color-primary from Blue (#0000FF) to Red (#FF0000):

On Site A: Every block, container, and CSS class using color-primary will immediately change from Blue to Red across all pages of domain-a.com.
On Site B: Nothing changes. domain-b.com keeps its own color-primary set to Blue.

3. When WOULD a Token Change Affect Both Sites?

A token change would only update both websites simultaneously if you are using a specialized multi-site setup or central management system:

WordPress Multisite: If both domains are sub-sites within a single WordPress Multisite network and share a global theme/CSS engine or custom multisite token plugin.
Centralized Design System Tools: If you are using an external design tool (like Figma or a Headless CMS/Design System API) that pushes token updates via code/webhooks to both sites automatically.

For standard, separate WordPress installations built from a site template or backup clone, site tokens remain completely local to the domain where you edit them.

OK so if I have a base template for a website which we will call wpbase and I apply that to one url and then a few weeks later I use the same base for another domain name. If I go to the Design Token I can change that from for simplicity of argument the first was color-primary was Blue to Red that would change all the CSS classes which used Blue to Red. My example was too brief I realise they both have different databases anyway I am now on board with Tokens and see why they have a different name to classes.

That clarity is a great milestone! It completely changes how you think about building and maintaining websites once that distinction clicks.

To summarize the relationship in one mental model:

Design Tokens are the ingredients (the core color hex codes, font sizes, gap widths).
CSS Classes are the recipes (how those ingredients combine to style a button, card, or navigation bar).
HTML Elements are the finished dish (the actual markup rendered on the page).

By decoupling the ingredients from the recipes, you get total flexibility. If you decide to tweak your primary color or bump up your site’s global spacing, you adjust the token once, and every recipe using that ingredient updates cleanly without you having to edit a dozen individual CSS classes.

When people announce new features – they overlook why you might want the feature and assume that you already know. Which if you have been coding something for months has escaped your attention.

You have hit on the single biggest blind spot in developer communications: “The Curse of Knowledge.”

When a developer or product team spends months building a feature, they are so deep in the implementation details that they experience cognitive collapse—they can no longer remember what it was like not to know why the feature matters.

This leads to feature announcements that focus entirely on what was built or how it works, while completely skipping why anyone should care.

Why Feature Announcements Fail

Most tech release notes suffer from three core communication breakdowns:

“What” vs. “Why” Shift: Creators announce the mechanism ("Added support for custom CSS variables in component wrappers") instead of the outcome ("You can now change your site's color scheme in one place instead of editing 50 separate elements").
Missing Problem Statements: They assume you are currently suffering from the exact same pain point they just solved, without reminding you what that pain point was.
Internal Jargon Bias: Teams adopt internal shorthand during development. When release day comes, they use those specialized terms (like “design tokens”) assuming the audience shares their exact vocabulary.

The “So What?” Test

Good technical communication bridges this gap by answering three questions in order:

1. WHAT IS IT?       --> "Design tokens"
2. WHAT WAS BROKEN?  --> "Updating global styles meant editing dozens of CSS classes manually."
3. SO WHAT?          --> "Now you can change one central value and update your entire site instantly."

If a release announcement skips step 2 and 3, it forces the reader to do the mental heavy lifting to figure out if the feature is even relevant to them.

How to Translate Dev-Speak into Value

When reading technical release notes, you can mentally translate their announcement patterns into real-world benefits:

What They Say (Dev-Speak)	What They Actually Mean (User Value)
“Refactored underlying DOM rendering engine”	The editor loads twice as fast and won’t crash on long pages.
“Added support for headless REST endpoints”	You can now pull your site’s content into mobile apps or third-party tools.
“Implemented fluid typography tokens”	Your text will automatically scale smoothly between mobile and desktop without manual breakpoint tweaks.

When you use WordPress and some of your clients update their own pages. Even if you are onboard partially you then have to potentially explain to the clients what is happening.

That is often the hardest part of agency or freelance work: you are not just building a site, you are also managing human expectations and client communication.

When WordPress pushes major structural features—like global styles, block patterns, or design tokens—it directly impacts client workflows. If a client logs into the dashboard and sees new settings, renamed options, or a shifted interface, it creates confusion and support tickets.

Why Client Hand-Offs Get Complicated

Feature Fatigue: Clients don’t want to learn how a site is built; they just want to edit text and swap images. Showing them advanced design settings (like tokens or CSS controls) causes anxiety that they might “break” the design.
Abstract Terminology: Explaining terms like Design Tokens, Reusable Blocks, or Flexbox Layouts to a non-technical client leads to eyes glazing over.
Loss of Guardrails: If clients have full access to global style tokens, they can accidentally change a primary brand color site-wide when they only meant to highlight a single word in a blog post.

3 Strategies to Manage Client Editors

1. Restrict What They Can Edit

Use WordPress role management and block locking to hide the technical controls entirely:

Block Locking: Lock down containers, grids, and global style settings so clients can only edit text and media contents.
Theme.json / Builder Permissions: Disable global design token editing for non-admin user roles (e.g., set clients to the Editor role rather than Administrator).

2. Translate Features into Actionable Rules

When you do need to explain a feature, explain the rule, not the technology:

What the Feature Is	How to Explain It to a Client
Design Tokens	“We have locked your brand colors into central switches. When you pick ‘Primary Blue’ in the editor, it guarantees everything stays on-brand.”
Block Patterns	“We built pre-designed content layouts for you. Just insert a ‘Testimonial Card’ pattern and fill in the text.”
Global Classes	“This style is linked across all service pages. Changing it here ensures all your service pages stay uniform.”

3. Provide a Single-Page “Brand & Editor Guide”

Instead of teaching them how WordPress or GenerateBlocks works under the hood, give them a simple 1-page reference cheat sheet inside their admin dashboard (using a plugin like Dashboard Notes or a custom admin page) that covers:

What user role they have.
Which color options to select for buttons vs. backgrounds.
Who to contact if they need a new layout built.