Posts

Insights, thoughts, and tips on product, design, and development. Pick a topic and start exploring.

  • Little Big Things for WordPress Editing

    Agentic workflows are taking a leading role in how we interface with WordPress, and that’s a good thing. But it doesn’t mean the editing experience has to stay difficult for the folks who want to sit down and build something, or make the tweaks that their agent can’t seem to narrow down.

    So these are a few “little big things” I’ve been exploring after coming back from paternity leave, all aimed at making it easier to edit in WordPress. None of them are big in scope, but they’re all about removing complexity that’s piled up a bit.

    Block Locking

    Right now, patterns inserted into a page get a kind of auto-lock, as a new construct introduced in WordPress 7.0, separate from content only locking. These two ideas are doing nearly the same job, but one is a bit difficult to comprehend while the other is only a technical know-how.

    My fix is to use the existing content only locking when patterns are inserted, while adding a layout lock option in the block lock modal. This gives authors a way to set the content only locking easily, while also adapting the behavior of inserted patterns to be either a function of locked, or unlocked, instead of something in-between.

    I also want to bring those lock controls into List View. The lock icon today is currently decorative: you see it and there’s nothing to do. My PR makes it useable, where you can select it to see a full list of locking functions when unlocked: lock movement, lock removal, lock layout. And a one-click unlock when the block is locked. No more hunting.

    Soon we’ll be able to remove the existing block locking modal entirely, when we update the block toolbar menu to use this same flyout, further reducing the UX complexity of locking to one click to see the options, and another to apply an option (in the same spot).

    Editing Synced Entities

    When you want to edit a synced pattern, a template part, or an inserted pattern, the editor currently routes you differently for each. You lose your sense of place. You’re no longer in the page you were composing; you’re in some other view, and you have to find your way back.

    My PR on unifying the edit/done interactions collapses these into one flow. Click edit, the selected block stays in focus while the rest fade out (spotlight mode), make your changes, click done (or anywhere else on the canvas).

    It’s the same interaction whether you’re working with a synced pattern, a template part, or a freshly inserted patter: a temporary unlock where you can make changes without loosing your place in the editor.

    Sure, if you want to go to the isolated view of synced entities, you can using the “Edit original” menu item (no change).

    There’s even more we could do here that isn’t in this initial PR. Right now only the parent of a synced pattern shows the purple sync indicator; everything inside it looks like regular content. It could be better for the whole synced subtree to read as synced. Also, the block card could carry a “Synced” badge instead of a “Pattern” badge (which I don’t think is useful).

    Those are small affordances, but they keep you oriented without sending you somewhere else to understand what you’re looking at.

    Zooming Out

    Zoom out has its own version of the same problem. It lets you see the page as a composition and rearrange it. Pattern insertion is part of that job, but the current flow doesn’t behave like the rest of the canvas. It opens the sidebar inserter, which slides your content over, and then you’re figuring out how to close it and get back to where you were.

    The fix is to stop investing a new UI/UX for the zoom-out interaction and reuse the existing Patterns Explorer modal. The page stays put, you pick a pattern, and you return to the same canvas. There’s no manual resetting necessary.

    The modal creates a clear, temporary selection state: open, pick, close, keep going. The standard blue insertion line handles drag and drop, so the separate “Drop pattern” strip goes away with this.

    I also added items to the block toolbar options menu, “Add before”, and “Add after” which opens the same Patterns Explorer at the correct insertion index. Those already exist everywhere, but instead of having a blank insertion point, when you’re working with patterns you’ll see patterns.

    The toolbar follows the same idea. “Change design” becomes “Replace”, and instead of opening a custom up-to-six dropdown of patterns in the toolbar, it opens the Patterns Explorer modal with the active category preselected.

    Again, just reducing the complexities and matching the expectations of the existing editing experience.

    Pushing these forward

    If you know me, you know I’m not precious my PRs. I’ve kicked off the efforts and I believe in the direction, but I don’t need to be the one who lands them (or becomes a bottleneck).

    If you’re a contributor, please pick these pull requests up, test, suggest/push commits, and take them over the line.

    Now that we have many of the pieces in place for WordPress, circling back and reducing complexity is the most important work we can do.

  • Just Another CMS

    You’ve heard about EmDash, Cloudflare’s “spiritual successor to WordPress.” It’s an interesting demo with some good ideas. But a successor to WordPress? Not quite.

    Why WordPress

    WordPress didn’t reach 42.5% of the web by being insecure. It got there because an open ecosystem creates more value than a closed one.

    The highlight feature of EmDash is its sandboxed plugin model, where plugins run in isolated environments. But that sandboxing only works on Cloudflare’s infrastructure. You can host EmDash elsewhere, but the security model doesn’t come with you.

    WordPress runs anywhere: a shared host, a managed provider, your own server. Whether you’re running your blog, a business, WhiteHouse.gov, or streaming Artemis II’s lunar flyby on NASA.gov to millions of people, WordPress is the CMS with proven scalability.

    Sure, it’s a dinosaur. But that’s not an insult.

    WordPress has 23 years of plugins, themes, documentation, and proven patterns. If you need a CMS, why would you run one that launched days ago, or even years ago?

    What we can learn from EmDash

    WordPress has agent skills, but the EmDash skills are more opinionated and workflow-focused. I particularly like the push for migrating WordPress plugins and themes. We can learn from these to progress Data Liberation further, adding more import paths from other sites and applications into WordPress.

    EmDash also ships a content modeling UI with custom fields and content types built into the admin. WordPress can do all of this with the Fields API, and AI is good at setting it up in code. But there’s no core UI for managing content types visually.

    We’ve explored a similar concept, but EmDash’s take is simpler, and that’s a gap worth closing.

    More broadly, WordPress needs a more opinionated developer experience. WP-CLI, Studio, Studio CLI, WP AI Client, and MCP Adapter are solid foundations, but there’s not yet a clear starting point that ties the technicalities of WordPress together.

    That ambiguity is fine for experienced developers who already know their way around, but it can be a high wall for our agents.

    EmDash made all those choices upfront because it could. WordPress has to get there by converging on the concepts that have built up over time. A proper front door.

    The actual competition

    Companies will keep launching CMS competitors aimed at WordPress’s market share. But the more interesting trend isn’t another new CMS.

    For the first time since W3Techs started tracking historical yearly trends, sites built without any CMS is trending up.

    I don’t expect a wave of people switching from WordPress to EmDash. But I am curious about the people who think they don’t need a CMS at all because they can vibe-code a static site in an afternoon.

    Even so, WordPress has been democratizing publishing for 23 years and will keep doing so for many more.

    New projects like EmDash are a reminder that complexity has a cost. When you start from scratch, simplicity comes easy. WordPress has to earn it with every release. 

    People are building with agents, and WordPress has to be incredibly easy for those agents to work with. That’s what EmDash gets the most right, and what WordPress could take pointers from.

  • A Red Pen

    Craft is caring enough to get the details right.

    Matthew Butterick argues this for typography in Practical Typography. Reader attention is finite. Every typographic choice you make either earns it or loses it.

    Readers judge your typography before they read a word. That’s how they decide whether it’s worth their time.

    Butterick made the case for typography. Orwell made it for prose in Politics and the English Language: no stale metaphors, short words over long ones, cut anything you can cut, active voice, no jargon, and break any rule rather than write something ugly.

    They’re different disciplines, but with the same instinct: sweat the details and respect the reader. These rules aren’t hard to follow themselves, but doing them consistently, on everything you publish, is.

    So I built an agent skill that runs in Claude Code and Cowork.

    Agent skills are folders of instructions and resources that agents can discover to do things well (like editing).

    "Screenshot of the Claude.ai chat interface showing a greeting that reads 'Good evening, Rich' with the Anthropic logo, and a message input field containing '/red-pen I have a post I'm drafting. Mind checking it?' with the Opus 4.6 model selected."can you give me alt text for this9:29 PM"Claude.ai chat interface greeting 'Good evening, Rich' with the Anthropic spark logo. The message composer shows a draft prompt reading '/red-pen I have a post I'm drafting. Mind checking it?' with '/red-pen' and 'a post' highlighted in blue as a skill command and file attachment. The Opus 4.6 model is selected, with an orange send button and a plus icon for attachments.

    It’s a red pen.

    It checks my drafts against the craft rules I set and shows me where I need to tighten up.

    I care about this because craft compounds. Sloppy writing erodes trust one post at a time. The red pen has made my writing better. Maybe it’ll help yours too.

    Check out my Red Pen skill →

  • Studio CLI: Local WordPress in Seconds

    The WordPress Studio team just shipped the Studio CLI as a standalone npm package.

    If you’ve used the Studio desktop app, you know the pitch: fast local WordPress development powered by WordPress Playground. Now all of that works from your terminal. No desktop app, no Docker, no Apache configs.

    Install it with npm install -g wp-studio and run studio site create to get a local WordPress site up in actual seconds.

    You, or more likely your agents, can even configure sites with custom domains, HTTPS, and specific WordPress or PHP versions:

    studio site set --domain mysite.wp.local --https --wp 6.8

    You can also authenticate with WordPress.com to create a temporary preview site and (soon) push/pull sync:

    studio auth login
    studio preview create

    The Studio app is nice. I run it every day I’m building with WordPress. But putting it in the terminal means our agents can use it too. Just tell your agent about the package, or give it my post here, and you’ll be up and running in no time.

    It’s free to install and use. Early access is live now on Mac, Windows, and Linux (a first for Studio).

    Get WordPress Studio CLI →

  • Office Hours

    I’ve been thinking about how to get more direct product feedback for WordPress. X is a fine medium, and tools like Interviews.now are cool, but I also like a good face-to-face conversation.

    Set up a 1:1 with me →

    Two slots a week, up to 30 minutes each. One early morning, one later in the afternoon, so there’s a better chance of catching folks across time zones.

    Grab one if you want to talk about where WordPress is headed, what you’re building, or how you’re using AI with WordPress. I’d also love feedback on WordPress core, WordPress.com, WooCommerce, Jetpack, or anything else we’re working on at Automattic.

    Many of the best product insights I’ve gotten came from casual conversations. Someone mentions a small thing that’s been bugging them for months and it turns out fifty other people feel the same way.

    Those moments are worth protecting time for.

  • Meet the WordPress AI Providers

    The new WP AI Client in WordPress 7.0 is provider-agnostic. This means you get to choose what AI providers you want to use, while plugins just add functionality via abilities.

  • How to Use the WordPress AI Client

    The upcoming release of WordPress 7.0 ships with the new WP AI Client. You will be able to can call any AI model (Anthropic, Google, OpenAI, others) through a single API, in PHP directly and from JavaScript using the Abilities API.

  • API is the UI

    The fastest-growing users of our products are agents. And agents don’t need interfaces.

    Agents do not need buttons, visual hierarchy, hover states, or spinners. They need APIs, structured data, and predictable endpoints (and to know about them).

    What matters underneath is the primitive: block schemas, data models, structured content. The formats they produce (markdown, HTML, JSON) are addressable, diffable, and writable by both humans and machines. Most interface chrome is just a convenience layer on top.

    You can already see this shift in code editing.

    A year ago, writing software meant living inside a code editor, manually creating and editing files. Today, tools like Codex, Claude Code, and Telex have moved much of that primary workflow into a chat interface.

    The code editor still exists, but its role has changed: you’re often reviewing, fine-tuning, and steering while the editor becomes secondary.

    The same shift is happening in website building: an agent does not need a block inserter or drag-and-drop chrome. It needs a clear schema for what a page can be and a stable way to write to it (cue the block model for WordPress).

    The visual editor becomes the place where a human reviews what the agent built and fine-tunes from there. Which means we’re now designing for two audiences.

    The primary audience is increasingly the agent: give it clean APIs, predictable structures, and fast execution paths.

    The secondary audience is the human: they need controls to edit, review, refine, and redirect, but most of all they need confidence. Did the agent do something that supports their goal? Did it meet their standards? How do we communicate what the agent did and why? How do we help humans and agents stay aligned? And when they’re not aligned, how do we make it easy to redirect?

    We’ve always treated the human interface as the product, the shape of buttons, the depth of shadows, the flow from connecting accounts to purchasing to completing the job. The API was often an afterthought for integrations or technical requirements.

    Human interfaces are not going away, but they are becoming less central. I’ve spent my career building interfaces, but now the most important work I do is what happens beneath them.

    API is the new UI.

  • How I Got Ralph to Ship Overnight

    I woke up to five pull requests this morning. Passing tests, clean commits, generated PR descriptions.

    I didn’t write a single line of code (but I did review).

    This is what product management looks like now. I describe the problem. We shape it into a PRD. Then the agent translates that into structured issues, sequences the work, and starts building.

    My job is less “writing specs” and more thinking clearly, making good calls, and steering the system while it moves.

    I’ve been building my own take on the Ralph Wiggum Loop: a system of Claude Code skills that plans, structures, and executes features mostly autonomously.

  • Giving my blog a voice

    I’ve found myself choosing audio more often, like in last week’s experiment, interviews.now. It’s nice, especially when I’m walking, driving, or just stepping away from a screen.

    I wanted to explore adding audio to my blog in a way that stays simple and doesn’t add any friction to how I publish—at all.

    So yea, you can listen to my posts, read in my voice.

  • I built an agent that interviews WordPress users

    I built an ai voice agent that interviews people about WordPress. Three minutes, their honest take, with structured insights delivered on the other side.

    The way I see it, conversations are variables—context, intent, memory, tone. Set them right and agents handle structured research while you focus on judgment calls.

    Humans are irreplaceable for empathy, judgment, shared experience. But for conversations that are structured and repeatable? Agents are in.

  • WordPress Explorations: Application Menu

    This is part of my WordPress Explorations series, where I’m exploring new, far-out ideas about WordPress.

  • WordPress Explorations: Pages & Layers

    This is part of my WordPress Explorations series where I’m exploring new, far out, ideas about WordPress.

  • WordPress Explorations

    I’ve been thinking about WordPress differently lately. Taking a step back from the accumulated complexity and simply imagining how it could exist.

    WordPress has grown, in both capability and in the many different shapes it can take. That evolution enables millions of people to publish online, but it also adds layers of complexity that have built up over time.

    So in this new series of posts, I’m exploring what else could be. What if we could rebuild this ship with the knowledge of everything we’ve learned along the way? What would we do differently today?

    I want to question every assumption. Challenge requirements carved in stone. Strip concepts down to their core and ask: what’s actually needed? Because that’s often where innovation happens—when you stop accepting constraints as given.

    None of these ideas are proposals.

    This is exploration for exploration’s sake. Some might work, most won’t. That’s the point.

  • WordPress Almost Didn’t Happen

    What if Matt had joined Google instead of starting WordPress?

    The internet might have felt a little less like ours.

    In his recent post, Matt mentioned “How the internet might have turned out differently if I had taken that job, as my mom wanted me to (because they offered free food).”

    Funny line. But also wild to think about. It’s incredible how much of the web traces back to one person deciding to build something open.

    I think about that sometimes. The tiny choices that ripple out for decades. Who’s choosing open now? And what will that mean twenty years from here?