Category: WordPress Project

Six days out from its final release, WordPress 7.0 RC4 has shipped alongside the major release’s Field Guide — the last major milestones before Wednesday’s launch.

Release coordinator Amy Kamala announced the fourth release candidate on WordPress.org News on Thursday. RC4 follows last week’s RC3, which shipped with real-time collaboration completely removed from core after months of technical problems with the feature.

The release also marks the hard string freeze, locking all translatable strings so the Polyglots team can finalize translations before launch.

The Field Guide, published on the Make WordPress Core blog, outlines major developer features and breaking changes, and links out to individual developer notes. Even without RTC, its former headline feature, 7.0 is substantial. It comprises more than 419 Core Trac tickets, including over 76 enhancements and more than 300 bug fixes, plus 411 Gutenberg enhancements and more than 486 bug fixes across the editor, dashboard, and AI integration.

The new AI infrastructure coming to 7.0 is now headlining the release. WordPress 7.0 will ship with the WP AI Client — a provider-agnostic API that lets plugins call generative AI models through a consistent interface — alongside a Client-Side Abilities API that extends the Abilities API introduced in 6.9 to the browser. The AI Connectors screen, which WordPress co-founder Matt Mullenweg pushed for during the beta cycle, will give users a single place in the dashboard to manage connections to AI service providers. A Connectors API will allow plugins to register additional providers.

The modernized dashboard includes a refreshed admin color scheme, view transitions across wp-admin, a ⌘K/Ctrl+K Command Palette shortcut, visual revisions inline in the editor, and an iframed post editor. Notes, which first shipped in WordPress 6.9, has been updated with several improvements, including a new keyboard shortcut, dashboard widget, and notifications to help users stay on top of team communications.

On the design side, there are new Headings and Breadcrumbs blocks along with block-level custom CSS and Navigation Block improvements, while a developer’s toolbox section in the Field Guide covers PHP-only block registration, Interactivity API updates, DataViews and DataForms, and Block Bindings API iterations.

The release also raises WordPress’s minimum supported PHP version to 7.4, a change that had been in the works since late last year.

Gutenberg Times editor Birgit Pauli-Haack has been maintaining a WordPress 7.0 Source of Truth since March, offering a collaboratively written companion to the Field Guide tracking changes for developers, theme builders, and site admins.

WordPress 7.0 was originally scheduled for April 9 during Contributor Day at WordCamp Asia 2026 in Mumbai. That date was pushed back over unresolved issues with real-time collaboration, which was ultimately pulled from the release on May 8 and will be re-evaluated for 7.1.

The final release is scheduled for Tuesday. It will be six weeks late, but with a feature set that puts the focus squarely on where WordPress is heading with AI.

The WordPress AI Team has released version 0.9.0 of the AI plugin, adding two new experiments for comment moderation and content resizing, a WP-CLI command for bulk alt text generation, and a new Developer Mode that gives developers per-feature control over AI providers and models.

The release was announced on the Make WordPress AI blog on Monday by Fueled-sponsored contributor Jeffrey Paul, who leads development of the canonical plugin. It’s the ninth release since the plugin first launched in November 2024 as the AI Experiments plugin, and the second since the project was renamed WordPress AI earlier this year as the team began elevating experiments to stable features.

The headline addition in 0.9.0 is a Comment Moderation experiment that uses AI-powered sentiment analysis and toxicity detection to flag potentially problematic comments before they’re published. The feature is designed to help site owners reduce spam, harassment, and low-quality engagement, with flagged comments sent to the moderation queue for human review.

A Content Resizing experiment lets users shorten, expand, or rephrase selected content. Paul said it continued the plugin’s focus on bringing lightweight editorial AI workflows directly into WordPress.

On the developer side, a new Developer Mode toggle on the AI settings page allows per-feature configuration of AI providers and models. Developers can now compare model behavior across features, test different providers during development, and optimize for cost, speed, or output quality.

The release also introduces a wp ai alt-text generate WP-CLI command for bulk alt text generation across media libraries, aimed at accessibility improvements, migration workflows, and editorial automation. Other changes include improvements to the settings page UI, descriptive filenames for AI-generated images, and updates to how image generation guidelines are applied.

Version 0.9.0 comes as the plugin closes in on its 1.0 milestone. The plugin’s original roadmap targeted a 1.0 release to coincide with WordPress 7.0, but the timeline has stretched following the major release’s delays.

Work is already underway on 1.0, which Paul said would include onboarding flows for a “Try AI” callout in WordPress 7.0, new experiments for type-ahead suggestions and AI request logging, integration with Gutenberg’s experimental Media Editor, and content provenance tracking via C2PA.

This latest release of the AI plugin is the fourth in roughly two months, following 0.8.0 in late April and a pair of rapid-fire releases in March that pivoted the plugin’s infrastructure to align with WordPress 7.0’s built-in AI capabilities.

The third release candidate for WordPress 7.0 has shipped with real-time collaboration completely removed from core following Matt Mullenweg’s decision to pull the feature on Thursday.

Release coordinator Amy Kamala announced RC3 on the WordPress.org News blog on May 8, marking the end of RTC’s troubled run in the 7.0 cycle.

After making the call to pull the feature, Mullenweg had posted in the #feature-realtime-collaboration channel in WordPress Slack that he’d be fine with simply deactivating RTC in a way that “nerfs it in a safe way.” But the release team went further. Rather than leaving the code in place and switching it off, they settled on a full code deletion that stripped all RTC infrastructure out of core.

RTC code still exists inside Gutenberg’s packages, but nothing in core turns it on anymore. The wp.sync JavaScript global has been hidden by bundling so it’s no longer exposed to themes or plugins. A separate pull request to disable remaining RTC public APIs in core builds was still open on the Gutenberg repository as of publication.

Under the revised schedule published in April, RC3 was supposed to function as a new beta in practice, with RC4 serving as a true release candidate. However, the RC3 announcement walks that back. According to Kamala, RC3 is no longer considered a new Beta 1, after the release team decided the RTC removal didn’t warrant resetting the 7.0 cycle.

WordPress 7.0 remains on track for May 20.

The RC3 announcement says RTC will be “re-evaluated during the 7.1 release cycle” — notably not a commitment to ship the feature in 7.1, just to revisit it. That’s softer language than what Automattic-sponsored contributor Anne McCarthy used in her announcement, Real-time collaboration will not ship in WordPress 7.0, a day earlier, where she framed the feature’s return as more of a given pending further testing.

Writing in the comments on that post, McCarthy said RTC could still be tested via the Gutenberg plugin. However, The Repository was unable to find an activation toggle in the Gutenberg Experiments screen on a local test site running the latest version of the plugin. Gutenberg 23.1 shipped on May 7 with four RTC fixes — just hours before Mullenweg pulled the feature from 7.0.

Also in the comments, Plugins Team contributor Luke Carbis asked whether RTC was available as a feature plugin or via the Gutenberg plugin. McCarthy said testing was available via the Gutenberg plugin, and it was an “open question” whether RTC might be spun out into its own feature plugin. “That will need to be discussed when the dust settles as part of getting broader feedback going forward,” she said.

RC3 arrives after a 43-day gap since RC2’s release on March 26, during which more than 143 Trac tickets were closed. 

For developers, the full removal means a clean break. Anyone who had started building against RTC’s REST endpoints or JavaScript interfaces during the beta cycle will find them gone in 7.0 and will need to remove that code.

Gutenberg 23.1 has introduced a user interface for creating custom post types in WordPress, a move that has generated excitement and skepticism in roughly equal measure.

The experimental feature, which allows users to create and manage custom post types directly in the admin via Settings, went from a GitHub issue to a merged pull request in less than two weeks. Automattic engineer Nik Tsekouras opened the tracking issue on April 22, and colleague Marin Atanasov submitted the pull request on April 30. It was merged the same day.

Custom post types have been a foundational part of WordPress since version 3.0 introduced them in 2010, allowing developers to extend the CMS beyond standard posts and pages. But creating them has always required either a plugin or code. That gap spawned two well-known products. WebDevStudios’ Custom Post Type UI plugin has over 1 million active installations, and WP Engine’s Advanced Custom Fields added custom post type and taxonomy registration tools in ACF 6.1, building on an already massive user base of more than 2 million sites.

Now, for the first time, WordPress is building a UI for this directly into the editor.

Jamie Marsland, Head of WordPress.org YouTube at Automattic, drew attention to the feature in an X post on Monday that picked up significant traction, with 210 likes, 73 reposts, and dozens of comments.

“Custom post types go from ‘developer feature’ → ‘everyday user feature,’” Marsland wrote. “WordPress is becoming a powerful content modelling system.”

This was just merged into Gutenberg trunk, and it’s a much bigger deal than it looks 👇

WordPress is getting a native UI to create custom post types.

No code. No plugins.
Just:
Settings → Post Types → Add

That might sound small… it’s not.

Custom post types go from… pic.twitter.com/uZBMwsU0fI

— Jamie Marsland – Head of WordPress YouTube ❤️ (@pootlepress) May 5, 2026

But the pace of the work, and whether it belongs in core, has raised questions. Bluehost-sponsored core committer Jonathan Desrosiers commented on the GitHub issue, asking, “Why is this being tackled? I don’t see any compelling discussions or reasoning as to why this is a problem that WordPress Core should tackle. How does this fit into the roadmap and the 4 phases?”

WebDevStudios CEO Brad Williams had a similar question. “Was there a discussion around this in Slack somewhere? Curious the reasoning behind this as it still feels like plugin territory to me,” he wrote on X.

Aye! Code co-founder Paolo Tajani argued it should have started as an official plugin first, flagging the risk of naming conflicts and duplicate post types when plugins register the same content types differently. Marketer and developer Matt Beck raised concerns that the new feature stores its definitions in the database rather than in version-controlled files, a workflow that plugins like ACF solved by writing JSON definitions that developers could commit to a repository.

“Unless I’m missing something here, these definitions live inside the db which means… not under version control, and you’re putting data modelling data into the database itself, which is silly,” Beck wrote on X.

According to the pull request, the feature works by registering a private wp_user_post_type custom post type that stores one record per user-defined post type, with its slug, status, and a JSON-encoded configuration stored in standard post fields. A REST API filter rejects slug collisions with existing post types.

The tracking issue acknowledges the feature’s boundaries, noting that “complex use cases will remain in the plugin territory.”

Others welcomed the addition but questioned the timing. Developer Keith Mason wrote on X, “As great as this is — it’s about 15 years too late.” Latif Pala, also a developer, argued the feature should have shipped alongside Gutenberg itself in WordPress 5.0 back in 2018. WPSoul CEO Igor Sanz quipped, “2035 — WP is getting native UI to add custom meta.”

Yoast founder Joost de Valk, meanwhile, looked ahead — and toward the larger prize. “So… how long before we get this for custom fields too?” he wrote on X in reply to Marsland’s post.

The Gutenberg 23.1 release announcement on Make WordPress Core buries the feature. It leads with faster image upload finalization and new UI primitives, listing the content types experiment among “Other Notable Highlights.” The feature is flagged as an experiment, and users need to enable it in the Gutenberg plugin’s “Experiments” settings.

The timing is hard to separate from the broader competitive and political landscape.

Cloudflare’s EmDash CMS, which launched in April and positioned itself as a “spiritual successor to WordPress,” drew attention to the fact that its content modeling capabilities — including custom content types — were built in from day one. During an interview on WP Product Talk, Senior Product Manager Matt Taylor pushed back on the idea that capabilities like custom content types should be plugins at all, calling it “odd” that they weren’t already part of WordPress core.

In October 2024, WordPress.org took over WP Engine’s free ACF plugin and separately forked ACF Pro a month later, releasing it as Secure Custom Fields with all premium features available for free. A preliminary injunction in December 2024 ordered the return of the free ACF plugin to WP Engine, but the ACF Pro fork remains in the WordPress.org plugin repository under the secure-custom-fields slug with over 70,000 active installations.

WordPress co-founder Matt Mullenweg has pulled real-time collaboration from WordPress 7.0, ending months of technical turbulence around the major release’s headline feature, and citing both persistent engineering problems and the toll of Automattic’s ongoing legal fight with WP Engine.

Mullenweg broke the news on Thursday evening UTC in the #feature-realtime-collaboration channel on WordPress Slack, telling contributors he was “not confident with RTC being in core at this point.”

“I’m fine taking the heat for pulling it out, but the surface area, race conditions, server load, memory efficiency, and the bugs that keep popping up in fuzz tests / etc don’t give me a lot of confidence on our current approach being the robust one we want to support,” he wrote.

He also pointed to the WP Engine litigation as a factor, saying the “lawfare and depositions” had been “a time DoS for critical people.”

“Perhaps without that in the background we could have gotten to a better place by now, but I don’t think with the current deposition schedule and all the faff around discovery we’re able to support this feature,” he wrote.

Automattic-sponsored contributor Anne McCarthy announced the decision on the Make WordPress Core blog shortly after, calling it “a difficult decision” made “in service of shipping a stable and reliable WordPress 7.0 release.” 

McCarthy also published the results of recent hosting performance tests that had been conducted with eight hosting environments across four storage approaches: post meta, a dedicated custom table, post meta with transients for client awareness, and a hybrid approach using a custom table with object cache-backed awareness. 

The hybrid option had emerged as the recommended path forward, performing roughly 52% faster than the post meta baseline and finishing first or tied-first on six of seven test environments. That work will now carry over into future development.

Core committer Aaron Jorbin has opened a Trac ticket to track the removal work, and Automattic developer Max Schmeling has submitted a pull request to disable the feature by forcing the wp_is_collaboration_enabled() function to always return false and removing the collaboration toggle from the Writing Settings screen in the WordPress dashboard.

In #feature-realtime-collaboration, release coordinator Amy Kamala flagged the tight timeline, noting that the next 7.0 beta release was due out today and the technical unwind seemed like a lot to accomplish in 24 hours. Mullenweg acknowledged the scope, saying the work might mean a release date change. WordPress 7.0 is currently scheduled for release on May 20.

Fueled-sponsored core committer Peter Wilson, who originally reported the cache invalidation issues affecting RTC’s performance, posted that he had been “on the fence for the last week” and backed Mullenweg’s decision. WP Engine-sponsored core contributor Joe Fusco, who worked with Wilson on an early database schema, was more upbeat, writing, “Excited for 7.1! Lots of great work this push and the database approach is in good shape going in.”

McCarthy said real-time collaboration remained “an important and exciting feature for WordPress” and that once the immediate release work was complete, a plan would be shared for broader testing and continued iteration ahead of a future release.

A troubled feature from the start

Real-time collaboration, the centrepiece of Phase 3 of the Gutenberg roadmap, has been dogged by performance and infrastructure challenges since it was first flagged for possible inclusion in WordPress 7.0 in November 2025. The feature, which enables Google Docs-style simultaneous editing in the WordPress post editor, relies on HTTP polling to allow for widescale availability — a constraint that has been at the heart of the performance problems.

Early testing by hosting providers revealed the feature added too many requests per user, polled too frequently, and created significant object caching issues when built on the post meta table. WordPress 7.0 RC1 was delayed by five days in March following the decision to scrap the database approach. Even after changes were made, concerns persisted, and when RC1 finally shipped, core committers still had reservations about the release’s readiness.

Mullenweg then called for a further delay at the end of March, scrapping the planned April 9 release at WordCamp Asia so that contributors could pursue the database table after all. That decision left the release team in limbo over the Easter long weekend, unsure of how to proceed. A new release date of May 20 was eventually set in late April, and hosts were called on to help test the four storage approaches.

Wilson had been leading the final push on the database side, developing a hybrid approach that paired a custom table with object cache-backed awareness data. His pull request was on track for commit today ahead of the planned beta release.

Hosts relieved, community broadly welcomes decision

An employee at a large hosting company, who asked not to be named, described months of scrambling to assess RTC’s impact on their platform.

“The fire began when we actually loaded up an early WordPress 7.0 version with RTC on it,” they said. “We saw quickly that the way it was approached at the time would have greatly impacted our hosting platform and customer load times in the admin area.”

The source said hosts had watched the feature’s storage approach bounce between post meta, meta API workarounds, and a proposed custom table — a process that left their database team worried. “It bounced around in limbo,” they said. The decision to disable RTC by default had been a turning point, they said, after hosts had been prepared to force-disable the feature across their platforms entirely.

“RTC is a cool feature but it’s quite a gift to get this reprieve from worrying about its impacts on hosting and all of this rushing,” the source said. “It was the wrong approach and it needed so much more time to bake, be tested, and get hosts involved in confirming what the impacts would be.”

Chris Reynolds, a developer advocate at Pantheon who spoke to The Repository in a personal capacity and not on behalf of his employer, said the host had done initial testing to make sure RTC worked out of the box but hadn’t conducted extensive stress testing.

“My biggest concern, personally, was how could you possibly test how this performs at scale, with 20+ simultaneous users editing the same post,” he said.

Reynolds questioned whether WordPress needed to solve real-time collaboration in core at all, pointing to Pantheon’s Content Publisher product. “Do you bend over backwards to get WordPress to support real-time collaboration really well? Or do you use the tools that have been iterating on that concept for a decade plus — e.g. Google Docs — and not have to train content editors on how to do that inside WordPress?” he said.

“I’m not fundamentally against the feature, but it did feel like it wasn’t quite ready yet.”

The community response on social media has been overwhelmingly supportive of the decision, while also questioning whether RTC should be in core.

Hendrik Luehrsen, CEO of Luehrsen-Heinrich, called Mullenweg’s decision a “good call” and said it was “good to see brave decisions being made in the project at the moment. Inspires hope.” LearnDash founder Justin Ferriman said putting RTC into core had always come across as “a bit tone deaf” and also praised the decision to pull it from 7.0.

Developer Andrew Hoyer called real-time collaboration “one of my least wanted features,” adding, “I think this should be a plugin that extends the core functionality for those who want it.”

Multiple developers echoed the call for RTC to be released as a canonical plugin rather than bundled into core, including Virfice founder Rayhan Arif who posted, “Most general WordPress users are unlikely to use the feature regularly. It could instead live as a separate plugin under the WordPress org profile for those who truly need it.”

GoDaddy’s Nik McLaughlin posted on X that he was “honestly relieved.” Yoast founder Joost de Valk also said it was the right call, “just five weeks too late,” referring to the decision in late March to delay the 7.0 release date.

Disclosure: WP Engine and Automattic-owned Pressable are sponsors of The Repository.

The WordPress Accessibility Team has published a comprehensive rewrite of its accessibility-ready theme guidelines, giving authors using the tag until June 30 to meet the requirements or face suspension from the WordPress.org directory.

The announcement, published on May 6 by core committer Joe Dolson, caps a two-year effort to modernize guidelines that hadn’t been updated since they were first introduced in 2012. Both Dolson and long-time accessibility contributor Amber Hinds, CEO of Equalize Digital, said the requirements had fallen behind. 

There are currently 108 themes in the WordPress.org theme directory tagged as accessibility-ready, all of which will need to be retested.

Hinds said she had frequently heard frustrations from clients and at the WordPress Accessibility Meetup that people didn’t trust the accessibility-ready tag, because there was no transparency about when a theme had been tested, by whom, or against which standards. The original requirements predated WCAG 2.1, WCAG 2.2, and the widespread adoption of HTML5 and ARIA.

“We put many, many hours into trying to make sure that these new guidelines were clear, testable, and well documented for theme authors,” Dolson said.

The rewrite started at the WordCamp Europe 2024 Contributor Day, where contributor Rian Rietveld began reviewing all the existing documentation and identifying what needed to change. Hinds led the work through Contributor Days at WordCamp Canada 2024 and WordCamp Europe 2025, with each round drawing in new testers whose feedback helped expose gaps in the instructions.

Progress stalled at times. Hinds said efforts to get changes made on the WordPress.org directory to surface testing information and accessibility statements went nowhere, and the project sat for months before she picked it back up in early 2025. She and Dolson completely rewrote all the requirements and testing instructions, and a final sprint in late 2025 and January 2026 brought the guidelines over the line.

The changes are significant. Recommendations have been removed entirely. The guidelines now contain only hard requirements, each in a standard format with testing instructions and links to relevant WCAG documentation. 

New requirements include support for reflow, resize, and text spacing changes; rules against unexpected changes of context; accessible hover and focus content; an accessibility statement; and a prohibition on recommending inaccessible plugins. A standardized Google Sheet template guides the testing process, and the team’s documentation has moved to a version-controlled GitHub repository.

“I think one of the biggest hopes is that it might bring more people to the team as contributors because there is an easier process people can follow to contribute,” Hinds said.

Because the accessibility-ready tag is applied through a theme’s source code rather than controlled by the Accessibility Team, authors who don’t respond will have their themes suspended. Dolson said the team would not act against authors actively in dialogue about updating their work, but was matter-of-fact about unresponsive ones.

“Anybody who has not responded at all…yes. That’s what’s going to happen,” he said.

He added that the team had dealt with authors who passed reviews only to revert accessibility fixes in subsequent updates, and that the new process aimed to establish real consequences for that kind of abuse.

Hinds is hosting a webinar on May 21, Global Accessibility Awareness Day, to walk participants through the testing process. The team’s aim is to get all 108 themes retested that day.

The documentation is maintained at wpaccessibility.org, and theme authors can request a review via Dolson’s announcement on the Make WordPress Accessibility blog.

Changes have been rolling out across WordPress.org after Matt Mullenweg recently created a new channel on WordPress Slack, giving a small group of trusted contributors the authority to overhaul the site without approval from any team, committee, or stakeholder other than himself.

The #meta-janitors channel went live on April 18, just days after Mullenweg spent hours in #core-committers saying “the wheels have fallen off” the WordPress project and blaming process creep for a culture that produced what he called “boring or mediocre crap.” Two days later, he turned his attention to Five for the Future, calling the program’s data “worse than useless.” The #meta-janitors channel is where those critiques have turned into action, with a handpicked team entrusted with production access and a mandate to ship fast.

“Spinning up an initial group of people I’m very comfortable with having dotorg sandboxes and making changes without approval or feedback needed from any team, group, stakeholder, commenter, or approval from anyone but me,” Mullenweg wrote in his opening message to the channel.

“Since we get so much flak for this being one guy’s personal website, let’s at least lean into it and have fun.”

The “personal website” remark is a callback to an interview Mullenweg gave The Verge last year in which he said “WordPress.org just belongs to me personally.” 

Mullenweg told the group in #meta-janitors that they could “override anyone in WordPress.org, including each other, except for me” in their area of responsibility, and said he wanted to see WordPress.org become “the best community hub the world has ever seen.” 

“Technically, all liability for anything we do falls to me, so I’m saying go for it, go crazy, let’s just make this experience better,” he wrote.

“Let’s give people the largest repository of free, GPL, secure code that the world has ever seen, and fix all the things that cause us to not collaborate, try to lean into more of the culture of GNU / Linux command line and have hard things done well in a simple and secure way, free to everybody.”

“All I ask is that folks who have been given the Golden Sword and Cloak of Invincibility from me blogvomit their updates in this channel so we can stay in the loop.”

He admitted he wasn’t proud of WordPress.org but wanted to be, and said his goal was “something like posthog.com” and “not drupal.com or launch.joomla.org.”

The initial group of 12 included WordPress Executive Director Mary Hubbard, Automattic Architecture Wrangler Anne McCarthy, WP Engine-sponsored core committer Weston Ruter, Human Made CGO Noel Tock, ServMask CEO Yani Iliev, Automattic Head of Global Expansion James Grierson, and featured plugins curator Nick Hamze. The group also includes WordPress lead developers Dion Hulse, Mark Jaquith and Andrew Nacin, and Automattic Systems Wranglers Barry Abrahamson and Eugene Barnard.

The channel has since expanded to 32 members as others have joined after being tagged in conversations, pulled into specific projects, or found the public channel on their own.

Overhauling Five for the Future

Iliev has taken on the group’s most ambitious project: overhauling Five for the Future, the program whose data Mullenweg called “worse than useless” just days before launching the channel.

On April 18, Iliev outlined four problems he wanted to solve: identifying which contributors are worth sponsoring, giving sponsors confidence their money is producing results, smoothing the path for first-time contributors, and building a reward system modeled on Stack Overflow’s reputation scores.

On April 24, Mullenweg greenlit four mockups Iliev shared that would dramatically change how Five for the Future data is shared and displayed:

• A new “Team Directory” page to replace individual Make Team pledge pages will not only show how many people are contributing to each Make team, but also rank contributors by their weighted contributions. The page will also display independent vs. sponsored contributors, the team’s opt-in rate, and the number of contributions over the past 30, 90, and 180 days.
• A new design for individual profiles will display contributions by weight, sponsorship status, specializations, and list the user’s recent contributions. Make Team badges will remain but will not be displayed as prominently as they are currently.
• A new design for company Five for the Future pages will display a dashboard-style design that surfaces a company’s impact (“Is my check being well spent?” as Iliev put it) as opposed to simply displaying who a company is sponsoring.
• A new “Find a Contributor” page will surface contributors who are seeking sponsors, giving companies a page where they can quickly view the details of active contributors and how their work is positively impacting the project.

Iliev said the mockups were the result of 27 iterations of adversarial review between Claude, Gemini, and Codex, and while they had the look and feel of posthog.com, the final designs would match WordPress.org’s existing branding.

He said the goal was to ship a foundation that every team could then contribute to and extend, with the first version of pages using existing data and later revisions incorporating feedback from teams, contributors, and sponsors.

“I am solving this from my end, being a company that is looking for contributors to sponsor, however, it also needs fresh eyes from each team — they need to vet the data that is being used and 👍🏼👎🏼 if the data is properly used to show high value/low value contributions,” Iliev wrote. 

Iliev has been waiting for SVN access, but said his goal was to launch all four pages at the same time later this week.

Other changes the group is working on

In the almost three weeks since the channel was created, the group has shipped a raft of other changes across several areas of WordPress.org.

Hubbard has updated the WordPress.org ‘Requirements’ page to display a clearer CTA to download WordPress, along with clearer requirements.

McCarthy led a team effort to ship a new WP-CLI landing page, which is now live at wordpress.org/cli. The previous wp-cli.org website now redirects to the new WordPress.org landing page.

McCarthy has also led an effort to improve WordPress.org’s jobs infrastructure. Users can now update their profiles to display their current job, past work history, and key accomplishments, and also toggle whether they are open to job opportunities and display an “open to work” frame on their avatar, similar to LinkedIn. She is also exploring resume import functionality and redesigning the jobs.wordpress.net website.

Hamze is exploring several design-related projects, including the creation of a free digital swag shop, with wallpapers, profile pics, and “the kind of little community goodies people actually want to use.” He’s also updating the default demo content for theme previews in the WordPress.org theme repository, including retiring the boat. He posted a Playground demo in the #themes channel with the new default content he wants to push live.

Another idea he shared to redesign the Submit a Plugin page to show “the new generation of vibe coders that we understand and support them” received pushback from Ruter, plugin reviewer Luke Carbis, and Audrey HC-employed meta contributor Samuel “Otto” Wood. Hamze argued that lowering barriers for AI-assisted submissions would free reviewers for higher-value work, but Ruter countered that an easier path could trigger an influx of low-quality plugins that overwhelmed the review team.

Operating in the open, sort of

The channel is public on WordPress Slack and non-members have joined and posted, but the initiative hasn’t been formally announced to the broader community. Bluehost-sponsored core committer Jonathan Desrosiers asked whether an announcement was planned but didn’t get a response. He has since published a page in the Meta Handbook about the Meta Janitors initiative.

On an episode of Crossword last week, Carbis described the initial burst of activity in the channel and said activity appeared to slow down after people outside the initial group started joining the channel.

Whether that’s actually the case is unclear, though the past two weeks have coincided with travel for some members of the group, and others, like OG lead developers Jaquith and Nacin, are rarely seen on WordPress Slack. Some projects, including Iliev’s work on Five for the Future, have simply been held up due to SVN access as folks other than Hulse seek to commit changes to WordPress.org.

The channel’s unconventional way of working doesn’t fit with how contribution to WordPress.org has traditionally worked, with no team consensus or formal announcements. But the completed projects, and those underway like Five for the Future, have been stagnant for years. Whether this approach breaks the logjam or creates new friction will become clearer in the weeks ahead.

Disclosure: Automattic-owned Pressable is a sponsor of The Repository.

A small team of contributors has put out a call for help building a new onboarding initiative for the WordPress project, asking Make teams to review guides, clean up beginner-friendly issues, and connect repositories ahead of an official launch at WordCamp Europe in Kraków in June.

Contributor Pathways pairs two resources aimed at newcomers: a set of Pathway Guides in the Contributor Handbook on WordPress.org that walk people through common contribution types, and a Good First Issues board on GitHub that automatically collects beginner-friendly tasks from repositories across the project.

The project is being led by Velda Christensen from Automattic, alongside colleagues Cheyne Klein, Maruti Mohanty, and Kel Santiago-Pilarski, all full-time sponsored contributors.

In a post on the Make WordPress Project blog, Christensen framed the work as responding to a familiar pattern anyone involved in contributor onboarding would recognize.

“Any new contributor hits the same walls: onboarding info is scattered, pathways aren’t clear, messages go unanswered in Slack, and good work sometimes stalls in review,” she wrote. “Teams want help, but we’re losing people at the door.”

WordPress Executive Director Mary Hubbard, who made lowering barriers to participation one of her Big Picture Goals for 2026, said the project hadn’t done enough to bridge the distance between enthusiasm and impact.

“I’ve seen many folks that are eager to help, there is a willingness and excitement,” Hubbard told The Repository. “Though, they often ask where to start. What is the first move? We tell folks to come and contribute, then send them to Slack channels, handbooks, tickets, and they have yet to understand the culture, so it may be difficult for them to be air dropped and ping. This fails a lot of people.”

Hubbard described Pathways as an attempt to change the approach. “The goal is to give someone a guided route into real contribution: what to learn, where to go, who to ask, and what a first useful contribution looks like,” she said.

The catalyst was WordPress Credits, the WordPress Foundation’s student contribution program, which has grown rapidly since its launch at WordCamp Europe 2025. According to the latest Education Buzz Report, a monthly report tracking the project’s education initiatives, 292 students from 18 universities and institutions are currently contributing to WordPress, supported by 66 mentors. Ten new institutions joined in March alone, more than doubling the program’s institutional footprint. 

Hubbard said Credits made the onboarding gap impossible to ignore.

“When you have hundreds of students arriving through institutions, you can’t rely on tribal knowledge or personal introductions,” Hubbard said. “Students struggle with the same things general newcomers do, but faster and more visibly: unclear tools, unclear norms, unclear ownership, and not knowing whether their work is actually useful. Scale forces clarity.”

Data from the Contributor Dashboard pilot, which went live in March at wpcontributordashboard.org, reveals how much the project has been losing. Across five years of tracked activity, more than 6,100 of roughly 16,800 contributors made only a single contribution — a 37% drop-off risk. The average time from account creation to first contribution stands at 90 days. New contributor numbers are down 32% compared with the same period last year.

The Pathway Guides are organized into seven categories — Build, Design, Write, Translate, Test, Organize, and Promote — and are designed to be scannable rather than exhaustive. Each guide covers the steps involved in a particular contribution type and links out to the relevant team handbooks, rather than duplicating information that already exists. The collection is maintained in a community-owned GitHub repository, so any team can propose or edit guides directly.

Hubbard said Christensen was also developing a second component that would give new contributors a defined project they could complete and feel good about.

The Good First Issues board aims to solve a different version of the same problem. Beginner-friendly issues have always existed across WordPress project repositories, but they are hard to find and harder to track. The board aggregates them automatically from connected repositories. Because it cannot retroactively import old issues, Christensen is asking existing contributors to help clean up stale items, follow up on issues awaiting review, and ensure open good-first issues include enough context for someone unfamiliar with the codebase to pick them up.

The Pathways work sits within a broader push that Hubbard has been driving since she outlined her priorities in January. That push includes the Contributor Dashboard, a revamp of WordPress meetups to focus on hands-on contribution rather than passive attendance, and a longer-term effort to develop WordPress Foundation credentials. 

Earlier this year, Mullenweg described 2026 as “the year of the meetup,” and in recent weeks he has called for a fundamental rethink of how the project recognizes and values contributions, including his argument that Five for the Future’s data had become “worse than useless.”

Hubbard framed education and contribution as two sides of the same problem.

“Education is a flywheel,” Hubbard said. “It brings new people in, but it also strengthens the people already here. Pathways and the education programs are designed to do both. They create an entry point for new contributors, and they give existing contributors a way to build new skills, validate what they know, and stay relevant.”

Asked what success would look like at WordCamp Europe, Hubbard said it was simply about demonstrating the model clearly enough so contributors could see how it works and where they fit.

“I treat this work as a pilot,” she said. “That gives us permission to test, adjust, and, if needed, stop or abandon pieces that aren’t working. So the goal is to show it in practice, socialize it across teams and contributors, and learn quickly.”

She said retention would come from connection and momentum rather than process. “The first contribution is the starting point,” she said. “Meetups and social touchpoints are where people build relationships and start to feel part of something, not just passing through it.”

Contributors are encouraged to review the new Pathway Guides, help draft new ones, and connect their repositories to the Good First Issues board. Discussion is also happening in the #core-program channel on WordPress Slack.

Disclosure: Automattic-owned Pressable is a sponsor of The Repository.

WordPress core contributor Joe Fusco has released an experimental plugin that surfaces who else is logged into the WordPress admin and what they’re working on.

The WP Engine-sponsored contributor announced the Presence API feature plugin on the Make WordPress Core blog this week. The project is a spin-off of a database table he proposed to fix cache invalidation issues in real-time collaboration, and he’s seeking feedback.

The plugin aims to solve three problems: there’s currently no way to see who else is also logged into a WordPress site; the only way to find out someone else is editing a post is to try opening it yourself, and by then your work may already overlap; and the post list doesn’t show which posts are currently being edited by another user.

The plugin features two dashboard widgets — one showing who’s online and another displaying a list of posts that are currently being edited — an admin bar drop-down list that shows who else is online, an “Editors” column on the Posts screen, and an “Online” filter for the Users screen. It also has REST endpoints and WP-CLI commands, and a post-lock bridge that co-exists with existing _edit_lock behavior.

All features are gated on the edit_posts capability, with full technical details available on the project’s GitHub page.

The project came out of Fusco’s recent efforts to help find a fix for the cache invalidation issues that have dominated the WordPress 7.0 release cycle. As we’ve reported, RTC’s reliance on post meta to store awareness data was found to invalidate persistent post query caches site-wide whenever any user had the editor open. Fusco was a key contributor to the Trac ticket that followed, proposing two new database tables: wp_collaboration and wp_presence.

While core contributors have moved ahead with wp_collaboration (it’s now one of four storage approaches hosts are currently testing as a solution for RTC in 7.0), Fusco built the Presence API feature plugin independently to test RTC, using a dedicated ephemeral data table with a 60-second TTL and data flowing through the Heartbeat API.

In his announcement, Fusco said he presented the plugin during a Core Dev Chat meeting and it was transferred to the WordPress GitHub account. It was submitted to the WordPress.org plugin directory on April 6. 

He has invited feedback on whether the dashboard widgets, admin bar, and post list are genuinely useful, and if there are other admin screens or workflows where presence would also be useful. Two Playground blueprints with five and 40 seeded editor accounts let testers see how it handles density without a second browser.

Discussion is happening in a new #feature-presence-api channel in WordPress Slack, with bug reports welcome on the project’s GitHub repository.

Disclosure: WP Engine is a sponsor of The Repository.

The WordPress AI Team has shipped version 0.8.0 of the WordPress AI plugin, rolling out new editorial workflows and integration with the Guidelines feature in the Gutenberg plugin, with work also underway on comment moderation and AI request logging.

Released earlier this week and available to users testing WordPress 7.0, the plugin’s image generation and editing feature has had its experimental flag removed, while a new Refine From Notes experiment allows users to automatically apply editorial feedback to post content.

In the announcement post, project lead Jeffrey Paul, a Fueled-sponsored contributor, wrote that refining from Notes allowed users to refine their posts more efficiently with fewer manual edits.

“This supports more streamlined editorial workflows and moves toward more agent-like content refinement experiences,” he wrote.

The release also introduces two new AI dashboard widgets, along with a new extensible framework for registering additional dashboard widgets. An AI Status widget shows plugin onboarding steps, along with the status of available connectors, features, and experiments. An AI Capabilities widget displays the number of available abilities across the plugin and connected AI services.

“These widgets improve discoverability and help site administrators quickly understand what AI capabilities are available on their site,” wrote Paul.

Image generation and editing, first introduced as an experiment in version 0.4.0 in March, is now a stable feature. As part of the promotion, references to older DALL·E models have been dropped in favor of newer image generation models, including gpt-image-2.

Abilities in the AI plugin can now integrate with the Guidelines experiment in the Gutenberg plugin, letting AI-generated content respect site-wide editorial standards on tone and style. When Guidelines are configured, supported abilities pick them up automatically.

The plugin’s Title Generation feature now uses a modal interface that lets users preview and refine suggestions before applying them, with support for multiple regeneration attempts and inline editing.

Other changes include bulk enable and disable controls for experiment groups, and reduced context sent during Review Notes processing to bring down token usage and model costs. There have also been several UI improvements to refine the settings experience, making it clearer and more consistent with WordPress design patterns.

Looking ahead to 0.9.0, there’s plenty more coming. According to Paul, work is underway on new onboarding flows in support of a “Try AI” callout in WordPress 7.0, and new experiments focused on content resizing, comment moderation, AI request logging, and content provenance tracking for text and images via C2PA.

Several early prototype experiments are also being explored, including type-ahead suggestions, extended provider support, integration with the experimental media editor in Gutenberg, Connector usage approvals, and tools like the AI Playground and deeper MCP integration.

“These concepts are still exploratory, but they help test how AI could support real workflows across WordPress,” Paul wrote. “We encourage users and developers to review and test these ideas and share feedback so the most valuable experiments can mature and land in upcoming releases like 0.9.0.”

Paul encouraged contributors to get involved by reviewing open issues and pull requests, and joining discussions on GitHub.

WordPress 7.0 has a new release date of May 20, with a call for hosting providers to help test real-time collaboration expected to follow today.

Release coordinator Amy Kamala published the updated release schedule on the Make WordPress Core blog on Wednesday, which has a new beta scheduled for May 8 and a new release candidate on May 14, ahead of the final 7.0 release.

Kamala said the versions would retain RC names in their version strings to avoid confusion when sites update, with the new beta versioned RC3 and the new release candidate versioned RC4. Only RC4 will be a true release candidate as RC3 will be treated as a beta in practice.

Kamala flagged that last-minute changes to the schedule were possible and the timeline could still shift depending on host feedback.

“Thank you all for your flexibility in these recent weeks while WordPress contributors around the world worked tirelessly on necessary architectural improvements for the 7.0 release,” Kamala wrote.

The release was originally scheduled for April 9 during Contributor Day at WordCamp Asia but was paused in late March after WordPress co-founder Matt Mullenweg called for a return to beta releases to allow more time to address a cache invalidation issue found in real-time collaboration.

The forthcoming call for testing, led by Bluehost-sponsored core committer Jonathan Desrosiers, will ask hosts to run a new script that benchmarks four possible data storage architectures for real-time collaboration against their own environments.

The four approaches are the implementation in the current 7.0 pre-release, which stores both awareness and updates in wp_postmeta; a dedicated wp_collaboration database table; a transients approach that stores awareness in the object cache; and a hybrid combining the database table with object caching for awareness.

Awareness is the data that tracks who else is currently editing a post — their presence, cursor position, and selection — and it’s read and written on every poll cycle, which is why it has become the central performance question for RTC.

The testing script has come together over the past week in the #feature-realtime-collaboration channel in WordPress Slack, through work from Automattic’s Max Schmeling and Alec Geatches. Schmeling wrote the WordPress PHP side, and Geatches wrote the Node.js script that hits the /updates REST endpoint and produces a per-poll breakdown of response times. 

Desrosiers has since pulled their work into a new distributed-rtc-performance-testing repository on GitHub and added a wrapper script that tests all four approaches in a single command.

Earlier testing on WordPress.com, shared with the release team on Slack, captured query logs during roughly 2 minutes of collaborative editing across two browser tabs on disposable test sites spun up via Jurassic Ninja, Automattic’s WordPress sandbox tool. The pre-release implementation generated close to 4,000 SQL queries. The custom database table cut that by 67%, and the transients approach by 80%. The hybrid approach hasn’t yet been benchmarked.

Query volume matters because on shared hosting every request ties up a PHP worker until it completes, as Desrosiers noted in Slack, and a feature that polls aggressively across multiple tabs and collaborators can chew through workers quickly. That’s the scenario Mullenweg has repeatedly flagged and that the host testing is intended to measure.

Hosts have already been testing RTC, including WordPress.com, which has enabled RTC for 100% of sites on its shared infrastructure. GoDaddy contributors have also been testing RTC, with Desrosiers saying early feedback from the company had helped improve the testing script so it would run in more environments.

Fueled-sponsored core committer Peter Wilson, who first proposed a dedicated wp_collaboration database table for RTC in February, opened a pull request for the hybrid approach on Sunday, building on an earlier PR by WP Engine-sponsored core contributor Joe Fusco. Wilson’s version stores awareness in a persistent object cache when one is available and falls back to the custom table when it isn’t, while updates and sync data go in the custom table in both scenarios.

“Awareness uses a persistent object cache when available (this is the key to the transients approach performance, not actually transients),” Wilson wrote in the #feature-realtime-collaboration channel in WordPress Slack.

Wilson said on Tuesday he was particularly interested in feedback from systems engineers or database administrators on the proposed table structure, noting that even after the delay he hadn’t heard anything specific about it. 

Mullenweg is expected to review the test results from hosts and make a final decision on which storage approach will ship in 7.0, according to notes from a release squad call on April 15 that Automattic’s Anne McCarthy shared with the release team on Slack.

The May 20 release will land just over two weeks before WordCamp Europe, which is set for June 4–6 in Kraków, Poland. Earlier release timeline proposals had considered releasing during or after the event, but Desrosiers argued against tying the release to WCEU.

“While it would be great to coincide with WCEU, I’d like to recommend that we do not introduce all of the surrounding planning and coordination that needs to take place for that so that everyone can focus on the release itself,” he wrote, adding that WCEU Contributor Day could serve as a jumping off point for WordPress 7.1.

A May 28 final release was also considered, but independent core committer Aaron Jorbin flagged conflicts with Eid al-Adha, expected to start on May 26, and with Shavuot and Orthodox Christian Accession Day falling on May 21.

Disclosure: Automattic-owned Pressable is a sponsor of The Repository.

When agency owner Dinesh Jain asked WordCamp Asia’s Q&A panel how companies could best contribute to WordPress, core committers Peter Wilson and Sergey Biryukov gave the same answer: sponsor contributors. WordPress co-founder Matt Mullenweg disagreed.

The exchange put a spotlight on Five for the Future, the initiative Mullenweg launched in 2014 to encourage companies to dedicate 5% of their people to working on WordPress, and a tension he says has been building for years — recruiting sponsored contributors has come at the cost of overshadowing the work of volunteers and hobbyists.

Since the Q&A on Saturday, Mullenweg has gone further, posting on the Make WordPress Core blog about elevating individuals, and in the #five-for-the-future channel in WordPress Slack, where he said the program’s data was “worse than useless.”

The Q&A split

Jain’s question came during the closing keynote and Q&A in Mumbai. Wilson, who is sponsored by Fueled to work full-time on the WordPress project, said sponsored contributors had the freedom to give to the project year-round in ways someone contributing in their spare time could not.

“I think that’s a really impactful way of doing it as a company because it’s not one day, it’s 365 days a year,” Wilson said.

Biryukov, who is sponsored by Yoast and also works full-time on the project, said sustainability across WordPress’s 20-plus Make teams required more companies to step up. 

“To make things sustainable, we need more companies to sponsor contributors,” he said. “I think that’s the biggest impact that companies can make.”

Mullenweg, who was unable to join the Q&A in person, relayed his reponse via Automattic’s Head of Communications, Chenda Ngak. He said he wanted to retire the term “sponsored contributor” altogether and pushed back on the framing Wilson and Biryukov had just offered. He questioned what the project had lost by making companies so central to contribution, and said he would prefer contributor badges to show WordPress.org usernames, hometowns, and websites rather than employer names.

The Make post

Mullenweg expanded on those remarks in a post published to the Make WordPress Core blog shortly after the WordCamp, prompted by a photo of an attendee badge he saw on X.

My WordCamp journey started in Mumbai as an attendee. Now, in the same city, I get to be the part of the org team for @WordCampAsia
⁰Grateful for how far this community has brought me!#WordPress #WCAsia2026 pic.twitter.com/lOJtSEk4QK

— Krupa | Freelance QA Engineer | #WCAsia2026 Org (@krupajnanda) April 10, 2026

“Krupa, sorry to use you as an example, but the giant SELF EMPLOYED on your badge shocked me, and led me down a path of thinking of all the ways my push to get companies doing what Automattic and Yoast has created some issues in its success, and the unintended consequences it’s maybe led us to,” he wrote, addressing the badge’s owner and also referring to Yoast’s early involvement as an active contributor to the project.

He said he had first heard the problem framed by core developers who felt the project was doing more to recognize corporate contribution than individual effort, with several telling him it felt like a bigger deal to contribute without being paid, and that this was not being acknowledged.

He highlighted several places where he said corporate emphasis had become entrenched: 5ftF testimonials, the plugin and theme directories, the business model of WordCamps, and his own presentations going back six or seven years. 

He also raised a structural concern, arguing that in delegating decision-making authority to teams and committees, the project had lost a clear forum for issues that cut across all of them.

The Slack conversation

Mullenweg also posted in the #five-for-the-future channel in WordPress Slack on Sunday and has continued throughout this week, calling the program’s data “worse than useless with how we’ve structured the program” and suggesting ways 5ftF could be improved.

He acknowledged that the program had been structured to encouraged pledges, but those pledges were never followed up, and “even if they did work not caring how it impacted our goals.”

He outlined four problems he said needed to be addressed: the elevation of commercial presence over hobbyists, students, and volunteers; pledges being treated as a completed action rather than a first step; the absence of activity tracking after a pledge is made; and Make teams losing sight of their “higher purpose” in favor of process and intermediate goals.

Revisiting an ongoing problem

None of this is new ground. A roundtable at WordCamp Europe 2025 sparked fresh momentum to reform 5ftF, with hosting contributor and Rapyd Cloud Managing Director Wes Tatters warning at the time that the community had a six-month window to act before the moment passed.

“It started as something voluntary, then became an implied obligation — and then it was turned into a weapon,” Tatters told The Repository at the time. “As soon as companies feel they’re being forced or shamed into contributing, you lose buy-in.”

A contributor dashboard pilot, now live at wpcontributordashboard.org, has been the most concrete step taken in recent years toward addressing the contributor visibility gap. The dashboard maps contribution activity across Make teams into a shared ladder framework.

Several contributors responded to Mullenweg’s Make post. Anne McCarthy, who works at Automattic, said she had opened an issue to design a best-practice badge template that all WordCamps could use.

“I agree that right now we have swung too far towards emphasizing companies sponsoring people rather than the people doing the work, sponsored or not,” she wrote.

McCarthy also supported bringing back Lead Developers.

“Personally, I’d love to bring back Lead Devs and refresh the list. I think this is a net negative in the project and is a learning that I think we lost along the way,” she wrote. “It’s left big gaping holes in terms of accountability and responsibility that I see show up in releases every time when decisions need to be made.”

Amber Hinds, CEO of Equalize Digital, argued that measuring total hours contributed was structurally biased toward large companies. 

“It would be better to ask how many hours are being contributed of available hours,” she wrote, noting that a single person volunteering half their time was personally giving far more than a company whose hundreds of pledged hours represented just 5% of available capacity.

In the #five-for-the-future channel, GoDaddy-sponsored contributor Courtney Robertson pointed to a question that has lingered since Mullenweg’s dispute with WP Engine went public in 2024: who actually owns the WordPress project’s infrastructure. WordPress.org is owned personally by Mullenweg, and Robertson said one of the most persistent friction points for contributors working on things that live on WordPress.org was his characterization of it as his personal site.

“The community needs to hear you clearly say that is part of contributing to the WP project,” Robertson wrote. “Yes, a lot can be done now via AI to need less humans in some areas… but also, having it written somewhere, having you personally deliver that would likely go a long way.”

Mullenweg’s response addressed the ownership question obliquely. “I know some people are like ‘we’re just enriching Matt,’ which is funny because a lot of this new stuff is going to be more expensive and make me poorer 😂 but that’s okay,” he wrote, noting that most of WordPress.org runs on GPL software.