Unblock didn’t start as Unblock. It started as a side effect of something else I was building.
A few years back I started the v2 cycle of WP Grid Builder , and one decision I made early in that rewrite ended up shaping everything that came after.
Where it started
WP Grid Builder needed a new card builder for v2. I had a few options on the table, and I picked the one that felt the most ambitious: rebuild it on top of the standalone block editor, the same @wordpress/block-editor package that powers Gutenberg, but mounted outside the post editor. Honestly I wasn’t sure it would hold up.
That decision looked small at the time. It wasn’t. The moment I started building cards as real blocks on a real block editor canvas, I started reaching for ideas that didn’t fully belong in a card builder. I wanted to let users pick the HTML tag of an element. I wanted CSS selectors to be a real thing, not a styling shortcut buried in a control. I shipped a version of both in v2, but constrained: a limited set of tags, a closed selector system scoped to the card.
It worked for the product. It also made obvious that the real idea was bigger than the product. WP Grid Builder v2 was where the idea showed up. Unblock is what happens when you stop trying to keep it inside one product.
What it grew out of
The shape didn’t come from page builders. It came from tools I’d been using for years.
Browser DevTools, mostly. There’s something about inspecting a live page, tweaking a value, and watching the page respond instantly that I’ve never really gotten over. No schema in the middle, no abstraction. You’re touching the thing itself.
CodePen pushed it further for me. Three panes, HTML, CSS, JS, all editable, all reflected immediately. The editor kind of gets out of the way.
But the tool that struck me the most was Bootstrap Studio . I wasn’t really a user, but I’ve had it on my radar since around 2016. It caught my eye because of how natural it felt, the same way DevTools does. It was the first visual builder I saw that didn’t hide the markup from me. You could see the tree, the elements, the attributes. It treated HTML as the source of truth, not as something the tool generated for you.
None of these were the answer for WordPress. But together they sketched out something I kept thinking about for years without really being able to name it. An editor that respects the standards underneath instead of inventing its own dialect on top.
One thing led to another
Once I committed to one block, one HTML element, CSS had to follow. You can’t have real elements and fake styles. So I went the opposite way from inline per block: selectors attached to blocks, stored globally, deduplicated, reusable.
In WP Grid Builder v2 that idea lived inside a closed system. A specific set of selectors, a specific scope, and a specific set of properties that are useful but bounded. In Unblock, I took the lid off. Any selector, any at-rule, any property, any variable, all tokenized and stored centrally.
Then AI showed up everywhere, and I started looking at the foundation with different eyes.
Then AI happened
Most plugins and builders invent their own dialect. A proprietary JSON schema. A custom binding syntax for dynamic data. A bespoke way of declaring styles. It works inside the tool, and inside the tool it’s often very well designed. But an LLM doesn’t natively know any of it.
Unblock had gone the other direction almost by accident. Real HTML, real CSS, composable elements all the way down. Every modern LLM already speaks that fluently, because it’s the language of the open web.
That was when I started noticing that AI features were easier to build than expected, mostly because everything was already expressed in standard web languages.
So the question for dynamic data became obvious. Don’t invent a syntax. Use one the LLMs already know. Twig was the answer. Fifteen years of PHP templating, popularized in WordPress by Timber, sitting in the training data of every modern model.
That closed it. HTML, CSS, JavaScript, Twig. Four standards, no proprietary syntax anywhere in the stack. And once the stack is standards, something nice happens on its own. Every property has a known shape, a known type, a known set of valid values. You can edit it as code, or you can wrap a UI around it. The two views aren’t really separate features. They’re two windows on the same data.
Not a replacement
For a while, in my head, what I was building was a replacement. That framing didn’t survive long. The more I built, the more I realized Gutenberg already had most of what I needed. The problem wasn’t the editor. The problem was that the editor was built for content, and I kept asking it to build pages.
Unblock plugs into the same APIs every block author uses. The blocks live in the same inserter. The patterns, the shortcuts, the templates: all of it stays. What Unblock adds is the standards layer underneath.
Where it stands
Unblock today is a standards-based engine that unlocks the editor for page building. Real HTML, real CSS, real expressions, all wired into Gutenberg. The engine is also the bridge between the AI and the editor: the model only ever speaks standards, and the engine translates that into blocks. One block, technically, since one is all you really need.
What comes next is more interface. The HTML and CSS sides already have a full visual layer in the inspector, in two-way sync with the code. The data side, loops, conditions, queries, will get the same treatment, step by step. Every standard has a known shape, which means every standard can have a real UI sitting on top of it. That’s the main aim of the Beta.
If you’ve read this far, you’re probably the kind of person I had in mind when building this. Try the demo, and tell me what you’d like to see next.