u/No-Leading6008

We live in duality!

We live in duality. There is no darkness without light. So is good and evil Sadness and happiness Poor and the rich Beauty and ugly It's important to understand the Michael Angelo effect Michael sees the ideal form in a rock and sculpts the excess and brings out what he wants. Similarly you encourage what's best within you or someone to bring out the best within them. Now, the negative side also plays an important role. It brings out the shadow side that needs to be enlightened, something you need to fix. A healthy relationship( it doesn't matter which relationship) doesn’t just accept who you are now—it actively helps you become who you want to be. Some relationships highlight/trigger your traumas that needs some attention so you can fix it. Both are the sides of the coin. Both have equal importance. No matter what you choose your enlighten something...

reddit.com
u/No-Leading6008 — 5 days ago

For a couple of months I have been sharing my ideas and have finally built it. It's more than an MVP stage (releasing it as opensource unde GPL2).

Topics:

Blocks don’t scale --> every developer implements them differently

Design systems decay  -->   tokens exist but nothing enforces them

Performance becomes a post-build activity

Junior devs unintentionally break global consistency

Every project slowly drifts from its original system

Maintenance never actually ends

These are real issues that developers and agencies face. Yesterday someone posted this( https://www.reddit.com/r/ProWordPress/comments/1sy576c/are_people_actually_leaving_wordpress_or_just/ )

The idea was to minimise the maintenance and build a system to create consistency in development. The usual way is to install WordPress, download a relevant theme or build one from scratch. Then build or use theme builders to create blocks.

The issue with this approach is different developers work on the same website and each has their own style of development. No consistent method of development, no color consistency using tokens, no panel consistency in inspector controls.

I have attempted to fix these issues by creating a system using a plugin.

It has the following:

Token registry

Element JS registry

Panel registry

Website structures

Basic optimization as per hosting

Before I explain each registry or feature I want to let you know who this system is and is not for.

This system is not for someone who loves to use website builders, or who needs no restrictions using colors, spacing or any restrictions regarding branding or structure. This is definitely not for someone who used 20-30 different variations of color red in different blocks.

This system is for someone who is conscious about branding, colors, spacing, borders and strives for consistency in development as well as the website they create. This consistency is mostly seen in agencies, medium to large teams or a few really good developers who are serious about branding.

Let's go through each registry and know what problem it solves.

  1. Token registry

Problem/solution statement: Branding consistency solved using tokens

Tokens are not new. They help maintain consistency not just in colors and fonts but also in spacing and more. We have 141 tokens assigned to colors, fonts, spacing etc. Additionally there are 50 more tokens that you can assign as needed.

  1. Element JS registry

Problem/solution statement: Repeated UI elements reimplemented in every block, solved using a shared element registry

Most block setups rebuild the same things like buttons, icons, and wrappers inside every block separately. The Element JS registry is a shared collection of reusable JS components that any block can use. This means less repetition, consistent behavior across blocks and one place to update something when it needs to change.

  1. Panel registry

Problem/solution statement: Inconsistent inspector controls across blocks, solved using a shared panel registry

Without a shared standard every block ends up with its own inspector panel built differently and laid out differently. The Panel Registry brings all block controls under one structure. Panels are registered once and reused across blocks so the editing experience stays consistent for developers and content editors regardless of which block they are working in.

  1. Website structures

Problem/solution statement: Starting every site layout from scratch, solved with prebuilt structures that follow the token and block system

wpTruss ships with foundational website structures which are layout patterns for common page sections. These are built on top of the token and block system so they inherit all branding decisions automatically. Teams can put together structured, on-brand pages faster without needing to build from zero every time.

  1. Basic optimization as per hosting

Problem/solution statement: Generic asset loading that ignores the hosting environment, fixed with basic hosting-aware performance defaults

A plugin that works well on managed WordPress hosting may not behave the same on shared hosting. wpTruss applies basic performance optimizations based on the hosting context, adjusting how assets are loaded and cached. It is not a full performance suite but it makes sure the foundation is sensible out of the box.

reference to previous posts regarding this system:

https://www.reddit.com/r/ProWordPress/comments/1s1h7bw/wordpress_blocks_dont_scale_we_built_a_registry/

https://www.reddit.com/r/ProWordPress/comments/1rtic2b/what_if_gutenberg_blocks_had_to_pass_validation/

https://www.reddit.com/r/ProWordPress/comments/1recqs4/preventing_design_entropy_in_gutenberg_projects/

https://www.reddit.com/r/Wordpress/comments/1rckzzf/rethinking_wordpress_as_an_operating_layer/

Im open to answer your questions regarding it.

(validator rules, architecture decisions, tradeoffs, where this might not fit, etc)

u/No-Leading6008 — 8 days ago
▲ 1 r/woocommerce_Stores+1 crossposts

After working on multiple WordPress projects (agency and product), we kept running into the same pattern:

Not bugs. Not plugin issues. Structural problems. The recurring problems

Blocks don’t scale. Every developer implements them differently Design systems decay. Tokens exist but nothing enforces them Performance becomes a post-build activity Junior developers unintentionally break global consistency Every project starts from scratch again Maintenance never actually ends

What we tried

Guidelines, code reviews, naming conventions, documentation: None of it held.

Because the problem wasn’t discipline. The problem was lack of enforcement.

What we changed: Instead of adding more process, we asked:

What if WordPress simply didn’t allow inconsistency in the first place?

That led us to build an internal system, now called wpTruss, with a few hard constraints.

  1. Blocks must pass validation before they exist

We added a Block Validator with 12 rules. No hardcoded colors. Must use tokens

No global CSS leakage. Must be scoped. Required structure enforced. No almost correct blocks allowed

If it fails, it does not register.
Result

You don’t review blocks anymore. The system rejects bad ones upfront.

  1. Tokens are not optional

We implemented a Token Registry: colors, spacing, typography, radius and shadows Blocks do not store values. They reference tokens. So when a client says Change brand color

You change one value and the entire system updates instantly.

  1. Structure over theme

We removed the idea of a theme. Header is a block. Footer is a block. Templates are block compositions

Everything is built using the same system. No theme lock-in. No builder dependency. Just structured blocks assembling the entire site.

  1. Elements are centralized

Instead of every block redefining headings, buttons, and images, we created an Element Registry in JS.

Each element: resolves tokens, enforces consistency, behaves predictably everywhere. So a button is not 17 variations across blocks. It is one system-controlled element.

  1. Performance is not optimized. It is produced

We built an Asset Bundler that: loads CSS and JS per page, only what is used, combines and minifies, automatically, injects proper image attributes, defers JS by default, We did not build this for PageSpeed.

But the output consistently hits:

95+ out of 100 without any performance plugins

Even with:

WooCommerce, AJAX, infinite scroll microstore blocks,

  1. Blocks became more than content

We started building micro-app blocks.
Example

A single block that: loads products, infinite scroll, AJAX cart, cart updates, checkout flow(default woocommerce)

This is essentially a mini storefront inside one block.

It still scores 95+. What this changes in practice, Rebrands take minutes instead of days, New projects import a system instead of rebuilding it, Junior developer risk is structurally eliminated, Performance is no longer a separate phase, Maintenance is close to zero, Or more bluntly, The system removes the need for being careful.

Why we are sharing this now

Over the past few weeks, we have been discussing parts of this problem here:

block scaling, validation, design entropy, WordPress as an operating layer

Those discussions led to this system.

If you want context, here are the earlier threads:

https://www.reddit.com/r/ProWordPress/comments/1s1h7bw/wordpress_blocks_dont_scale_we_built_a_registry/

https://www.reddit.com/r/ProWordPress/comments/1rtic2b/what_if_gutenberg_blocks_had_to_pass_validation/

https://www.reddit.com/r/ProWordPress/comments/1recqs4/preventing_design_entropy_in_gutenberg_projects/

https://www.reddit.com/r/Wordpress/comments/1rckzzf/rethinking_wordpress_as_an_operating_layer/

Where it is now, This is not a concept anymore.

It is running. Who this is for: Not beginners. Specifically: agencies, product teams, developers working with Gutenberg at scale

If you have ever said: Why does every project slowly fall apart

This is our answer.
Open to questions

Happy to break down: validator rules, architecture decisions, tradeoffs, where this might not fit

No fluff. Just what we have learned building it.

reddit.com
u/No-Leading6008 — 9 days ago