In this episode, Bob Dunn discusses utilizing 4.4 million words from Open Channels FM’s podcasts and blog posts. He highlights tools like Jetpack AI Search and Site Chat, enhancing users’ access to valuable insights and discussions.

tl;dr: 15 years stuck in the same wp-admin, why don’t you try in playground the new wp-admin experience? WordPress has spent the last fifteen years becoming capable of doing almost everything, yet somehow we have continued interacting with wp-admin in fundamentally the same way: click somewhere, load another screen, go back, open another tab because you do not want to lose the previous one, and after a while end up with ten different WordPress tabs scattered across your browser. I find it quite funny that we all accepted this as completely normal. Today WordPress is used to run stores, publications, membership sites, communities, LMS platforms, agencies and entire businesses. We have plugins that are effectively full applications, incredibly complex editing experiences, analytics, forms, CRM systems, media tools, commerce, automation and thousands of other things living inside the same installation. Yet the interface connecting all of them still assumes that, most of the time, you want to look at one thing at once. And when you don’t, the browser has to solve the problem for us. Browser tabs have essentially become the window manager of WordPress. That is one of the ideas that eventually led us to OpenStation. Why don’t we have windows? It sounds ridiculously obvious when you phrase it like that, but that is exactly why I find the question interesting. On a normal computer I can have my editor open next to a browser, keep a terminal in the background, drag files around, minimize something I want to return to later, or simply arrange my workspace around whatever I am doing at that moment. Nobody thinks about this as a feature anymore because it is just how computers work. Then we open WordPress and suddenly that whole model disappears. If I am editing a post and need something from the Media Library, I navigate away or open another tab. If I am checking an order while editing a product, another tab. If I want to compare two posts, another tab. If I am configuring something and need to check how another part of the site is set up, another tab. There is nothing technically wrong with that, of course, and it has worked for years, but after building and using OpenStation every day I started noticing how much context we constantly throw away simply because wp-admin was designed around pages rather than workspaces. That distinction matters much more today than it probably did fifteen years ago. WordPress quietly became something much bigger I keep describing WordPress as the operating system of the web, and obviously I do not mean that literally. What I mean is that WordPress has gradually accumulated many of the characteristics you would expect from a platform where applications live. Plugins install capabilities into it. Users have identities and permissions. Applications share data. We have APIs, scheduled processes, notifications, media, editors, databases and an enormous ecosystem of software that knows how to work with the same underlying environment. The strange part is that the interface never fully made the same transition. We kept adding more applications to WordPress, but we continued presenting them largely as destinations in a menu. OpenStation started from a very simple thought: what happens if, instead of redesigning every individual wp-admin page again, we change the environment in which those pages live? That immediately opens a much larger set of possibilities. A post editor does not need to replace your media library on screen. A WooCommerce order does not need to replace the product you were editing. A plugin screen does not necessarily need to occupy the entire browser just because you clicked its menu item. They can simply be windows. You can move them, resize them, minimize them, keep several of them open, organise them across different desktops and return to exactly what you were doing without recreating the context again. The funny thing is that none of this feels particularly futuristic. Quite the opposite. We have been using computers this way for decades. We just somehow never brought that interaction model into wp-admin. The interesting part is not actually the windows The windows are what people notice first because they are visual, but I think the more important idea is what happens once WordPress stops assuming that navigation must destroy context. Suddenly the admin becomes a workspace. You can have the Media Library next to the editor instead of travelling between them. You can keep an order visible while checking something else. You can open notes or widgets without abandoning your current task. Applications can coexist on the same desktop and eventually interact with each other in ways that become much harder when everything is isolated in separate browser tabs. This is also where things like drag and drop become much more interesting. If two applications are part of the same environment, moving an image, a product, a post or another WordPress entity between them can become an actual interaction instead of a sequence of copy, navigate, search, paste and navigate back. And once you start thinking about WordPress this way, a lot of things that initially looked like unrelated OpenStation features start making sense together: windows, the dock, multiple desktops, widgets, the command palette and applications are all different pieces of the same idea. The goal is not to decorate wp-admin until it looks like a desktop operating system. The goal is to make working in WordPress feel less like navigating a website and more like working inside an environment. We don’t need to replace wp-admin to do this This is probably the part I like the most about the approach. WordPress already has an enormous ecosystem and rebuilding everything would be both unrealistic and, in my opinion, the wrong problem to solve. There are thousands of admin interfaces that already work, plugins developers have spent years building, and workflows users already understand. OpenStation can sit on top of that rather than asking the ecosystem to start again. The existing WordPress admin can continue being WordPress. Existing plugins can continue exposing their interfaces. What changes is how those interfaces are presented and how you move between them. In some ways, I think that is much more interesting than simply designing another admin UI. We are not trying to decide what every WordPress application should look like. We are trying to give those applications a better place to live. And once you have that place, building actual OpenStation-native applications becomes possible as well. We have already been experimenting with things like a photo editor, project management tools and forms, but what excites me is not any individual application. It is the idea that WordPress can host an entire collection of tools that feel like they belong to the same workspace instead of a collection of isolated screens connected by a sidebar. So why did it take fifteen years? Probably because there was never a single moment where the old model stopped working. WordPress evolved gradually. A new menu here, another plugin there, a more sophisticated editor, WooCommerce, custom post types, page builders, analytics, SEO tools and so on. Each addition fitted reasonably well into what already existed, so there was never an obvious reason to stop and question the basic interaction model. But those small changes accumulated. The WordPress of today asks considerably more from wp-admin than the WordPress of fifteen years ago did, and I think that eventually creates an opportunity to revisit assumptions that once seemed completely reasonable. The assumption we are questioning with OpenStation is a very simple one: Why should opening something in WordPress mean leaving everything else behind? After spending months working this way, I now notice it every time I go back to the traditional flow. I open something, realise I need another part of WordPress, create another browser tab and immediately think: why am I doing this outside WordPress when WordPress itself could manage the workspace? That is probably the best way I can explain what we are building. WordPress has had applications for a very long time. Perhaps what it has been missing all these years is somewhere for those applications to actually live together. By the way, don’t forget you can always try OpenStation without even installing it in your site, using WordPress playgrounds

The Open Source Champions initiative invites individuals and brands to support the network through a unique advocacy opportunity, offering exposure, promotional features, and participation in special episodes.

Howdy, Before anything else: if you maintain WordPress sites, go update them. WordPress 7.1.2 shipped on September 22 to patch a single critical vulnerability in page template resolution, one that lets an unauthenticated attacker load a chosen PHP file from outside your active theme’s directories. Now let’s move on to better things. Anne McCarthy is auctioning off her framed WordPress release albums, the ones given to release squad members. All the proceeds go to Stimpunks, a nonprofit started by Ryan Boren, who joined the project in 2003 and wrote the plugin system that nearly every site runs on. She calls the albums “a form of a gold medal to me,” and she built the auction site herself in a week. The starting bid is $500. We also learned this fortnight that the next default theme will be called Ipsum, which means 16 years of naming themes after the calendar is over. Admittedly, I’ll miss the old Twenty* names a little. But it’s time for something new for a new era. Two more quick things: WordPress has taken its turn leading the Open Website Alliance, alongside Drupal, Joomla!, and TYPO3, with Mary Hubbard holding the rotating presidency for the WordPress Foundation. And starting with 7.2 in December, release parties move from in-person events to livestreamed webinars, so the whole squad can actually be there. Enjoy your weekend! Your friendly neighborhood dev advocate, Justin Tadlock Table of Contents Developing Gutenberg and WordPressPlugins, Themes, and Tools for #nocode site builders and ownersTheme Development for Full Site Editing and BlocksBuilding Blocks and Tools for the Block editorAI in WordPress Developing Gutenberg and WordPress Two security releases in six days. WordPress 7.1.2 is the urgent one, and it’s security-only: an unauthenticated attacker can, under the right conditions, make page template resolution include a readable local PHP file from outside the active theme directories. John Blackbourn led the release, Robert Ressl disclosed it, and the fix was backported to every eligible branch going back to 4.7. Five days earlier, WordPress 7.1.1 arrived as the regular maintenance release with 11 security fixes, 17 bug fixes on Core, and 19 for the Block Editor. Aaron Jorbin led it, and Anthropic is credited twice in the security list. Aki Hamano announced what’s new in Gutenberg 24.0. The big feature: post title changes now show up in revisions with a proper diff, so you can stop guessing when a rename happened. The Gallery block gains a Grid variation with column count and “crop images to fit” configurable per breakpoint, and Site Title picks up fit-text, scaling to the width available instead of a fixed point size. And nearly 100 icons were redrawn on a stroke-based grid. Stalled out somewhere between “clone the repo” and “why won’t this build”? Contributor Toolkit 1.2 from JuanMa Garrido now covers Gutenberg as well as Core, and it runs a stock WordPress in Playground with your checkout mounted as the plugin, already activated. No local server, no Docker. The road to 7.2 Anne McCarthy published the roadmap to 7.2, and it looks to be a security-heavy cycle by WordPress standards. Sudo mode gates sensitive admin actions behind re-authentication, a new Secrets API gives credentials “a first-class way to store credentials safely,” and Application Passwords get hardened. Notes should gain a suggestion mode and emoji reactions. Designers get form element customization in Global Styles and custom block states. The final release lands in early December. Real-time collaboration came out of WordPress 7.0, and Chris Zarate has now explained why in a post on moving to a server-aware approach for collaboration, written with Alec Geatches, Dennis Snell, ingeniumed, and Paul Kevan. The old design had browsers hold the post in a CRDT document and sync peer-to-peer, which broke three ways: the server couldn’t tell who made which edit, opening the door to content laundering; REST API and WP-CLI updates couldn’t participate, so saves became all-or-nothing overwrites; and a dropped connection could take your work with it. Three candidate sync engines are on the table, with a gutenberg-sync-engines repo to test against. If you build editorial tooling, have an opinion about this now. The next default theme has a name, and for the first time in well over a decade, it isn’t a year. Henrique Iamarino introduced Ipsum, built with Carolina Nymark, Maggie Cabrera, and Juanfra Aldasoro. The reasoning behind the naming change: “default themes will have their own names and change when the design calls for it, not when the calendar does.” The theme is intentionally spare. It’s blog-first, has minimal typesets, and structural elements that stay invisible until you need them. The request is simple: “try it and tell us what breaks and what’s missing.” Nik Tsekouras opened a call for testing the DataForm editor inspector, which rebuilds the Post and Page tab of the Settings sidebar so it stops drifting from Quick Edit in the Site Editor. Install Gutenberg 24.0 or later and enable Editor Inspector: Use DataForm under Settings → Gutenberg. Test it as an editor, author, and contributor, not just as an admin. Behind the release A minor release can touch more than twenty branches, and much of that work was done by hand. Lance Willett opened a public repo of Core release tools, which includes tagging, release docs, SVN merge verification, and contributor lists. Huzaifa Al Mesbah counted 84 people who tested WordPress 7.1 across 337 Trac tickets. Fifty were first-timers, which is 60% of everyone who showed up. The most important line: “you don’t need to be a developer.” 7.2 testing is open now. Plugins, Themes, and Tools for #nocode site builders and owners WooCommerce 11.2 lands the week of October 6, so read Shani Banerjee’s pre-release notes before it arrives rather than after. Order withdrawal emails become configurable, the CSV importer can match products by Global Unique ID when neither ID nor SKU is available, and checkout fields gain date support with min/max validation. Two of the seventeen developer advisories will bite if you ignore them: date filters in wc_get_orders() and wc_get_products() now read a bare date as a day in your store’s timezone rather than UTC, and the Cart and Checkout order summary becomes a fixed 360px column with the two-column breakpoint moving from 700px to 920px. Two dot releases arrived in between, both flagged as security updates. WooCommerce 11.1.2 fixes the infinite recursion that was breaking product variation galleries, and 11.1.1 hardened API permissions and session handling. The latest WordPress.com changelog moves the AI website builder from picking a theme to generating one: on Premium and Business plans, it “now generates a fully custom theme built around your goals and brand.” A new Annotate feature lets you queue several targeted edits and send them at once. GatherPress started on a fourteen-hour drive to WordCamp US in 2018, when two Montclair meetup organizers came up with a name and then didn’t write any code for nine months. Rae Morey tells the story of how it grew into WordPress’ Meetup.com replacement, through July of this year, when Automattic’s Karen Arnold confirmed WordPress is going ahead with it. The gatherpress.org domain is transferring to the Foundation, and the plugin has been testable at events.wordpress.org since August 28. No launch date yet, and co-maintainer Mervin Hernandez Sitnikovski would rather you help than wait. Theme Development for Full Site Editing and Blocks WooCommerce has a new block theme. Brian Coords announced that Purple is back and ready for beta testing. The project was paused during a strategy update last year, and it’s Woo’s first official block theme. Ten color palettes, ten font pairings, custom styles for both WooCommerce and core blocks, and templates covering everything from Shop to Checkout to My Account. The inserter category is being renamed from “WooCommerce” to “Shop.” If you’re wondering where Storefront’s featured extensions went, block editing absorbed most of them. Peter Schimke also notes that Purple is now the default for new WordPress.com Commerce stores. Mark your calendar for Wednesday, September 30 at 10 a.m. PDT / 1 p.m. EDT / 7 p.m. CEST: Woo is hosting a live session on building with WooCommerce block themes. Mike McAlister of Ollie joins Woo engineers Karol Manijak and Lucio Giannotta. There’s a Q&A at the end and a recording afterward, but questions only work if you show up. “We need more workflow in Core,” said K. Adam White, principal engineer at Human Made, talking with Nathan Wrigley on WP Tavern about migrating to blocks with artisanal care and enterprise efficiency. At the center of it is Human Made’s open-source Rehydrator, which uses pattern HTML as a template and injects migrated content into it, so structure and styling survive a move off something like Sitecore. He describes building SQLite databases from client exports just to find the edge cases. He’s candid about the gaps, too: granular permissions, editorial approval workflows, and internationalization. “Keeping up with Gutenberg – Index 2026” A chronological list of the WordPress Make Blog posts from various teams involved in Gutenberg development: Design, Theme Review Team, Core Editor, Core JS, Core CSS, Test, and Meta team from Jan. 2024 on. Updated by yours truly.  The previous years are also available: 2020 | 2021 | 2022 | 2023 | 2024 | 2025 Building Blocks and Tools for the Block editor Your Query Loop returns nothing, and the heading and pagination you wrapped around it render anyway. Ryan Welcher spent a live stream adding a “hide if empty” control to Advanced Query Loop, his free plugin that extends the core Query Loop with taxonomy relationships, meta queries, and relative date filters. Gutenberg’s JavaScript tests have moved off Jest. Marco Ciampini explains that unit and integration tests now use Vitest, driven by ESM: as more dependencies shipped ECMAScript modules, the CommonJS-based Jest setup needed more and more compatibility glue. The part that affects you: @wordpress/scripts 36.0.0 makes Vitest the default for test-unit-js, with @wordpress/eslint-plugin 27.0.0 following. Not ready to migrate? Switch to wp-scripts test-unit-jest and install the Jest dependencies yourself. AI in WordPress Your agent builds you a landing page, and then what? It sits in a chat log, or a folder, or a local dev server nobody else can reach. That’s the gap Spacefast is built for, and Automattic soft-launched it this week: Matt Mullenweg announced it on X. The pitch is the last mile for agent output: publish from a conversation with Claude or ChatGPT, from npx spacefast publish, or from a GitHub push, and get a permanent URL with immutable versions, one-click rollback, and access controls. It hosts full-stack projects, not just static files. The WordPress hook is a Spacefast plugin with two modes. Static mode hooks into Simply Static, exports your site, and publishes the snapshot. Headless mode treats WordPress as the content source for a repository project, triggering a production rebuild when you publish or update public content. MCP turns up everywhere WordPress Trac now speaks MCP. Lance Willett announced a Trac MCP server that’s “public and free to use: no account or API key needed.” Ask what’s left on a ticket and which pull requests are still open, or what someone committed in January 2005—yes, it goes back that far. It covers every WordPress.org Trac, from Core and Meta to bbPress and GlotPress. James LePage wrote the first version, with props to Jon Surrell, David Newman, and Konstantin Obenland. Jamie Marsland makes the case for why WebMCP is going to be big for WordPress and, more usefully, shows you how to try it this afternoon: open the ChatGPT desktop app in Work mode, load WordPress Playground in its built-in browser, and ask it to build you a homepage. His framing is the clearest I’ve read. WebMCP gives an assistant “an instruction manual with working buttons” instead of making it squint at screenshots. For the enterprise view of the same shift, Shane Schick compares WebMCP and traditional MCP and lands on a line I’d pull out of the whole piece: “MCP is not going away, and WebMCP shouldn’t be seen as a rival protocol.” His table sets them side by side on deployment, access scope, scalability, and auditability. That auditability row is the one that matters if you answer to a compliance team. Schick also introduces Parse.ly MCP, which connects Parse.ly data to whichever assistant your team already uses. You authorize once with your existing login, and the assistant sees exactly the sites your account already sees. “Analysis that used to take a request and a day now takes a conversation.” One more, for the security-conscious: WPShout walks through connecting Cursor to WordPress with MCP using ThemeIsle’s Easy MCP AI plugin. Every tool call still passes a WordPress capability check, with a 60-requests-per-minute default. Their advice is the part to take seriously: “read-only first, watch the audit log for a week, then grant write scopes deliberately.” Putting agents to work Anthropic open-sourced its commerce agents on September 2, and WooCommerce has already adapted them. Shani Banerjee walks through running the Claude Commerce Agent on WooCommerce, which spins up a demo store with eight products and nine orders in about fifteen minutes. The neat piece is a bridge plugin: the assistant’s cart lives under a Store API token your browser session can’t see, so at checkout the plugin re-adds each item to your real cart with normal stock checks. Merchant-side changes stage behind an approval gate, and “ask it to approve itself and it declines.” There’s a second kind of visitor to design for now. Carlo Daniele argues for building WordPress for AI agents instead of just human visitors, and the distinction he draws is the useful one: “Crawlers primarily retrieve or index information. Agents can go a step further and take action on a user’s behalf.” That turns architecture questions into permission questions: who is asking, on whose behalf, what can they change, which actions need approval. The Abilities API and MCP Adapter are where WordPress answers them. A week later, Daniele turned to operations. What happens when AI agents become your new website operators? works through a five-stage autonomy ladder and argues most teams should sit partway up it for a while. I feel like he’s right about that. As he puts it: “An agent that makes a bad production change creates another.” Learning and practice Want a structured introduction rather than a pile of blog posts? Destiny Kanno announced that the AI-Powered WordPress course is now live on Learn WordPress: four modules, 23 lessons, roughly nine hours. The first three are for anyone who publishes; the fourth introduces the developer APIs and assumes no prior PHP experience. The AI team’s contributor summary for September 16 is a good snapshot of what’s actually moving. neillmcshea reports work on markdown feeds for the AI plugin, so AI clients can request a markdown version of a post. PHP AI Client 1.5.0 is close. There are still open gaps in web search support. For example, message parts can’t represent source annotations, and citation URLs are hard to retrieve. Finally, a piece for the conversations you have with clients rather than with a terminal. Will Davis writes about how WordPress agencies use AI, and what clients should ask about it, arguing that the honest uses are the boring ones—code generation, QA, content migration, documentation—while architecture and governance stay human. His five questions for clients would work just as well on a sales call, starting with “What does a person review before it reaches me?” As he puts it, AI “genuinely reduces repetitive work, but it doesn’t replace judgment.” Need a plugin .zip from Gutenberg’s master branch?Gutenberg Times provides daily build for testing and review. Now also available via WordPress Playground. There is no need for a test site locally or on a server. Have you been using it? Email me with your experience. Questions? Suggestions? Ideas? Don’t hesitate to send them via email or send me a message on WordPress Slack or Twitter @bph. For questions to be answered on the Gutenberg Changelog, send them to changelog@gutenbergtimes.com

Tonight I started working on some Shortcode processing in WordPress. This is an historically nasty problem because the Shortcode syntax and parsing is wildly dynamic. Shortcode syntax is only technically recognized for shortcodes registered at the time of parsing. This means that there is not a general Shortcode grammar. Whether a shortcode has “content,” meaning whether it expects a closing tag, depends on whether the closing tag exists in the post. This is a problem that has plagued me for years and I have generally just ignored. There’s an open Core issue in Trac for changing some shortcode parsing (#50683), and I have thought a lot about it. But I think there is more to explore, and more to gain. Maybe this goes nowhere, but keep your eyes open for it.