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

---

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.

A website changelog helps creators document progress, celebrate small wins, showcase evolution, fuel creativity, and build audience trust. It can include updates, humor, and various formats, making it accessible for all.

A reflection on recognizing the right time to move on from creative projects and handling self-doubt.

OPENSTATION · COMMUNITY VOICES

Formerly Desktop Mode, now a new way to feel at home in wp-admin.

A plugin can accumulate installs. It is rarer for people to describe it as a new way of thinking. As of September 25, 2026, OpenStation, known in its earliest releases as Desktop Mode, has inspired 23 public WordPress.org reviews: 22 five-star and one four-star.

OpenStation turns the WordPress admin into a spatial workspace: movable windows, a dock, a taskbar, widgets and virtual desktops. That is the feature list. The feeling is better told by the people who use it.

---

The words that stopped us in our tracks

1. When a plugin becomes the default

“I can’t imagine using WordPress any other way. I love this plugin so much.”

— Nick Hamze, “Favorite plugin ever”

That may be the highest compliment a tool can earn: not merely useful, but difficult to imagine living without. Nick’s review reads less like a rating and more like an invitation to join a movement.

“This is a game-changer. Can never go back!”

— ainom, “Absolute pure awesomeness”

OpenStation begins as a striking visual idea, then quietly rewires expectations. Once several admin screens can live together, the old one-page-at-a-time flow feels surprisingly distant.

---

2. When the metaphor improves the work

“It genuinely feels like using a lightweight operating system inside WordPress.”

— spackenjaeger, “A revolutionary new WordPress admin experience”

The operating-system metaphor is not decoration. Windows hold context. The dock makes tools reachable. Virtual desktops separate kinds of work. The familiar desktop grammar turns multitasking into something visible and natural.

“Having several admin screens open at once changed how I work more than I expected.”

— Juan Lentino, production user and plugin integrator

Juan’s review is especially telling: he has run OpenStation in production since the Desktop Mode days and builds integrations against it. The novelty faded; the workflow remained.

---

3. When delight becomes productive

“The desktop-style layout, draggable windows, dock, and taskbar make the admin area feel completely different in the best way.”

— Marco Moreira, “A refreshing new way to use WordPress admin”

Productivity software does not have to be joyless. The best interfaces reduce friction and add a little momentum, the feeling that the workspace is helping rather than merely waiting.

“This plugin blowed my mind. It turns your wordpress admin in such a beautiful dashboard. What an experience.”

— MauroS, “One word… Wow!”

The wording is wonderfully unfiltered. Beauty, surprise and experience are not side effects here; they are part of the product.

---

4. When people see the road ahead

“This is definitely something I would use on a daily basis. Well done!”

— vepth, “I’m blown away”

“Desktop Mode definitely stands out with its own approach.”

— Rami Obeidat, “Modern and creative admin experience”

Both reviews point to the same achievement: OpenStation is not chasing a generic “modern admin” look. It has a point of view—spatial, extensible and unmistakably its own.

---

From Desktop Mode to OpenStation

The project’s name changed because its ambition outgrew a mode. “Desktop Mode” described the first transformation. OpenStation describes the platform emerging around it: a place where WordPress apps, windows, widgets and workflows can meet.

“The integration surface is unusually well behaved for a plugin this ambitious.”

— Juan Lentino, WordPress.org reviewer and integrator

That sentence matters as much as the praise for the interface. The magic users see is supported by a public API that plugin authors can build on, frequent releases and an opt-in design that keeps classic WordPress one click away.

The best roadmap is a chorus

Names change. Interfaces evolve. Code ships, breaks, improves and ships again. What stays constant in these reviews is the feeling that WordPress can be more personal, more spatial and more alive.

OpenStation is still moving fast. But if the people already living in it are any guide, the destination is worth watching, and the journey is already changing how they work.

Explore OpenStation on GitHub →
Read all WordPress.org reviews →

Quotes are excerpted from public WordPress.org reviews. Spelling is preserved; excerpts are linked to their original sources.

Bruce is one of my favorite writers. He packs profoundness. Also honored that he’s an advisor at Automattic, truly one of my idols. His blogs and books rocked my world when I was young.

Cami and Bob talk about adapting to tech changes growing older in the web industry and keeping routines that work.

Examining support systems behind open source, the open web, and everyday life, along with why sustaining these efforts is necessary.

The podcast network has reduced its active lineup to four shows, leading to no new episodes for Open Makers. However, past content remains accessible, with a shift towards deeper discussions on open source and web trends.

Transcript

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, migrating to blocks at an enterprise level and what’s involved in moving from a different CMS into WordPress.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox and use the form there.

So on the podcast today, we have K. Adam White, or K. Adam for short.  K. Adam is the principal engineer at Human Made, an enterprise WordPress consultancy. He’s been involved with WordPress for almost 20 years, attending his first WordCamp in Boston back in 2011, and has contributed to WordPress Core and the broader open source ecosystem. Human Made is known for delivering complex projects, think high stakes, no room for mistakes? From global brands moving to WordPress.

This time around,  K. Adam delivered a presentation at WordCamp US focused on a crucial topic for anyone modernising their site, migrating to blocks. Human Made has been all in on the block editor since the Gutenberg plugin days, and the team now specialises in large scale migrations from other content management systems like Sitecore, as well as from other WordPress page builders.

Our conversation focused on the technical and editorial challenges of moving tens, or hundreds, of thousands of posts into the world of blocks and patterns. We talked about the need to combine artisanal care, attention to detail in design, layout, and brand, with industrial scale. The ability to automate, audit and validate mass migrations without losing visual fidelity.

We also discussed the use of patterns as a foundation for development, integrating custom and Core blocks, and leveraging new tools, including AI powered agents and open source plugins like Human Made’s, own rehydrator, to streamline migration workflows.

We also touched upon how clients are onboarded. The process of auditing legacy content. Strategies for training editorial teams on the block editor. And there’s a frank reflection on gaps in WordPress, like granular content permissions.

If you are contemplating a move to the block editor, wrestling with a massive content migration, or curious about what happens when enterprise complexity meets the flexibility of WordPress, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you  K. Adam White.

I am joined on the podcast by K. Adam White. Hello, K. Adam.

[00:03:41] K. Adam White: Hello. It’s good to be here.

[00:03:42] Nathan Wrigley: Yeah. Thank you for joining us. You have an interesting name. Just go on, I know it’s totally off piste, but tell us about your name.

[00:03:49] K. Adam White: Sure. It’s a first initial K, and the middle name Adam that got conjoined in college and I quite like it. So I think in a sphere, and a particular niche in WordPress with so many Adams of so many different colours, then K. Adam is a little bit more me.

[00:04:04] Nathan Wrigley: Yeah, nice. So we’re in the corridor, so forgive any noise that you hear on this podcast episode. We can’t avoid it. We’re in the corridor at  WordCamp US, and you have done, some presentation work this time around. Do you want to just tell us, I mean I presume it’s happened because we’re at the very closing stages of the conference. How did it go?

[00:04:21] K. Adam White: It went, as far as I can tell, quite well. My session was early yesterday, right after the morning keynotes in that early slot where everyone’s coffee has kicked in, and the fatigue of the conference hasn’t quite set in yet.

So I had a great audience and the talk I thing went quite well. I’ve had a number of different conversations off the back of it on various different topics that I covered. So the breadth of those discussions has been really exciting for me.

[00:04:44] Nathan Wrigley: So that is going to be the meat and the bones of what we’re going to talk about today. But first, if you don’t mind, let’s talk a little bit about you and what you do and where you work, just so that we can paint your credentials if you like.

So tell us about your job, how long you’ve been in the WordPress space? Who do you work for? Et cetera.

[00:04:59] K. Adam White: Yeah. My job is principal engineer at Human Made. We’re a WordPress enterprise consultancy, and I have been there nine years. I’ve been in the WordPress community quite a lot longer than that. My first WordCamp was WordCamp Boston 2011, which is a mind boggling 15 years ago now. And before that, I had been using WordPress personally since 2007. So we’re coming up on 20 years of involvement, at least as a user. And then, became a contributor in the early 2010s around 2013, I think my first commit landed.

[00:05:25] Nathan Wrigley: Yeah, nice and Human Made, if you haven’t heard, we’ll put the links into the show notes, anything that K. Adam mentions today, we will put us a link on the WP Tavern podcast episode website, so you can click through to it. But go and check out Human Made, definitely one of the big hitters. I think it’s fair to say in the WordPress space.

[00:05:40] K. Adam White: It’s very kind of you to say so.

[00:05:42] Nathan Wrigley: You did your presentation and it was entitled, Migrating to Blocks. I’m going to intuit from that, that Human Made is all in on the block editor. You’re not using some sort of other proprietary platform. Would that be the case?

[00:05:55] K. Adam White: That would be the case. We were very early adopters of Gutenberg back in its plugin days. We were doing work before it was merged for building out some early block sites, testing out what we could do. Learning how to build and change our theme development processes to move in a more block oriented direction, and then follow that directly into the Full Site Editor world.

And it’s been a great ride. We do work with other page builders and other blocks, platforms and frameworks. We do tend to, as a company, work on projects that have some sort of particular technical complexity that made someone come to us rather than a different agency.

That does mean that we are broadly specialised in WordPress as a platform, including many of those page builders. We’ve worked with Elementor, we’ve worked with Divi, Beaver Builder, but we as a company will always advocate for the block editor and the site editor. And we have our own processes oriented more and more towards delivery with that framework in mind.

I think that the thing that is bringing some of the companies that we help to migrate to WordPress into this ecosystem is the flexibility and the quality of the editorial experience. And personally, my opinion is that Gutenberg does that leaps and bounds better than any of our other page builders that don’t have that native integration into the platform.

[00:07:09] Nathan Wrigley: So if a client comes to you and they are agnostic as to what you are going to build with, your default posture would be we are going to use the block editor.

[00:07:16] K. Adam White: Absolutely default.

[00:07:17] Nathan Wrigley: Okay. And do you have to do any level of persuasion anymore? I’m guessing if we were to rewind the clock, let’s go to 2017, soon after Gutenberg started to become more widely available. I imagine there was quite a bit of explaining to do. Do you still have to do any of that? Or is it a case now that the enterprise people understand what’s going on, and there’s less of a back and forth about whether they should use blocks and patterns and whatever else?

[00:07:41] K. Adam White: If we are building from scratch, we haven’t found there is any reluctance. Particularly if people are coming from a different content management system, particularly a different enterprise content management system. The editor is so compelling, that there’s never any objection to using it. They might ask, should we use this or some other thing I’ve heard of? And we can say, the block editor is built in. We feel that it’s the most robust and future proof platform that you can choose. So we would recommend going that route rather than adding in another plugin, however good they are.

But we do still, nonetheless, have some projects where they are already on a page builder, and they might have invested a lot of training. We might have an entire business school worth of people that are very comfortable with whatever their existing system is, whether that’s Beaver Builder or something else, et cetera, Elementor.

And I think that it’s very important for us to remember what our remit is when we come into a project. That, doesn’t always involve helping them change everything to match what we see as the future. I think that’s a responsibility of the client to understand where they are in conjunction with where the WordPress roadmap is, and make their own decisions about what tools are right for them.

So, for existing projects, we’ll work with what’s right for the clients editorial team, but if we have to make a recommendation, it will always be the block editor.

[00:08:56] Nathan Wrigley: Okay. Yeah, good to know. At place in the market where you are, I’m presuming there’s very little room for error. When you build something, it’s got to work out of the box, on day one. You’ve presumably got stakeholders who’ve got editorial teams, and they’re fairly, we’re, dealing with large corporations that can’t afford for there to be mistakes.

So that kind of leads us to the nature of your presentation, which was called, and again, links will be in the show notes on wptavern.com. Migrating to Blocks with Artisanal Care and Industrial Scale. And I’m actually just going to read the first paragraph because it summarises what we’re going to talk about perfectly. It’s fairly long, but I’ll go through it all.

Whether we’re modernising an old personal blog or migrating hundreds of thousands of existing posts from another CMS. Using WordPress in 2026 means converting our contents to blocks. The convert to blocks button in the editor works well enough for one post. But if we have dozens or hundreds, what can we do to make the process less manual and more powerful? How can we integrate a site’s content directly into full block patterns without losing the columns and structure it had before? And then it goes on to mention, a particular build, I presume, where you were leaving one CMS coming into WordPress.

Just lay out some of the fun, interesting problems that you have to overcome when you’re moving from an entirely different CMS into WordPress, because I guess it’s more complicated than, “Look, there’s a bunch of paragraphs and images. Let’s just drag those over and hope for the best.” Tell us what the problem before you is.

[00:10:22] K. Adam White: That’s a great question. It’s actually remarkable how close you can get to satisfaction with just moving paragraphs and images over and hoping for the best. But there is a big gap in terms of visual fidelity.

The editor in a theme that we’ve built for a client will be configured with patterns and templates and all of the block variations that they need to be able to very quickly sketch out a page. If they are starting from scratch, a client with a fully site editing enabled theme can drop a hero pattern on the page, set in the media they need. Change any font sizes within the pallet of what’s available with their brand guidelines encoded in the theme.json. It’s very easy for them to build out and write content fresh.

But if you have, again, hundreds of thousands of posts, even if you’ve built all those patterns, the heading and paragraph and image only approach doesn’t cut it, because then there would be a tremendously backbreaking amount of work, adding group blocks, adding background colours, et cetera.

That’s usually data that is available in one form or the other in the current system. If we’re migrating without a design change, we will have, whether it’s the layout database in Sitecore or a metadata in a different WordPress block editor that we’re migrating from. Or whatever the equivalent is in our source. We want to preserve the layout of the page and the styling elements. So making sure that headings get the right text treatment, that anything that’s italicised comes over. All of the nuances there, particularly around background colours, images, et cetera. That’s the piece that we’ve been over the past year, looking at how we can improve our process when we’re building a new site, but bringing content over from an old.

Within that context, my talk covered two broad areas. The specific tail end of the talk was about how we can actually use the theme patterns that already exist in the theme directory, and use those to inject particular pieces of source data. So if you have a pattern for a hero element, and you know from your source data what the image URL is supposed to be, what the title is supposed to be. We can use the HTML directly from the pattern file, and do lightweight search replaces within that using either direct PHP string replacements or a tool that we’ve written, that I shared a link to called rehydrator, which is a very early stage experiment, that we’ve got out on GitHub.

And we can use that to put the content into the structure that it’s going to need to have for it to be fully, visually correct. So rather than just reducing and throwing away anything that isn’t a heading or a paragraph, we’re taking the framework from the theme pattern that’s been built. And then we’re writing a migrator that takes data and puts it into that HTML structure, and saves that into the post content. So that when an editor opens up a page, it loads correctly in the editor without block validation errors and it looks right on the front end.

[00:13:15] Nathan Wrigley: Okay. There’s a lot of depth in that, isn’t there? We’ll come back to that in a moment.

I’m curious about process of how you, persuade clients that you are going to be able to carry this work out successfully. So how does that actually work? You obviously look at their existing content, you have a discussion about what the new design is going to look like, and then do you build out some kind of templates or patterns or what have you, so that you can then pull in a proportion of the content, maybe, I don’t know, 10 or a hundred or 5,000 or whatever it may be, pieces of content. Check that that’s all right. Show it to the client. How does that workflow go to build up their confidence that what you are going to do when you finally click the button is actually going to succeed?

[00:13:50] K. Adam White: The way that we’ve been approaching that, I think particularly, over the past six months, I should caveat first that this process has changed so much. Because the tools we have available with AI agents have been evolving in leaps and bounds alongside this particular migration process, which started in January.

So in this case, we started out by building patterns that we could put content for one test post, from the existing site manually. Bringing the contents over, copying and pasting headings, et cetera. And using that to create the patterns that we could show to the client to say, does this look correct? Does this structure mirror what you’re expecting? Is this what you expect an author to have available within the post editor?

And then you know, which pieces belong in the template, which pieces are managed at the site editor level? We’ve done a lot of that ahead of starting the actual migration.

Now that the migration is in progress, any subsequent pieces we’re developing in tandem, we’re saying, okay, we have a press release. That press release, we have audited the incoming data, and we have determined that there are four different layouts for press releases. And this one is used the most and it has these elements. This one is used less, but it has images, et cetera.

And we can build the template for that post type, and at the same time write the migrator for identifying the content nodes, and the source data and bringing that information over into the new patterns.

So we have the patterns that we can show, okay, if you’re building something from scratch, this is what that looks like in the editor. But then at the same time, we can run the migrator over, in most cases, all of the relevant type of data and say, and here is a list of pages to validate.

So what we’ve been doing is bringing that to our stakeholder, and allowing them to do spot checks, so that they can look through and validate that there are all of the required elements on the test pages. Things like, “oh, alright, we don’t have a mapper yet for video embeds. So videos are missing,” and that’s usually going to be an all or nothing thing. We’ve found very few cases where we end up with one or two errors on a specific post basis that aren’t related to support for a complete type of output pattern.

[00:15:55] Nathan Wrigley: Is there a sort of fault tolerance there? So obviously in the case of this particular migration, tens of thousands of posts, I guess there’s never going to be a moment where you can be a hundred percent confident apart from reading the 10,000 posts that you’ve done everything correctly. Is there a, we’ll do 10 to begin with, then we’ll go up to a hundred, then we’ll go up to a thousand.

What, is the sort of tolerance that you present to the client? I’m just imagining that just lurking in post 9,999 is just some weird thing that was allowable in the CMS but never got used before or since, and that piece of content got missed. I don’t know what’s allowable in that scenario. So is there any level of tolerance for fault?

[00:16:32] K. Adam White: The major advance that we’ve made with migrations as a broad structure this year is a much better understanding of those edge cases. And the way that we’ve done that is by leveraging Claude and various other tools to do cross site audits to make sure that we have a full picture of the source data.

So we are able to feed in whatever export files we get from our source site. In this case we’re working from Sitecore, which is an enterprise CMS, which has two database structure. There’s actually a database with a content tree, and then another database that contains layout information. And a page is rendered by switching back and forth between those and assembling the final output.

We were able to get exports of the relevant content from both of those, from the developer of the current site. And we fed those and a whole bunch of documents from the product owner into a ongoing conversation with Claude. And we’re able to use that to build some actually node.js scripts that would take the files we’d gotten from the Sitecore devs, and build a local database in SQLite that each developer on the team was able to run locally. And we can query against that to find those edge cases.

So in a combination of writing our own manual queries, or having a chat conversation prompt for finding individual things, and then it will run a number of queries and report back to us. We’re able to identify very quickly, oh, there’s only one press release that has images, that’s interesting. But there are 17 that have a FAQ accordion.

So that type of auditing has become trivial, and it’s mind boggling how much faster that’s allowed us to move in terms of understanding the data that’s there, and building out a mapping of how we’ll migrate through the different types of content.

We don’t tend to start with only 10 pages in a post type because it’s relatively cheap to run the migrator over a thousand instead of 10. And that gives you a lot more content for both various people on the client team, but then also agentic tools to click through and do a little bit of spot check validation.

What we tend to do is to migrate content type by content type, and we’ll prioritise those based on what we see as the balance between scale and complexity.

[00:18:39] Nathan Wrigley: Do you leverage Core blocks wherever possible, or do you bring bespoke Human Made blocks where that’s necessary? Or can you basically bind everything in this particular build to a Core block?

[00:18:51] K. Adam White: Most of the time we will start with Core blocks and get as far as we can with them. This is a change from how we used to do it. Our early days, we had a lot of rapid iteration in the markup that Core blocks were using. In some cases, there was a lot of evolution in how the controls for them were set up.

[00:19:07] Nathan Wrigley: It was brutal.

[00:19:09] K. Adam White: It was brutal. But that pace of change for the main building blocks of a site has slowed down tremendously, and I think it’s a very stable foundation. So we will be pattern first in our development. We will start by working, doing a lot of in-editor prototyping actually, to build out layouts and patterns for each individual unit of content, each individual sort of component group in the source site. And, it will only be when we run into something like a carousel or a modal that we might reach for a off the shelf, third party option that’s not in Core, or bring our own solution to the table.

[00:19:45] Nathan Wrigley: So do you take, when you said pattern there, is a pattern a sub component of a, let’s say post for want of a better word? Or is it that the pattern is the entire post with bits injected into it? So paragraphs, headings, videos, whatever it may be? Like I said, at the beginning, or are you building up the entire post from various different patterns? Here’s a video pattern and here’s a, I don’t know, a paragraph pattern with a heading? Or a background image or whatever it may be.

[00:20:12] K. Adam White: Patterns tends to be at number of different levels. We might have individual patterns for a particular treatment of headline for example. But we also will have a pattern for a hero section. We’ll have a pattern for a hero section plus the bio below that, that we can use to populate a template in the site editor.

We build patterns at multiple levels of granularity, and we have a leaf to trunk system where we’ll make sure that we have renderings, whether they’re Core blocks with either default styling or one or two block variations, or individual patterns for things where we need to compose one or two blocks together. We’ll make sure that we have all of those leaf node pieces of content, all of our paragraphs, all of our inline images. And then we’ll build patterns for those higher level groups, the full width backgrounds with coloration and a particular headline treatment.

We build out those patterns at all of those different levels because it’s nice to have the granularity when we’re writing our migrators, and patterns can reference each other. So you can have an accordion pattern, which includes two references to an accordion item pattern, and you can have all of those little bits of HTML be discreet PHP files in your WordPress theme. So it makes it very simple to pull up in your editor only the code that you need to edit for a particular unit and know how that’s going to be scoped.

[00:21:26] Nathan Wrigley: This is going to sound like such a peculiar question, but it genuinely, from my point of view, this sounds like really interesting and curious work. It sounds, like there’s a lot to get your teeth into. You’re pushing the boundaries a little bit, but also you’ve got the scope of WordPress, which kind of makes it slightly easier.

I’m basically just making the comment that I think I would enjoy doing the work that you are doing. I don’t know if that, yeah, there really a question there.

[00:21:47] K. Adam White: Unfortunately, we’re doing less and less of that work, and Claude’s doing more and more of it. It’s been actually very efficient because this is such a core central construct in the WordPress block editor. There’s a lot of good documentation about it and agentic tools are quite good at helping to build pattern markup.

So, what we’ve been doing is bringing our human eyes onto that, doing all of our spot checks, making sure that things are kept as simple as possible. Because I think we’re all familiar with how verbose and overly complicated output can be from some tools. But then it is also something that I really wish more people were talking about and doing. Brian Coords earlier today in his talk, mentioned that pattern driven development really he sees as something that more and more of the WordPress community should be trying out. Because there are so many things that we used to build custom blocks for, that just strictly aren’t necessary anymore. And we can get so far by composing what we get from the lego kit of WordPress out of the box.

[00:22:40] Nathan Wrigley: Yeah, I feel like if we went back to 2015 and began Gutenberg again, I feel going patterns first would actually be a nicer approach, certainly a more straightforward approach. I know that there’s, ways to overcome that, but I always drop patterns in, never blocks, and then I’m always interacting with the blocks within the pattern. But it’s patterns first for me all the time. Just because I like the fact that I’m dropping in multiple bits of content that are pre-configured and pre-made and pre, I’ve fiddled with the CSS and made it just how I like it. And I just click the button once and there it is, and I can just rinse and repeat and it’s really straightforward.

[00:23:12] K. Adam White: I would agree, and over the past two to five releases of WordPress, we’ve also had such powerful additional tools added to the pattern toolkit. For example, Partially Synced Patterns. Was a major topic that I shared in my talk. Being able to have a reusable pattern and then make the content editable on a post by post basis makes it very seamless for a non-technical editor to go in, and not have access out of the box to stylistic controls that would make something drift from the brand’s guidelines that they’re trying to follow, but still be able to customise link targets, CTA, text, all of the descriptive and image elements.

[00:23:47] Nathan Wrigley: You are in the weeds of WordPress, and I’m in the weeds of WordPress all the time, but I still feel those tools are widely, not misunderstood, that’s the wrong, just there’s a void. Nobody even knows they’re there. There’s just tonnes of tooling inside the block editor that people simply don’t know about, because the UI and the UX is still a bit funky. You’ve got to go to various different places, and it’s easy to go down the wrong route.

Do you know what I mean? There’s a bunch of tools inside a WordPress that if you only had a few hours with somebody over your shoulder pointing out, “okay, click on that, look at that menu that does this thing.” It’s a shame in a way that’s the case. But I do feel there’s a lot of unexplored potential in every WordPress website that presumably you are leveraging. But I guess just because you’re in the weeds of it.

[00:24:30] K. Adam White: Wherever possible, we have the privilege of having a lot of history with the CMS. Human Made was founded in 2010 and has always had a strong open source posture. We’ve contributed to Core, we’ve put plugins out there in the ecosystem that are used by a number of other agencies. We’ve found the best of what our frenemy competitors use, and been able to adopt those into our own processes.

And the benefits of understanding all of the different types of block that you can use tremendously outweigh any time sink that it takes to learn them. I hope that, from my talk, people will now know that in 7.0, we added PHP only blocks, where you can have the attributes auto registered so that you get, even as a non JavaScript developer, a interface in the editor that someone can open up and go in and change values in the sidebar.

I hope that more people learn about Partially Synced Patterns. I hope more people learn about all of the different types of block that we have available, and find ways to integrate those into their own toolkits. Because playing with the grain of WordPress and using the Block Editor for all it’s worth, are how we untap the most value for our clients.

[00:25:34] Nathan Wrigley: Yeah, there is certainly an awful lot of power, and like I said, I just think some of it gets missed.

How much after you’ve done the migration, how much time do you have to spend with the clients? I have this impression that the Gutenberg editor is pretty straightforward, muscle memory for me essentially. Hours of playing in it. I know where all the bits and pieces are.

But I would also recognise that if I was to show it to somebody who’d never played with WordPress and was coming from, in this case Sitecore, how overwhelming is it? And do you take steps to make it less overwhelming by minimising what’s available in the interface, or just disabling options? What do you do in that regard?

[00:26:08] K. Adam White: No matter how much flexibility our clients want, it’s usually valuable to disable some options. I can’t remember a site we’ve shipped recently for any large website where we left the custom colour picker in, for example. You want to do a better job of limiting what people can use, so that we have confidence that the output, no matter how design savvy or not someone is, is going to be consistent with the rest of the site.

My colleague, Joeleen Kennedy, gave a talk a couple years ago at the first  WordCamp US Showcase Day back in 2024, about work we had done customising the editor for that type of simplicity. And in particular things that we can do around colour palette selection. Ways that we can hide the styling controls for certain blocks through having them embedded in a pattern.

It’s interesting to see that in WordPress recently, if you are editing content that has been marked as having come from a pattern in a post, you can edit all of the text, you can edit all of the images and link targets, but you actually have to hit edit pattern in the sidebar in some cases, depending on how the post is set up, to get into the details within the post that allow all of those other controls to be visible.

That divide took a tiny bit of adjustment for people on our client teams, but the separation has helped them stay focused on the content, and worry less about the overwhelming, combinatorial set of styling possibilities that their blocks have.

[00:27:29] Nathan Wrigley: Do you think that the necessary tools are already built into WordPress to do the kind of work that you are doing? Or is there some missing piece that would make it easier for somebody who doesn’t have the deep pockets that presumably Human Made would require, to do that kind of work. Is the default tooling usually okay to migrate things or have you had to build loads of bespoke tooling?

So in terms of if I was to approach a WordPress website and try to migrate from Sitecore over to WordPress, is this something that you absolutely need a team to do, or would you be able to get some simulation of this with Core WordPress?

[00:28:04] K. Adam White: If you had access to the exports of data from a Sitecore website, and you had a core vanilla WordPress install. And you had a LLM tool of some sort, I think that you could do a lot to get close to what you want. The LLM piece, I think enables this to be done by more people without having to be completely familiar with all of the internal nuances of WordPress. You need to direct it to the architectural pattern that you want, but we have found that it speaks Gutenberg pretty well.

[00:28:32] Nathan Wrigley: What was the name of the tool that you said you’d custom and built?

[00:28:34] K. Adam White: We had built a plugin called rehydrator.

[00:28:36] Nathan Wrigley: Okay, rehydrator, yeah.

[00:28:37] K. Adam White: rehydrator is the tool that we use to take a pattern in the theme and then use that pattern as the template when we’re bringing content over to make sure that we keep all of the styling theme side, and that our migration script doesn’t duplicate the markup specifically.

[00:28:51] Nathan Wrigley: What’s Human Made’s approach to the WordPress project in that regard? You said it was a plugin. Does that mean it’s a wordpress.org repository plugin, or is it one that you have on your own, I don’t know, GitHub repository or whatever it may be.

[00:29:01] K. Adam White: We have some things in the .org repository. In this case, that particular plugin is only on GitHub. A number of ones that we build are only on GitHub, because we’re building them for a very transient in time period of a site.

You don’t need a migration tool to be part of your site long term, it’s not something you’re going to be leaving active, and updating month over month when there is a site running. It’s something that you bring in for the purpose of populating the data. And then you can remove that.

And in that regard, for this particular one, at the moment it’s partly because it’s quite young, and it’s also because we don’t see it as being general purpose. So that plugin specifically is on GitHub and publicly available through Composer, but not on the plugin directory.

In other situations, we’ve gone the opposite direction, and anything that we see as being a ongoing value to a site as it’s running, we do try to move those over as we can.

[00:29:52] Nathan Wrigley: Given that you are on the sort of engineering side of Human Made, I don’t know if this question will land, but we seem to be in this interesting period where there’s a lot of chatter, AI kind of fits into the equation a little bit, but there’s a lot of chatter about the, market share of WordPress and whether or not WordPress as a tool will continue with the same numbers and clout and market share and all of those kind of things.

Do you notice at the enterprise level that there’s been any kind of change in a southerly direction? Maybe there’s been a direct change in a northerly direction. What I’m trying to say is, for the enterprise, does WordPress still maintain that kind of pride place, top of the tree, or are you struggling to find new clients?

[00:30:28] K. Adam White: We’re not struggling to find new clients. We’re lucky that we’re doing quite well on marketing, and we also have had a very powerful year in terms of building relationships with new enterprises, and finding ways to take the technology that we believe in and solve their problems with it.

But I would argue that WordPress has never been the top of the enterprise space. And this actually goes back to your question about what is there that might be missing inside WordPress. The biggest thing that I think someone gets from a more, I’m going to use the term loosely, traditional enterprise CMS, is control.

And WordPress has a security model where the ability to edit and publish a piece of content is usually at the post level. There’s ways to add specific permission checks for metadata. There’s ways that you can restrict what’s accessible and editable with custom interfaces and custom API endpoints. But we tend to have things fall down to the capability checks for user can edit post 1, 2, 3. Yes. No.

And that means that if you have a user profile where your organisation depends on someone being able to come in and touch only the headlines and the SEO metadata, we don’t really have a model for that right now in WordPress.

Whereas something like Sitecore, each individual, almost at the level of every string on the site, whether it’s a set of paragraphs or the label of a button, ends up as a individual node in the content tree. And those can be granted or denied to certain users on a much more granular level. So that to me is a bridge that I still am excited to see what we can do within WordPress to maybe build better interfaces, or better primitives in the editor.

Block locking helps a little bit, but it is an API that’s quite difficult for some teams to wrap their heads around. And it also doesn’t really change the fact that if you can edit the post, and you were able to get the code editor up, then if you’re able to save it, you’re able to save it and doesn’t really go block by block. You’d have to write custom validation or permissions logic in order to be able to reject and update based on the user if they’re editing a block that is next to the one that they were supposed to.

[00:32:32] Nathan Wrigley: So do you have to present to the clients? It’ll be fine. This is what WordPress has. Don’t worry too much about it. If you’ve got this permission, yep, sure. You might be able to overlap and think people could delete things or modify things that perhaps they wouldn’t have to. That’s an educational piece on your side. Go and teach everybody not to mess around with things that they shouldn’t be messing around with.

But you would wish that in WordPress you could assign, say, as you described, this H1, this person can amend it, and this person can access the colour palette for the background image over here, but they can’t access the text. That kind of really granular permission. Whereas block locking just, it seems a bit more of a blunt instrument if you know what I mean. It’s binary. It’s locked or it’s not. You’d like to unlock the capabilities within each block so that certain users can do certain things within the same block.

[00:33:15] K. Adam White: Within blocks, we tend to rely on security through obscurity. We can hide or obfuscate controls behind block locking with content only. We can hide them behind patterns. But if someone’s coming to WordPress, we do make sure that they understand upfront what the nuance of control will be. And we will work with them usually to make things more editable.

Again, I will mention that most of the projects that we get that come from one of these more control-oriented CMSs into WordPress, what they’re seeking is actually more flexibility, not less. So they’re making a decision that they are willing to exchange the stringent control that they get in their existing tool for a process-based change. Maybe they add a review step, or add some sort of workflow plugin, so that we can validate that things look good and have someone sign off on it before it gets published. They would prefer to go that route than to sacrifice the ability for the editors to have the full control, and full pallet of options available to them.

[00:34:13] Nathan Wrigley: Right, so that’s a much more loose approach. Everybody can maybe do more than they ought to do. If we have some editorial guideline where that can’t finally hit the public domain because the publish button is unavailable to you, that’s, okay. We’ll accept that kinda halfway house, if you like. That’s interesting.

[00:34:30] K. Adam White: Each client’s needs are going to be slightly different. We do layer in publication checklists. We have tools to be able to say, this has to be tagged with the primary category before it goes live. We have tools to say, this still has lorum ipsum in it. You can add those in and build workflows, but I tend to like to help clients build processes to support those, rather than trying to take a draconian approach and lock everything down. Because then your work is going to be constantly chasing fine-grained permissions controls when you could be working to use that time making sure that all of the editors know what they can do.

[00:35:04] Nathan Wrigley: I just want to drill into this a bit more. I know this isn’t where we were supposed to go, but I find it really interesting. Would you like those things to ship in Core? obviously they suit you down to the ground, all of those granular permissions, but do you think that belongs in Core?

[00:35:17] K. Adam White: I think that we need more workflow in Core.

[00:35:20] Nathan Wrigley: Okay.

[00:35:20] K. Adam White: I know that there’s a number of different agencies and hosts which each have developed our own workflows solutions. I’ve worked across a number of them on projects that I’ve helped to support.

But the notion that if you have something published and you make an edit out of the box, WordPress will automatically put live any further changes that you make to a published post when you hit save. That is probably the single thing that we most frequently have to build some type of plugin into a site to handle.

Because we need to be able to give people an editorial review step. So that is something that I think we have a number of good tools, but I would love to see a more opinionated default in Core that we can use as a foundation for more complicated post editorial workflow. I think that’s the thing that we most frequently run into. That, and also I guess internationalisation are probably the two things that hopefully will come to the surface of the WordPress roadmap over time.

[00:36:13] Nathan Wrigley: Yeah, I’d really not thought about that. Given Human Made’s sort of credentials and what have you. Do you have a lot of clout? Do you just punch above your weight in conversations about what makes it into Core? Do you get involved in those discussions? I’ve literally no idea how that would happen. Do you communicate to people when a release is coming around. Do you have a voice? Do you make yourself available? What is Human Made’s position in terms of getting things pushed into Core?

[00:36:37] K. Adam White: We participate in the project. I personally have been less involved in Core over the past several years than I would have hoped. I’ve been very much enjoying the detailed, quite close to the ground work that I’m doing on our agency projects. But unfortunately, I have taken a bit of a step back on the open source project.

Some of my colleagues are in a slightly different boat. My colleague, John Blackbourn, our Director of Security for our own hosting product is also the head of the Security Team for WordPress? And has been helping us get the core patches out for the recent set of security releases.

We obviously will advocate in calls for feedback within the Gutenberg project when we feel that there’s a particular direction that we see from our projects. We are able to provide feedback on the UI, and the capabilities of new blocks that are being proposed. But that’s all done through the normal Gutenberg GitHub issue, and WordPress

[00:37:28] Nathan Wrigley: So I think we should probably knock it on the head there. We’ve reached our allocated time. I’ll just point out that these days, it used to be the case that if I was at a WordCamp, you’d really have to wait about six months before the video for the presentation was available. I’m pretty sure it’ll be done already, in all honesty. 24 hours seems to be the time there. So if you were to go to WP Tavern, I will make sure that the link to the video, of K. Adam is there. If not, you can probably go to Google and search Migrating to Blocks, and in parenthesis, with Artisanal Care at Industrial Scale, and you’ll be able to see what it is that K. Adam was talking about.

But really, thank you so much for chatting to me today about all of that.

[00:38:06] K. Adam White: Thank you very much. And I can confirm that the video is already live on YouTube.

On the podcast today we have K. Adam White, or K. Adam for short.

K. Adam is the principal engineer at Human Made, an enterprise WordPress consultancy. He’s been involved with WordPress almost 20 years, attended his first WordCamp in Boston back in 2011, and has contributed to WordPress Core and the broader open source ecosystem. Human Made is known for delivering complex projects, think high stakes, no room for mistakes, from global brands moving to WordPress.

This time around, K. Adam delivered a presentation at WordCamp US focused on a crucial topic for anyone modernising their site, migrating to blocks. Human Made has been all-in on the block editor since the Gutenberg plugin days, and the team now specialises in large-scale migrations from other content management systems like Sitecore, as well as from other WordPress page builders.

Our conversation focused on the technical and editorial challenges of moving tens or hundreds of thousands of posts into the world of blocks and patterns. We talked about the need to combine “artisanal care”, attention to detail in design, layout, and brand, with “industrial scale”, the ability to automate, audit, and validate mass migrations without losing visual fidelity.

We also discussed the use of patterns as a foundation for development, integrating custom and Core blocks, and leveraging new tools (including AI-powered agents and open source plugins like Human Made’s own rehydrator) to streamline migration workflows. We also touched upon how clients are onboarded, the process of auditing legacy content, strategies for training editorial teams on the block editor, and there’s a frank reflection on gaps in WordPress, like granular content permissions.

If you’re contemplating a move to the block editor, wrestling with a massive content migration, or curious about what happens when enterprise complexity meets the flexibility of WordPress, this episode is for you.

Useful links

Human Made

Migrating to Blocks (With Artisanal Care, at Industrial Scale) – K. Adam’s presentation at WordCamp US 2026

Human Made’s rehydrator plugin on GitHub

वर्डप्रेस ने मुझे मेरे ज़िंदगी में कुछ अलग करने का मौक़ा दिया।

Introduction

My name is Satyam Vishwakarma, though most people know me as Satya. 

I come from a small village called Mahmadpur, near Fatehpur, the city of Doaba, in Uttar Pradesh, nestled between the sacred Ganga and Yamuna rivers. This is the place I’ve always called home.

I studied Electronics Engineering (Micro) at Government Polytechnic College in Fatehpur. Growing up and studying in a relatively small city, I never had a clear idea of where technology or the internet could take me.

I didn’t discover WordPress with a big career plan. I was simply curious about technology and wanted to help the people around me.

Most of my classmates, including me, came from Hindi-medium schools or the UP Board. A lot of the technical material we found online was either difficult to understand or simply wasn’t written in the kind of simple English we were comfortable with.

At the same time, I was probably one of the more tech-savvy people around me. I loved trying new software, exploring new features, and figuring out how things worked. Whenever I discovered something interesting, I would share it with my WhatsApp groups and classmates.

I didn’t think of that as writing or teaching at the time.

I was simply sharing something I had discovered.

Eventually, I thought: why not put some of this information somewhere that more people could find it?

That small thought became the beginning of my writing career.

Before WordPress, there was Blogger

Some of my earliest opportunities to write online came through people I met on WhatsApp.

I became friends with Mohit Vyas and Arpit Nuwal through one of the technology-focused WhatsApp groups I was part of. They had built a website called TopJankari. It wasn’t running on WordPress. It was a custom-built, dynamic website with its own basic way of managing content, but it was still fairly simple compared with the content management systems I discovered later.

I started writing technology and tips-related content for TopJankari.

For me, this was exciting. I was taking the things I was already experimenting with and turning them into something that other people could actually read and use.

Around the same time, I started experimenting with Blogger.com and began publishing my own technology and tips-related content there.

I wasn’t thinking about becoming a professional writer.

I just enjoyed technology; I enjoyed explaining things, and I liked the idea that something I wrote could help another person solve a problem.

That was enough motivation to keep going.

Then WordPress entered the picture

While I was experimenting with blogging, my brother Shivam (now runs a WordPress design agency called Subhash Digital) built his first website with WordPress.

That caught my attention.

I was already curious about how websites worked, and seeing him build something with WordPress gave me an idea of what was possible. I wanted to try it myself.

Around the same time, my brother Kapil and I started learning WordPress together.

Neither of us really knew what we were doing.

We learned through YouTube videos, documentation, blog posts, and mostly through experimentation.

We would try something, break it, search for why it broke, fix it, and move on to the next thing.

My first WordPress project was EngineersGuru, a place where I could share content related to my Electronics Engineering (Micro) course. 

I initially ran it as a subdomain, with the idea of making useful course-related tutorials and information easier for fellow students to understand.

We also started an Android-related blog and Jankari.xyz, a more general website where I could write about pretty much anything I found interesting.

In hindsight, those websites were my playground.

They were where I learned WordPress, writing, SEO, content creation, and the basics of running websites.

I wasn’t following a carefully designed career path. I was just building things because I wanted to see what I could do.

And that curiosity kept taking me somewhere new.

Learning by failing

As I continued blogging, I started learning about SEO, monetization, and affiliate marketing.

I experimented with different kinds of websites and eventually built more than ten blogs while I was still learning.

One of my projects eventually became EYNZone (formerly known as EYNWorld), where I started helping others learn WordPress and other skills and grow their own projects.

There were plenty of failures along the way.

I applied for Google AdSense more than twenty times before I finally stopped guessing and actually studied the guidelines carefully. Eventually, I got a brand-new domain approved with only two articles.

That experience stayed with me.

It taught me that rejection doesn’t necessarily mean you aren’t capable.

Sometimes you simply haven’t figured out the problem yet.

That became a recurring theme in my life.

Looking for a career, finding a community

Eventually, I started looking for a full-time job in mid 2022.

That was another learning experience, although not always a pleasant one.

I applied to more than 800 companies and went through around 2,000 job applications.

During that period, I discovered UnderrepresentedInTech through Michelle Frechette. That eventually introduced me to Post Status, where I started meeting more people from the WordPress ecosystem.

Something interesting was happening.

While I was struggling to find where I fit professionally, I was slowly finding a place for myself in WordPress.

I started learning not just about the software, but about the project behind it and the people who were building it.

And then I heard about WordCamp Bhopal.

The WordCamp I almost couldn’t attend

My first WordCamp was WordCamp Bhopal in 2023.

I wanted to go.

I had told people I would go.

There was just one problem: I didn’t have the money to actually make the trip happen.

So I asked for help in the Post Status Slack community.

I still think about what happened next.

People who had never met me in person decided to help. Alan, Jenni, and Corey Maass contributed financially. Michelle, Jeff, and others shared my request, and Ronald (from DLXPlugins) also helped after seeing it.

People I barely knew, or had never met at all, helped me get to an event that I otherwise couldn’t have attended.

I made it to Bhopal.

The journey itself was almost comical. I travelled at the last moment, ended up at the wrong location at night, and then had an entire hotel saga before things finally settled down.

But once I got there, none of that really mattered.

Later at the event, Nabin Jaiswal also helped.

I met people I had previously known only through websites, Slack, and social media.

And then something unexpected happened.

I wanted to go to another WordCamp.

Then another.

That first trip was followed by WordCamp Mumbai, WordCamp Udaipur, where I received a scholarship, and WordCamp Ahmedabad in 2023.

Within a few months, WordPress had gone from something I used on my computer to something I experienced through people.

It had faces now.

Names.

Conversations.

Handshakes.

People asking how I was doing.

And I wanted to give something back.

I didn’t know how much I could contribute

I started with the Marketing team and gradually found my way into other parts of the project: Community, Meetups, Polyglots, Photos, Training, and Core.

In January 2024, I published a public contribution goal for myself.

My #WordPress contribution goals for 2024:
1. Contribute 100 photos
2. Translate 5000 strings
3. Write 5 documentation pieces
4. Organize meetups
5. Attend 8+ WordCamps
6. Make impactful marketing contributions! #OpenSource #WordPressCommunity #2024Goals pic.twitter.com/uLxE0BdYVL

— Satyam Vishwakarma (Satya) (@ask_hellosatya) January 17, 2024

I wanted to contribute 100 photos, translate thousands of strings, work on documentation and training, organize meetups, attend WordCamps, volunteer at events, and make meaningful contributions to marketing.

At the time, it was simply a list of things I wanted to try.

I didn’t know where it would lead.

Within that year, I contributed around 150 photos and translated, reviewed, or suggested around 1,400 strings. I also reviewed Training content, organized my first meetup for WordPress’s 21st birthday, graduated as a mentee in the WordPress Contributor Mentorship Program 2nd Cohort for Support and Polyglots, worked on marketing for releases and events, volunteered at multiple events, and eventually led Contributor Day tables.

I also became a Project Manager at do_action Bhopal after starting there as a Content and Social Media Manager.

I also volunteered at PHPCamp 2024, an Un(conference) inspired by the BarCamp format.

Other WordCamp Events I Attended in 2025–2026

I also helped with sponsorships and the overall program progress of WPSimplified’s three-month live WordPress training program, led by Sunil Kumar Sharma, which ran from November 2025 to January 2026.

On paper, those things look like achievements.

But that’s not how I remember them.

I remember sitting in meetings, wondering whether my idea was good enough.

I remember asking questions.

I remember people patiently explaining things.

I remember realizing that I could actually be useful.

And I remember the feeling of seeing something I had worked on become part of something much bigger than me.

That was when contribution started becoming less about “what can I get from WordPress?” and more about “what can I give back?”

The people became the story

The more I contributed, the more people I met.

Some of them became friends.

Some became mentors.

Some simply inspired me by watching how they showed up for the community.

Michelle Frechette has been one of those people for me. So have Topher DeRosia, Isotta Peira, Nidhi Jain, Ganga Kafle, and many others.

What I admire about people like them isn’t just what they have achieved.

It’s the way they make other people feel that there is room for them, too.

That matters when you’re coming from somewhere like Fatehpur and trying to find your place in a global community.

You don’t always need someone to give you an opportunity.

Sometimes you just need someone to make you believe that you are allowed to try.

I’ve been fortunate to have people do that for me.

From contributing to building

By my second year, I started wanting to build things of my own within the WordPress ecosystem.

I volunteered and led the marketing team alongside Emma Young at WordCamp Asia 2025 in Manila.

I started building plugins of my own, with contributions and support from Harish, Bhargav, Makarand Mane, Hitanshu Sahu, and Sajid Ansari.

The first was QuoteFrameShare.

It lets people create and share customizable blockquotes in WordPress.

That project was particularly meaningful to me because writing and poetry have always been a part of who I am. Something that started with me writing technology tutorials for fellow engineering students had now come full circle into something I was building for writers, poets, and storytellers.

The second was Contributor Photo Gallery.

It helps WordPress contributors display their WordPress.org photo contributions as a portfolio without needing to write code.

That one came from another part of my journey: photography and the WordPress Photo Directory.

I liked that both projects solved relatively simple problems, but for communities and people I actually cared about.

I wasn’t just building a plugin because I could.

I was building something because I had an idea and thought it could be useful to someone else.

Not everything went smoothly

My WordPress journey hasn’t been a straight line upward.

There was a period when I became so enthusiastic about contributing that I started trying to do everything.

Every team.

Every opportunity.

Every event.

Every possible contribution.

I was so focused on proving that I could contribute that I wasn’t paying enough attention to everything else in my life.

Eventually, I burned out.

I also learned that community work has its own challenges. Not every experience was positive, and there were moments when I felt overlooked, misunderstood, or discouraged.

Those experiences were difficult, but they also forced me to think about what I actually wanted from contribution.

I realized that I didn’t want to spend my time trying to prove that I belonged.

I wanted to contribute because I cared about the project and the people in it.

That changed how I look at contribution today.

I learned that I didn’t need to be everywhere, collect every badge, or chase the biggest contribution count to prove that I cared. 

I needed to find a way of contributing that I could actually sustain.

I also realized I didn’t need to sacrifice my health, livelihood, or peace of mind to prove that I cared.

If you have one hour a week, contribute that hour.

If you have more time, great.

But contribution should be sustainable.

The support that I will never forget

One of the reasons I can talk about the difficult parts honestly is that the positive side of this community has been very real for me too.

People have supported me in ways they didn’t have to.

The help I received to attend my first WordCamp is one example.

Katie at Barn2 later sponsored a couple of my WordCamp trips through the company’s events budget. Makarand nominated me for the Yoast Care Fund, which I was fortunate enough to receive.

The WP Open Community Collective also supported me through a Contributor Day Lead Sponsorship sponsored by GoDaddy.

And there were people who helped in ways that weren’t financial at all.

People gave me their time.

They answered questions.

They recommended me.

They encouraged me when I was uncertain.

Those things can be easy to overlook when you are talking about contribution numbers, but for me, they are the real story.

Because behind every contribution is usually a person.

And behind my contributions are a lot of people who helped me get there.

What WordPress gave me

When I look back at the person who started writing technology tutorials for fellow engineering students, I don’t think he would have imagined any of this.

I didn’t have a conventional path into technology.

I didn’t study computer science.

I learned WordPress by building things, breaking things, and figuring them out.

And somehow, that was enough to get started.

WordPress helped me develop skills in technology, content, SEO, marketing, product building, and community.

It gave me opportunities to work with people around the world.

It took me to WordCamps that I once couldn’t afford to attend.

It helped me build open-source products.

But those aren’t the things I value most.

The biggest thing WordPress gave me was people.

That’s why the word ‘belonging’ feels more appropriate to me than ‘success.’

I came to WordPress to build websites.

Somewhere along the way, WordPress helped me build a community around me.

I am still figuring it out

I still don’t know exactly where WordPress will take me.

I want to keep building products.

I want to grow further in the marketing and product side of my career.

I want to explore more around partnerships and community.

And one day, I’d love to co-lead a WordPress release.

But I don’t want to chase these things just for a title or a badge.

I want to build things that are genuinely useful.

I want to become better at what I do.

I want to help people who are where I was a few years ago.

And I want to be the kind of person who, when someone remembers their first steps into WordPress, they can say: “Satya helped me get started.”

That would mean more to me than any badge.

Because that’s what happened to me.

People helped me get started.

People made space for me.

People encouraged me.

People believed I could contribute before I was completely sure myself.

So if someone reading this is just starting their WordPress journey, my advice is simple:

Start small. Ask questions. Find something you enjoy. Contribute consistently, but within your capacity.

You don’t need to have everything figured out before you begin.

I certainly didn’t.

I started writing because I wanted to make complicated things easier for my classmates.

I started blogging because I was curious about technology.

I started using WordPress because my brother showed me what was possible.

I kept learning because there was always something new to discover.

And eventually, I started contributing because I wanted to give something back.

But somewhere along the way, something else happened.

I found people.

I found opportunities.

I found a community.

And I found a place where I could keep learning, contributing, and becoming a little better than I was before.

I came to WordPress to build websites.

Somewhere along the way, WordPress helped me build a community around me.

And maybe that’s what this journey has really been about.

From blogging to belonging.

Blogging से Belonging तक: मेरी WordPress Journey

शुरुआत

मेरा नाम सत्यम विश्वकर्मा है, हालांकि ज़्यादातर लोग मुझे सत्या के नाम से जानते हैं। 

मैं महमदपुर नाम के एक छोटे से गाँव से आता हूँ, जो उत्तर प्रदेश के फतेहपुर, दोआब के शहर, के पास है और गंगा और यमुना नदियों के बीच बसा है। यह जगह हमेशा से मुझे अपना घर लगी है।

मैंने फतेहपुर के Government Polytechnic College से Electronics Engineering (Micro) की पढ़ाई की। एक छोटे शहर में बड़े होते और पढ़ते हुए मुझे कभी ठीक से अंदाज़ा नहीं था कि technology या internet मुझे कहाँ तक ले जा सकते हैं।

मैं WordPress तक किसी बड़े career plan के साथ नहीं पहुँचा था। मैं बस technology को लेकर उत्सुक था और अपने आसपास के लोगों की मदद करना चाहता था।

मेरे ज़्यादातर classmates, मेरी तरह, Hindi-medium schools या UP Board से पढ़े हुए थे। 

हमें इंटरनेट पर मिलने वाली बहुत-सी technical सामग्री या तो समझना मुश्किल होती थी या फिर वह उस तरह की आसान English में नहीं होती थी, जिसे हम सहजता से समझ सकें।

साथ ही, मैं शायद अपने आसपास के लोगों में technology को लेकर थोड़ा ज़्यादा curious था। 

मुझे नया software आज़माना, नए features explore करना और यह समझना बहुत पसंद था कि चीज़ें कैसे काम करती हैं। 

जब भी मुझे कुछ interesting मिलता, मैं उसे अपने WhatsApp groups और classmates के साथ share करता था।

उस समय मैंने इसे writing या teaching के तौर पर नहीं देखा था।

मैं बस वही share कर रहा था जो मैंने खुद discover किया था।

फिर एक दिन मन में आया: 

क्यों न इस information को कहीं ऐसी जगह रखा जाए, जहाँ इसे और लोग भी ढूँढ सकें?

वही छोटी-सी सोच मेरी writing journey की शुरुआत बन गई।

WordPress से पहले Blogger था

Online लिखने के मेरे शुरुआती मौकों में से कुछ मुझे WhatsApp पर मिले लोगों की वजह से मिले।

मैं technology से जुड़े एक WhatsApp group के ज़रिए Mohit Vyas और Arpit Nawal से online मिला। उन्होंने TopJankari नाम की website बनाई थी।

वह WordPress पर नहीं चलती थी। वह एक custom-built, dynamic website थी, जिसमें content manage करने का अपना basic system था। बाद में मुझे जिन content management systems के बारे में पता चला, उनकी तुलना में वह काफी simple थी।

मैंने TopJankari के लिए technology और tips से जुड़ा content लिखना शुरू किया।

मेरे लिए यह बहुत exciting था।

जिन चीज़ों को मैं खुद आज़मा रहा था, उन्हें मैं अब इस तरह लिख रहा था कि कोई दूसरा भी उन्हें पढ़कर इस्तेमाल कर सके।

उसी दौरान मैंने Blogger.com के साथ भी experiment करना शुरू किया और वहाँ अपना technology और tips-related content publish करने लगा।

उस समय मैं professional writer बनने के बारे में नहीं सोच रहा था।

मुझे बस technology पसंद थी। मुझे चीज़ों को समझाना पसंद था। और मुझे यह विचार अच्छा लगता था कि मेरे द्वारा लिखी गई कोई चीज़ किसी दूसरे व्यक्ति की समस्या हल करने में मदद कर सकती है।

मेरे लिए इतना ही काफी था आगे बढ़ते रहने के लिए।

फिर WordPress मेरी कहानी में आया

जब मैं blogging के साथ experiment कर रहा था, मेरे भाई Shivam ने उस समय तक WordPress पर अपनी पहली website बना ली थी।

इसने मेरा ध्यान खींचा।

मैं पहले से ही websites के काम करने के तरीके को लेकर curious था।

उनको WordPress के साथ कुछ बनाते हुए देखकर मुझे पहली बार अंदाज़ा हुआ कि इसके साथ क्या-क्या बनाया जा सकता है। 

मैं भी इसे आज़माना चाहता था।

उसी दौरान मेरे भाई Kapil और मैंने साथ मिलकर WordPress सीखना शुरू किया।

हम दोनों को वास्तव में कुछ खास पता नहीं था।

हमने YouTube videos, documentation, blog posts और सबसे ज़्यादा experimentation के ज़रिए सीखा।

हम कुछ try करते, उसे तोड़ देते, फिर search करते कि वह क्यों टूटा, उसे ठीक करते और फिर अगली चीज़ पर बढ़ जाते।

मेरा पहला WordPress project EngineersGuru था। वहाँ मैं अपनी Electronics Engineering (Micro) की पढ़ाई से जुड़ा content शेयर (publish) करता था।

शुरुआत में मैंने इसे एक subdomain के रूप में चलाया। मेरा उद्देश्य था कि मेरे fellow students के लिए course से जुड़ी tutorials और useful information को समझना थोड़ा आसान हो सके।

हमने एक Android-related blog भी शुरू किया और Jankari.xyz भी, जो एक ऐसी general website थी जहाँ मैं लगभग किसी भी ऐसी चीज़ के बारे में लिख सकता था जो मुझे interesting लगती थी।

आज पीछे मुड़कर देखता हूँ तो ये websites मेरे लिए एक playground थीं।

यहीं मैंने WordPress, writing, SEO, content creation और websites चलाने की basic बातें सीखीं।

मैं किसी carefully planned career path पर नहीं चल रहा था।

मैं बस चीज़ें बना रहा था, क्योंकि मैं देखना चाहता था कि मैं क्या कर सकता हूँ।

और मेरी वही curiosity मुझे लगातार कहीं न कहीं आगे ले जाती रही।

गलतियों से सीखना

जैसे-जैसे blogging आगे बढ़ी, मैंने SEO, monetization और affiliate marketing के बारे में सीखना शुरू किया।

मैंने अलग-अलग तरह की websites के साथ experiment किया और सीखते-सीखते दस से ज़्यादा blogs बनाए।

मेरे इन्हीं projects में से एक आगे चलकर EYNZone बना, जिसे पहले EYNWorld के नाम से जाना जाता था। वहाँ मैंने दूसरे लोगों को WordPress और दूसरी skills सीखाने और अपने projects को grow करने में मदद करना शुरू किया।

इस रास्ते में बहुत सारी असफलताएँ भी आईं।

मैंने Google AdSense के लिए बीस से ज़्यादा बार apply किया, और हर बार कुछ न कुछ गलत हो जाता था। आखिरकार मैंने सिर्फ अंदाज़ा लगाना बंद किया और guidelines को सही से पढ़ना और समझना शुरू किया।

आखिर में एक बिल्कुल नए domain पर सिर्फ दो articles के साथ मेरा AdSense approve हो गया।

उस अनुभव का असर मुझ पर रह गया।

इसने मुझे सिखाया कि rejection का मतलब हमेशा यह नहीं होता कि आप capable नहीं हैं।

कभी-कभी इसका मतलब सिर्फ इतना होता है कि आपने अभी तक समस्या को समझा नहीं है।

मेरी ज़िंदगी में यह बात बार-बार सामने आती रही।

Career की तलाश में निकला था, Community मिल गई

आखिरकार, 2022 के बीच में मैंने full-time नौकरी की तलाश शुरू की।

वह भी अपने आप में एक learning experience था, हालांकि हमेशा अच्छा नहीं था।

मैंने 800 से ज़्यादा companies में apply किया और करीब 2,000 job applications के process से गुज़रा।

इसी दौरान मुझे Michelle Frechette के ज़रिए UnderrepresentedInTech के बारे में पता चला। वहाँ से आगे मुझे Post Status से जुड़ने का मौका मिला, जहाँ मैंने WordPress ecosystem के और लोगों से मिलना शुरू किया।

कुछ interesting हो रहा था।

जहाँ मैं यह समझने की कोशिश कर रहा था कि professionally मेरी जगह कहाँ है, वहीं धीरे-धीरे WordPress में मुझे अपनी जगह मिल रही थी।

मैं सिर्फ software के बारे में नहीं सीख रहा था।

मैं उस project के बारे में सीख रहा था जो software के पीछे था, और उन लोगों के बारे में भी जो उसे बनाने में मदद कर रहे थे।

और फिर मैंने WordCamp Bhopal के बारे में सुना।

वह WordCamp जिसे मैं लगभग attend नहीं कर पाता

मेरा पहला WordCamp, WordCamp Bhopal 2023 था।

मैं जाना चाहता था।

मैंने लोगों से कह भी दिया था कि मैं जाऊँगा।

बस एक समस्या थी।

मेरे पास उस trip के लिए पैसे नहीं थे।

इसलिए मैंने Post Status Slack community में मदद माँगी।

आज भी मैं सोचता हूँ कि उसके बाद क्या हुआ था।

जिन लोगों ने मुझे कभी सामने से देखा तक नहीं था, उन्होंने मेरी मदद करने का फैसला किया।

Alan, Jenni और Corey Maass ने financially मदद की। Michelle, Jeff और दूसरे लोगों ने मेरी request को share किया। Ronald, जो DLXPlugins से हैं, उन्होंने भी इसे देखकर मदद की।

जिन लोगों को मैं मुश्किल से जानता था, या शायद कभी मिला ही नहीं था, उन्होंने मुझे उस event तक पहुँचने में मदद की जहाँ मैं अपने दम पर नहीं जा सकता था।

मैं Bhopal पहुँच गया।

और वह सफ़र अपने आप में काफ़ी उलझनों से भरा था।

मैंने आखिरी समय में यात्रा शुरू की, रात में गलत जगह पहुँच गया और फिर होटल को लेकर एक अलग ही किस्सा शुरू हो गया। आखिरकार, किसी तरह सब ठीक हुआ।

लेकिन जब मैं वहाँ पहुँच गया, तो इनमें से किसी चीज़ की उतनी importance नहीं रही।

Event के दौरान Nabin Jaiswal ने भी मेरी मदद की।

मैं उन लोगों से मिला जिन्हें अब तक सिर्फ websites, Email, Slack और social media के ज़रिए जानता था।

और फिर कुछ unexpected हुआ।

मेरा मन हुआ कि मैं एक और WordCamp में जाऊँ।

फिर एक और।

उस पहली trip के बाद WordCamp Mumbai, WordCamp Udaipur, जहाँ मुझे scholarship मिली, और WordCamp Ahmedabad आए।

कुछ ही महीनों में WordPress मेरे लिए computer पर इस्तेमाल की जाने वाली किसी चीज़ से बदलकर लोगों के ज़रिए अनुभव की जाने वाली चीज़ बन गया था।

अब उसके चेहरे थे।

नाम थे।

बातचीत थी।

हाथ मिलाना था।

लोग पूछते थे कि मैं कैसा हूँ।

और मेरा मन हुआ कि अब मुझे भी कुछ वापस देना चाहिए।

मुझे नहीं पता था कि मैं कितना contribute कर सकता हूँ

मैंने शुरुआत Marketing team से की और धीरे-धीरे WordPress project के दूसरे हिस्सों तक पहुँचता गया: Community, Meetups, Polyglots, Photos, Training और Core।

जनवरी 2024 में मैंने अपने लिए एक public contribution लक्ष्य बनाया।

मैं 100 photos contribute करना चाहता था, हजारों strings translate करना चाहता था, documentation और training पर काम करना चाहता था, meetups organize करना चाहता था, WordCamps attend करना चाहता था, events में volunteer करना चाहता था और marketing में meaningful contributions देना चाहता था।

उस समय यह बस उन चीज़ों की एक list थी जिन्हें मैं try करना चाहता था।

मुझे नहीं पता था कि यह मुझे कहाँ ले जाएगी।

उस साल मैंने करीब 150 photos contribute कीं और लगभग 1,400 strings को translate, review या suggest किया। मैंने Training content भी review किया, WordPress के 21st birthday के लिए अपना पहला meetup organize किया, releases और events के marketing पर काम किया, कई events में volunteer किया और Contributor Days में tables भी lead करने लगा।

मैं do_action Bhopal में Content and Social Media Manager के लिए चुना गया और बाद में Project Manager बना दिया गया।

कागज़ पर देखें तो ये सब achievements लगती हैं।

लेकिन मुझे ये इस तरह याद नहीं हैं।

मुझे meetings याद हैं, जहाँ मैं सोचता था कि मेरा idea सही भी है या नहीं।

मुझे अपने सवाल पूछना याद है।

मुझे याद है कि लोग धैर्य से चीज़ें समझाते थे।

मुझे याद है वह एहसास जब मुझे पहली बार लगा कि मैं वास्तव में useful हो सकता हूँ।

और मुझे वह feeling याद है जब मेरे काम की कोई छोटी-सी चीज़ मेरे से कहीं बड़ी किसी चीज़ का हिस्सा बन गई।

शायद वहीं से contribution मेरे लिए बदलना शुरू हुआ।

यह सवाल कम होने लगा कि:

“मुझे WordPress से क्या मिल सकता है?”

और उसकी जगह एक दूसरा सवाल आने लगा:

“मैं WordPress को क्या दे सकता हूँ?”

कहानी में लोग आने लगे

जितना मैं contribute करता गया, उतने ही ज़्यादा लोगों से मिलता गया।

कुछ दोस्त बन गए।

कुछ mentors बन गए।

कुछ ऐसे लोग थे जिन्होंने बस community में जिस तरह अपनी जगह बनाई और दूसरों के लिए मौजूद रहे, उससे मुझे inspiration मिली।

Michelle Frechette मेरे लिए ऐसे ही लोगों में से एक रही हैं। उनके साथ Topher DeRosia, Isotta Peira, Nidhi Jain, Ganga Kafle, और कई दूसरे लोग भी हैं।

मैं इन लोगों से सिर्फ इसलिए प्रभावित नहीं हूँ कि उन्होंने क्या हासिल किया है।

बल्कि इसलिए कि वे दूसरों को यह महसूस कराते हैं कि उनके लिए भी जगह है।

जब आप Fatehpur जैसी जगह से आते हैं और एक global community में अपनी जगह बनाने की कोशिश करते हैं, तो यह बहुत मायने रखता है।

हर बार किसी का आपको opportunity देना ज़रूरी नहीं होता।

कभी-कभी आपको सिर्फ किसी ऐसे व्यक्ति की ज़रूरत होती है जो आपको यह विश्वास दिला दे कि:

“हाँ, तुम भी कोशिश कर सकते हो।”

मैं खुशकिस्मत हूँ कि मेरी journey में ऐसे लोग आए।

Contribution से building तक

मेरे दूसरे साल तक आते-आते मेरे मन में WordPress ecosystem के अंदर अपने कुछ products बनाने की इच्छा होने लगी।

मैंने WordCamp Asia 2025 में Manila में Emma Young के साथ marketing team में lead किया और volunteer किया।

इसके साथ मैंने अपने plugins बनाना भी शुरू किया, जिसमें Harish, Bhargav, Makarand Mane, Hitanshu Sahu, और Sajid Ansari के contributions और support ने मदद की।

पहला था QuoteFrameShare

यह लोगों को WordPress में customizable blockquotes बनाने और share करने की सुविधा देता है।

यह project मेरे लिए खास था क्योंकि writing और poetry हमेशा से मेरी ज़िंदगी का हिस्सा रहे हैं।

जिस चीज़ की शुरुआत fellow engineering students के लिए technology tutorials लिखने से हुई थी, वह अब घूमकर ऐसे product तक पहुँच गई थी जिसे writers, poets और storytellers के लिए बनाया जा रहा था।

दूसरा था Contributor Photo Gallery

यह WordPress contributors को अपनी WordPress.org photo contributions को बिना code लिखे एक portfolio की तरह दिखाने में मदद करता है।

यह मेरी journey के एक और हिस्से से आया था: photography और WordPress Photo Directory।

मुझे अच्छा लगा कि दोनों projects छोटी और relatively simple problems को solve करते थे, लेकिन उन communities और लोगों के लिए, जो मेरे लिए सच में मायने रखते थे।

मैं सिर्फ इसलिए plugin नहीं बना रहा था क्योंकि मैं बना सकता था।

मैं इसलिए कुछ बना रहा था क्योंकि मेरे पास एक idea था और मुझे लगा कि वह किसी और के लिए useful हो सकता है।

सब कुछ हमेशा ठीक नहीं रहा

मेरी WordPress journey हमेशा सीधी ऊपर की ओर जाने वाली कहानी नहीं रही।

एक समय ऐसा भी आया जब contribution को लेकर मेरा उत्साह इतना बढ़ गया कि मैं सब कुछ करने की कोशिश करने लगा।

हर team।

हर opportunity।

हर event।

हर possible contribution।

मैं यह साबित करने में इतना व्यस्त हो गया था कि मैं contribute कर सकता हूँ कि मैंने अपनी ज़िंदगी की बाकी चीज़ों पर पर्याप्त ध्यान देना शुरू नहीं किया।

आखिरकार, मैं burnout हो गया।

मैंने यह भी सीखा कि community work की अपनी challenges होती हैं।

हर experience अच्छा नहीं था। कुछ ऐसे moments भी आए जब मुझे लगा कि मेरी बात को देखा नहीं गया, मुझे समझा नहीं गया या मैंने discouraged महसूस किया।

वे experiences आसान नहीं थे।

लेकिन उन्होंने मुझे यह सोचने पर मजबूर किया कि आखिर मैं contribution से क्या चाहता हूँ।

मुझे एहसास हुआ कि मैं अपना समय यह साबित करने में नहीं लगाना चाहता था कि मैं belong करता हूँ।

मैं contribute इसलिए करना चाहता था क्योंकि मुझे इस project और इसमें शामिल लोगों की परवाह थी।

इसने contribution को देखने का मेरा तरीका बदल दिया।

मुझे समझ आया कि मुझे हर जगह होना ज़रूरी नहीं है। हर badge collect करना ज़रूरी नहीं है। सबसे बड़ा contribution count हासिल करना भी ज़रूरी नहीं है ताकि मैं यह साबित कर सकूँ कि मुझे परवाह है।

मुझे बस ऐसा तरीका ढूँढना था जिससे मैं लंबे समय तक contribute कर सकूँ।

मुझे यह भी समझ आया कि यह साबित करने के लिए कि मुझे परवाह है, मुझे अपनी health, livelihood या peace of mind को sacrifice करने की ज़रूरत नहीं है।

अगर आपके पास हफ्ते में सिर्फ एक घंटा है, तो उतना ही contribute कीजिए।

अगर आपके पास ज़्यादा समय है, तो बहुत अच्छी बात है।

लेकिन contribution sustainable होना चाहिए।

वह support जिसे मैं कभी नहीं भूलूँगा

शायद यही वजह है कि मैं अपनी journey के मुश्किल हिस्सों के बारे में भी ईमानदारी से बात कर सकता हूँ, क्योंकि इस community का positive side भी मेरे लिए उतना ही वास्तविक रहा है।

लोगों ने मेरी ऐसे तरीकों से मदद की, जिसकी उन्हें कोई मजबूरी नहीं थी।

मेरे पहले WordCamp तक पहुँचने में मिली मदद इसका एक उदाहरण है।

बाद में Katie at Barn2 ने company के events budget के ज़रिए मेरे कुछ WordCamp trips sponsor किए। Makarand ने मुझे Yoast Care Fund के लिए nominate किया, जिसे पाना मेरे लिए सौभाग्य की बात रही।

WP Open Community Collective ने भी मुझे Contributor Day Lead Sponsorship, जिसे GoDaddy ने sponsor किया था, के ज़रिए support किया।

और कुछ लोगों ने ऐसी मदद की जो financial बिल्कुल नहीं थी।

लोगों ने अपना समय दिया।

मेरे सवालों के जवाब दिए।

मेरी recommendations कीं।

जब मैं खुद को लेकर uncertain था, तब मुझे encourage किया गया।

Contribution numbers की बात करते समय इन चीज़ों को आसानी से नज़रअंदाज़ किया जा सकता है।

लेकिन मेरे लिए असली कहानी यही है।

क्योंकि हर contribution के पीछे अक्सर एक इंसान होता है।

और मेरी contributions के पीछे बहुत सारे ऐसे लोग हैं जिन्होंने मुझे वहाँ तक पहुँचने में मदद की।

WordPress ने मुझे क्या दिया

जब मैं उस लड़के को पीछे मुड़कर देखता हूँ जिसने अपने fellow engineering students के लिए technology tutorials लिखना शुरू किया था, तो मुझे नहीं लगता कि उसने कभी सोचा होगा कि उसकी journey यहाँ तक आएगी।

Technology में आने का मेरा कोई conventional रास्ता नहीं था।

मैंने computer science की पढ़ाई नहीं की।

मैंने WordPress की चीज़ें बनाकर, उन्हें तोड़कर और फिर उन्हें समझते हुए सीखा।

और किसी तरह, शुरुआत करने के लिए इतना ही काफी था।

WordPress ने मुझे technology, content, SEO, marketing, product building और community जैसी skills विकसित करने में मदद की।

इसने मुझे दुनिया भर के लोगों के साथ काम करने के मौके दिए।

मुझे उन WordCamps तक पहुँचाया, जिन्हें मैं कभी afford भी नहीं कर सकता था।

इसने मुझे open-source products बनाने का मौका दिया।

लेकिन इन सबमें से कोई भी चीज़ वह नहीं है जिसे मैं सबसे ज़्यादा महत्व देता हूँ।

WordPress ने मुझे सबसे बड़ी चीज़ जो दी, वह लोग थे।

शायद इसीलिए मेरे लिए “success” से ज़्यादा सही शब्द “belonging” है।

मैं WordPress पर websites बनाने आया था।

लेकिन कहीं न कहीं, WordPress ने मेरे आसपास एक community बना दी।

मैं अभी भी इसे समझने की कोशिश कर रहा हूँ

मुझे अभी भी ठीक से नहीं पता कि WordPress मुझे आगे कहाँ ले जाएगा।

मैं products बनाते रहना चाहता हूँ।

मैं marketing और product के क्षेत्र में और आगे बढ़ना चाहता हूँ।

मैं partnerships और community के बारे में और explore करना चाहता हूँ।

और एक दिन, मैं WordPress release को co-lead करना चाहता हूँ।

लेकिन मैं इन चीज़ों के पीछे सिर्फ किसी title या badge के लिए नहीं भागना चाहता।

मैं ऐसी चीज़ें बनाना चाहता हूँ जो सच में useful हों।

मैं अपने काम में बेहतर बनना चाहता हूँ।

मैं उन लोगों की मदद करना चाहता हूँ जो आज वहीं खड़े हैं जहाँ मैं कुछ साल पहले था।

और मैं ऐसा इंसान बनना चाहता हूँ कि जब कोई अपने WordPress journey के शुरुआती दिनों को याद करे, तो शायद वह कह सके:

“Satya ने मेरी शुरुआत में मेरी मदद की थी।”

मेरे लिए वह किसी भी badge से ज़्यादा मायने रखेगा।

क्योंकि मेरे साथ भी यही हुआ था।

लोगों ने मेरी शुरुआत में मेरी मदद की।

लोगों ने मेरे लिए जगह बनाई।

लोगों ने मुझे encourage किया।

लोगों ने मुझ पर भरोसा किया, उस समय भी जब मुझे खुद पूरी तरह यकीन नहीं था कि मैं contribute कर सकता हूँ।

इसलिए अगर आप अपनी WordPress journey अभी शुरू कर रहे हैं, तो मेरी सलाह बहुत simple है:

छोटे से शुरू कीजिए। सवाल पूछिए। जो पसंद है, उसे खोजिए। लगातार contribute कीजिए, लेकिन अपनी capacity के भीतर।

आपको शुरुआत करने से पहले सब कुछ पता होना ज़रूरी नहीं है।

मुझे भी नहीं पता था।

मैंने लिखना इसलिए शुरू किया क्योंकि मैं अपने classmates के लिए मुश्किल चीज़ों को आसान बनाना चाहता था।

मैंने blogging इसलिए शुरू की क्योंकि technology को लेकर मेरे अंदर curiosity थी।

मैंने WordPress इसलिए शुरू किया क्योंकि मेरे भाई ने मुझे दिखाया कि इसके साथ क्या किया जा सकता है।

मैं सीखता रहा क्योंकि हमेशा कुछ नया सीखने के लिए था।

और आखिरकार, मैंने contribute करना शुरू किया क्योंकि मैं कुछ वापस देना चाहता था।

लेकिन कहीं न कहीं, इस journey के दौरान कुछ और भी हुआ।

मुझे लोग मिले।

मुझे opportunities मिलीं।

मुझे एक community मिली।

और मुझे एक ऐसी जगह मिली जहाँ मैं सीखता रह सकता था, contribute करता रह सकता था और हर दिन थोड़ा बेहतर बनता रह सकता था।

मैं WordPress पर वेबसाइटें बनाने आया था।

लेकिन कहीं न कहीं, WordPress ने मेरे आसपास एक community बना दी।

और शायद यही इस पूरी journey का असली मतलब है।

Blogging से Belonging तक।

The post From Blogging to Belonging: My WordPress Journey – Blogging से Belonging तक: मेरी WordPress Journey appeared first on HeroPress.

This security release features a fix for a critical severity security vulnerability.

Because this is a security release, it is recommended that you update your sites immediately.

You can download WordPress 7.1.2 from WordPress.org, or visit your WordPress Dashboard, click “Updates”, and then click “Update Now”. If you have sites that support automatic background updates, the update process will begin automatically.

Security update included in this release

The security team would like to thank Robert Ressl for responsibly disclosing that an unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories. If relevant pre-conditions for both the server environment and the active theme are met, this can lead to remote code execution (RCE).

Thank you to these WordPress contributors

This release was led by John Blackbourn. WordPress 7.1.2 would not have been possible without the contributions of the following people:

Aaron Jorbin, Aki Hamano, Alex Concha, Ehtisham Siddiqui, fiocavallari, Jb Audras, Jeffrey Paul, Jeremy Felt, Joe McGill, John Blackbourn, Jon Surrell, Lance Willett, Manuel Camargo, marcs0h, martin.krcho, Mukesh Panchal, Olga Gleckler, Pascal Birchler, Peter Wilson, Rajin Sharwar, Ressl, Rudy Faile, Sergey Biryukov, Shail Mehta, Stephanie Walters, and vortfu.

CVE and GHSA references

Further details can be found in the advisory: CVE-2026-87902 / GHSA-7hp8-65ch-5whp.

Backports

As a courtesy, the security fix was backported to all branches eligible to receive security fixes (currently through 4.7). As a reminder, only the most recent version of WordPress is actively supported.

I makes genealogy faster and more accurate while Charleen Mullenweg explains the ongoing need for human review.

Invisible characters challenge spam filters, CrowdSec deals with a code leak, and AI is shifting what matters in software development.

bbPress 2.6.18 is a maintenance release focused on forum imports and first-login password upgrades.

Imported users can now upgrade their passwords on first login for more legacy forum formats, including cases where the original forum database is no longer available. This release also corrects PHPWind topic statuses, reply counts, and forum dates during import, and restores Super Moderator edit links on front-end bbPress user screens.

bbPress 2.6.18 requires PHP 7.2 or newer and WordPress 6.0 or newer. Sites running an older PHP version should update PHP before upgrading bbPress. Read the 2.6.18 upgrade notes for importer compatibility details.

These changes are also in the 2.7 development branch. The Plugin Directory’s development trunk remains at 2.7.0-alpha-3.

Download bbPress 2.6.18 from WordPress.org, or update from your WordPress dashboard.

I’m happy to announce that I am now serving as president of the Open Website Alliance (OWA), representing the WordPress Foundation. The Alliance brings together the community organizations behind Drupal, Joomla!, TYPO3, and WordPress to advocate for open source and share practices that benefit their projects. I represent the WordPress Foundation in this role, which rotates among the Alliance’s members.

WordPress announced its participation in the Alliance in 2024, building on our work with Drupal, Joomla!, and TYPO3 to respond to the European Union’s Cyber Resilience Act. While many open source projects focus on underlying digital infrastructure, our content management systems power the websites where businesses reach customers and sell products and services. We asked policymakers to account for that economic role when setting security requirements, while respecting how communities of developers, translators, educators, and other contributors build and maintain the software. We share a belief that everyone should have the freedom to use, change, and share the tools they rely on.

This commitment to openness builds on efforts such WordPress’s recent signing of the Open Weights and American AI Leadership letter. Our mission to democratize publishing means giving anyone a voice and welcoming everyone to contribute. Working with other communities puts those values into practice beyond WordPress, supporting the freedoms that make participation possible. I invite you to read the Open Website Alliance charter to learn more about the commitments its members share and how the Alliance works.

I started writing a post (this post!).

Then, as usually happens, I needed a picture, so I dragged one straight from my desktop into OpenStation. No downloading, no extra tabs needed, no extra spaces in the editor, no more “in which tab was the image!?”… I just dragged it from my desktop…

Done!

And then I thought the post was already descriptive enough to tell how much we enjoy creating content in OpenStation… But I missed the preview. I wanted to see what the post would look like and edit it in real time. And it happened, I just had to click on the eye icon in the title bar of this editor.

This is probably my favourite kind of productivity, the boring stuff becoming pleasantly simple…

And yes, this whole post was written while recording the video

But I thought that a quick sanity review from one of my bots would make the post nicer for SEO. So I just saved the draft, and gave it to my agent

And the best part, is that EVERYTHING that my Agent did, is traceable.

Switch to OpenStation

Bob Dunn talks about breaking out of AI echo chambers to gain new insights

I have been using WordPress for a long time, and I still love it. But wp-admin has basically worked in the same way for years.

OpenStation is our attempt to change that.

It’s a simple idea: instead of moving from one admin page to another, you have a desktop where you can open different parts of WordPress at the same time.

Your WordPress. Your workspace.

You can open your posts, pages, media, plugins, WooCommerce or any OpenStation app in different windows.

You can move them around, minimize them or put two things next to each other.

It may sound like a small difference, but once you start using WordPress this way, it changes a lot.

Real-time previews

You can also see your changes while you are working on them.

No need to constantly jump between wp-admin and the frontend just to check how something looks.

Apps inside WordPress

This is one of my favorite parts.

We are building apps like AllTerrain Forms, Photo Editor (And more!) specifically for OpenStation.

They are still WordPress plugins, but they feel much more like normal desktop apps.

WordPress on your phone

We also wanted OpenStation to work properly on mobile.

You can install it as a PWA and use WordPress from your phone almost like any other app.

Performance Is Fast. Really fast.

OpenStation is not only about changing how WordPress looks.

We have put a lot of work into making it fast. In many cases, opening and moving between WordPress screens is faster than using them directly from wp-admin.

We are also working on caching and preloading parts of WordPress before you need them.

The goal is very simple: you click something and it opens FAST.

And it is still WordPress

This is important.

We are not trying to replace WordPress or build another platform on top of it.

Your plugins are still your plugins. WooCommerce is still WooCommerce. Your content stays in WordPress.

OpenStation just gives you a different way to use all of it.

And, of course, it is open source.

Thank you

And finally, a big thank you to everyone in the WordPress community who has tried OpenStation, shared feedback, reported bugs or simply told others about it.

And especially to all the contributors who are helping us build it. OpenStation would not be what it is today without you.

There is still a lot we want to do, and seeing people contributing, experimenting and building things with OpenStation is probably the best part of the whole project.

Thank you

This week Robert Jacobi shared about the evolving landscape of open source and tech. Highlights include AI’s growing role in security, WordPress and Apache fortifying their processes, LibreOffice redefining productivity with privacy, LoopConf rethinking event funding, and Switzerland’s bold move toward digital sovereignty. Explore how accountability, control, and sustainability are shaping the future of open technology.

Is sharing everything always good? Bob Dunn reflects on transparency and the noise in online spaces.

This security and maintenance release features 17 bug fixes on Core, 19 bug fixes for the Block Editor, and 11 security fixes.

Because this is a security release, it is recommended that you update your sites immediately.

You can download WordPress 7.1.1 from WordPress.org, or visit your WordPress Dashboard, click “Updates”, and then click “Update Now”. If you have sites that support automatic background updates, the update process will begin automatically.

WordPress 7.1.1 is a short-cycle release. The next major release will be version 7.2 and is currently planned for December.

For more information, please visit the WordPress 7.1.1 HelpHub site.

Security updates included in this release

The security team would like to thank the following people for responsibly reporting vulnerabilities, and allowing them to be fixed in this release:

• Stored cross-site scripting in wpautop() allows an unauthenticated visitor to inject script (subject to comment approval), reported by Rafie Muhammad (Awesome Motive, Inc.).
• HTML API: set_modifiable_text() allows breaking out of a comment via abrupt-closing sequences, reported by Jeremy Felt of the WordPress Security Team.
• Stored XSS in some themes that support custom headers, reported by Jeremy Felt of the WordPress Security Team.
• Specially crafted URLs can automatically install and preview an inactive theme from WordPress.org, reported by Paulos Yibelo and pwn.ai.
• Site Administrator can network-activate an installed Network-only plugin, reported by Jesse McNeil.
• Authenticated Path Traversal in WP REST Templates Controller, reported by Anthropic.
• XML-RPC can be used to publish customize_changeset posts that bypass checks for edit_css, reported by Ben Bidner of the WordPress Security Team.
• Contributor+ Arbitrary Post Overwrite, reported by Anthropic.
• Missing read_post check in attachment_submitbox_metadata() leaks a private parent-post title, reported by HDWSec.
• Missing Authorization leads to Draft/Pending Post Slug Disclosure by Contributor+, reported by Jakub Herman.
• Comments, including notes, can be reparented by any authenticated user, reported by Justin Hart, Viridis Security.

Thank you to these WordPress contributors

This release was led by Adam Silverstein, Adrian Duffell, Andrei Draganescu, and Aaron Jorbin.

WordPress 7.1.1 would not have been possible without the contributions of the following people. Their asynchronous coordination to deliver maintenance and security fixes into a stable release is a testament to the power and capability of the WordPress community.

Aaron Jorbin, abrahamfariaz, Adam Silverstein, Adi Moldovan, Adrian Duffell, Aki Hamano, Alex Concha, Andrea Fercia, andreasca, Andrei Draganescu, Andrew Duthie, Andrew Serong, André Maneiro, annezazu, Anthony White, Arkaprabha Chowdhury, Ashar Fuadi, Azragh, Barry, buffer1024, Chunhui Ouyang, Courtney Robertson, Dagan, Daniel Richards, Daniel Rodriguez, Darshit Rajyaguru, David Biňovec, Deepak Kumar, Dennis Snell, DevSaiful, Dhruvang21, Dominik Schilling, Ehtisham Siddiqui, Ella Van Durpe, Erick Wambua, FahimMurshed, Fernando Tellado, fiocavallari, George Mamadashvili, George Vasiliades, gregbenz, Harish Tewari, Hit Bhalodia, Isabel Brison, Jake Spurlock, Jamie Dąbrowiecki, Jb Audras, Jeffrey Paul, Jeremy Felt, Jiwoon Kim, Joe Dolson, Joe Hoyle, Joe McGill, Joen Asmussen, Johannes Jülg, John Blackbourn, Jon Surrell, Jonathan Desrosiers, Josh, Kamran Abdul Aziz, Khokan Sardar, Kira Schroder, kleisauke, Kushagra Goyal, l1onofjudah, Lance Willett, luksusspokoju, Manzoor Wani, Marco Ciampini, marcs0h, Marin Atanasov, Michael, Mohammad Jangda, mrkenobi, Mukesh Panchal, Nawazkhan Pathan, Nik Tsekouras, Parth Jogi, Pascal Birchler, Paul Biron, Paul Kevan, Peter Wilson, Rafie Muhammad, ramonopoly, Rashed Hossain, Ressl, Riad Benguella, Rudy Faile, Sainath Poojary, Scott Kingsley Clark, Sergey Biryukov, Shail Mehta, Shameem – a11n, siliconforks, Slava Abakumov, Stephen Bernhardt, Sukhendu Sekhar Guria, Ugyen Dorji, Utsav Ladani, vortfu, Weston Ruter, w3bdsgn, wolf45 plus representatives from Automattic, Bluehost, GoDaddy, Pantheon, and WP Engine.

Backports

As a courtesy, the security fixes are being backported, where necessary, to all branches eligible to receive security fixes (currently through 4.7). As a reminder, only the most recent version of WordPress is actively supported. The backports are in progress and will ship as they become ready.

How to contribute

To get involved in WordPress core development, head over to Trac, pick a ticket, and join the conversation in the #core channel. Need help? Check out the Core Contributor Handbook.

Props to Ehtisham Siddiqui, Lance Willett, Weston Ruter, and Adam Silverstein for proofreading.

Shifting budgets and tech priorities drive change for open source events software and government infrastructure.

OmFest is coming together quite nicely! The new website is beautiful and highlights some of the experiences available throughout the day. I think Om would be very impressed by the attendee list. We’re doing it at the Swedish American Hall, the same venue as the first WordCamp, where Om, of course, spoke about Blogs and Journalism. (The videos have been lost to digirot, unless anyone has some recordings? I’ve been looking everywhere.)

Below is cross-posted from OmFest.co:

September 29^th is when Om would have turned 60. 

When I first started thinking about how to mark the day, I knew I didn’t want a traditional memorial. Om loved bringing interesting people together, and he loved a festival that taught him something he didn’t already know. His curiosity crossed so many worlds and passions: technology, journalism, photography, investing, watches, pens, coffee, design, music, India, New York, San Francisco. 

So we’re bringing these worlds together. On September 29 in San Francisco, we’re throwing OmFest—twelve hours of ideas, objects, food, music, and conversation, organized and anchored around a statement Om once said:

“If you pay enough attention to the present, you can see the future.”

Present Future

Instead of tributes or keynotes, we’ll host a series of short talks with one simple challenge: teach us something you’re seeing before everyone else sees it. No pitches, no career retrospectives. You don’t even have to talk about Om. What happens to photography when anyone can generate the perfect image with AI? Why do physical objects become more meaningful as our lives become more digital? Are glasses becoming computers? What does handwriting do to the way we think? Different subjects, same goal: everyone leaves knowing something they didn’t know when they arrived.

A Festival of Om’s Curiosity 

Between the talks, there will be plenty to stumble upon. Through Om’s Lens: a gallery of Om’s photography. TIME: an exhibit that uses his watch obsession to spark a discussion about craft and collecting. Field Notes: a communal writing table stocked with fine paper, fountain pens, and ink, where you can write something worth remembering—and either keep it or leave it behind to be bound in a book to commemorate the day. And Om’s Shelf: books he read, loved, and recommended. The collection will start full and slowly empty as his favorite reads pass into other hands.

People from Om’s different worlds will drop in throughout the day to share knowledge and facilitate small, hands-on moments: a photography tutorial, a notebook-binding session, a lesson on the mechanics of a watch, an experience with a coffee you’ve never tried, a tea ceremony. And, woven into this experience, will be OM/60: sixty small discoveries about Om, hidden throughout. 

All Roads Lead to Om

The most important part, however, isn’t any of these objects. At check-in, instead of a badge with your company and title, you’ll choose the worlds through which you knew Om: photography, journalism, technology, GigaOm, investing, WordPress, India, coffee, pens and ink, design, music, or simply friends and family.

Then we build a physical map of it. It starts nearly empty. You add yourself, mark how you knew Om and whom he introduced you to, and those people connect to others. By the end of the night, I hope we’ll be able to see what Om spent a lifetime making. 

The question I keep asking myself: who will meet because of Om that Om never had the chance to introduce? If OmFest works, his network won’t just be documented that day. It’ll grow. 

From Ideas to Celebration

The day flows and builds. Morning is coffee, breakfast, books, photography, and conversation. The middle is deliberately unstructured—wander, eat, write, talk. In the evening, friends share short stories as we raise a glass to Om on his 60th. Then the bars roll in, the lights go down, the music gets louder, and OmFest becomes DesiParty: his old-school New York nights, Asian Underground, bhangra, electronica. We start with ideas and end with dancing. That feels right.

Version 1.0

What we’re building shouldn’t end on September 29. What does registration look like if it’s designed to help strangers talk to each other? How do you design a conference around curiosity instead of status? How do you make something that works for a two-hour visit or a twelve-hour one? How does a room encourage connection without forcing networking? 

We’re treating OmFest as an experiment. We’ll document what works—formats, designs, code, templates, check-in, programming—and open source as much of it as we can. Other events can take the best ideas and make them better.  

September 29 isn’t the end of OmFest. It’s version 1.0.

Come Build with Us

People from across Om’s life are building OmFest together. Some are contributing photographs. Someone is making a textile; another is bringing tea and guiding ceremonies. Others are helping with watches, eyewear, books, music, writing, and stories. We haven’t discovered whole parts of Om’s world yet. That’s the point.

If Om introduced you to something, or someone, we’d love to know. If there’s something you think people should experience, see, hear, taste, read, or learn that day, tell us. 

And if you just want to come, come. You don’t need to have known Om. You only need to be curious.

It’s official in SF Standard: Stewart Brand sells his seaworthy Sausalito houseboat to tech CEO. Ahoy!

WordPress, Apache, and Zephyr adapt to AI-driven security and infrastructure demands shaping the future of open source at scale.

Founder-led sales focus on authentic outreach and relationship building, prioritizing genuine engagement in communities over cold pitches, fostering trust, and recognizing that not every prospect is a good fit.