WordPress Podcast (English)

For a decade, WordPress’s HackerOne program received between 20 and 30 reports a month; this year it already exceeds 3,000, more than the previous twelve years combined.

Remember that you can listen this program from:

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from October 26 to November 1, 2026.

Two months after launching the Core Security Initiative, the security team takes stock with figures that explain why we’ve seen so many patches in a row. For a decade, WordPress’s HackerOne program received between 20 and 30 reports a month; in July it received 450, in August 773, and this year it already exceeds 3,000, more than the previous twelve years combined.

Much of this is research accelerated by AI tools, which makes WordPress more secure but means everything that comes after (triaging, fixing, backporting, testing, and publishing) has to move faster. That’s why there have been four security releases in 41 days, from 7.1.1 to 7.1.4, seven since mid-July, with more than 50 critical or high-severity vulnerabilities closed and every fix carried to all supported branches, down to 4.7.

Each release has a fixed team of trusted people with clear roles, ships in two waves to protect the most-used versions first, and automates the slow parts: backporting, which used to be done by hand across up to 25 branches, now has 73% of the 109 steps of a security release automated, with open tools. Some friction is kept on purpose, such as only a small group being able to package releases, to guard against supply-chain attacks.

Almost 3,000 reports have been closed this year, and the untriaged queue dropped from 359 to double digits. The team has refocused its tooling on finding core vulnerabilities before anyone reports them, using open-weight models and custom harnesses, and WordPress has enrolled in Anthropic’s OSS Scanner, which offers free analysis to open-source projects, with first results already under review and Anthropic credited in release announcements.

WordPress 7.1.4 is the fourth security release in 41 days, the one the Core Security Initiative update mentioned, and it arrives with a long list of fixes. The most serious is a flaw in the update process that could allow remote code execution during the window in which an update is applied. The rest are mostly stored XSS: via manipulated block markup, in the Customizer’s selective refresh, in the Categories, Playlist, Image, and comment pagination blocks, in personal data erasure requests, and in manipulated usernames, plus several in the Interactivity API, along with a stored denial of service in that same API. Also fixed: Customizer changeset drafts could be viewed without authentication, and Notes could be read by users with privileges but without access to edit the post. Bundled root certificates are also updated.

As always, update immediately; patches are backported down to 4.7, and this is a short-cycle release: the next major one is still 7.2, on December 8. The announcement doesn’t detail CVEs or total figures, and the HelpHub entry expands on the details.

In parallel, 7.2 is advancing: Beta 2 has already been followed by a Beta 3 with all applicable 7.1.4 fixes. The second beta keeps polishing the release without schedule changes or striking new features: work continues on the Abilities API, with content querying, capability requirements, and schema and permission improvements; server-side registration capabilities for DataViews and DataForm arrive; and REST API flexibility, desktop resource loading, and the move to SVG icons continue to be refined.

Feature Notifications, the project to give WordPress a unified notification system, now has a design proposal showing what it could look like, tested against all the messages WooCommerce and WooPayments show today, and a live demo.

The idea is a single bell for the site, available not just on some screens like current notices but across the whole dashboard, inside the editor, and on the public side of the site. Each notification opens to show what it’s about, who sends it, and a clear next step, and real problems stay at the top until resolved.

The second version of the prototype focuses on the rules that make everything look and behave the same regardless of who sends it. Plugins send data, not design, choosing among four formats, and each notification is described along five dimensions, including type, severity, and read state, whose values the core defines. Critical items are rare and visible: they tint the counter red until resolved, not just until read. There’s an alerts tab, and limits against noise, such as repeated notifications being replaced or grouped, and tips and offers being switchable all at once.

The WordPress AI team has published a proposal to let anyone manage their site with the AI agent of their choice, without having to put an assistant inside WordPress. Millions of people already use agents to search, buy, or run businesses, and products and several plugins and tools have shown there’s demand for managing sites this way. You open the agent, ask it to help with your site, the agent recognizes WordPress, gives you a link to authorize access, you log in, and you’re in. Today that requires installing and configuring the MCP adapter, getting the right abilities, and managing authentication with application passwords, with the risk of ending up pasting them in plain text into the agent, which isn’t ideal.

The approach has four coordinated fronts, using the WordPress 7.2 cycle to lay foundations and targeting 7.3 for core integration. The first is the MCP adapter, which will iterate quickly to gain reliability and security, with the idea of proposing to bring MCP into core in 7.3, either merged or packaged to evolve separately. The second is Abilities, defining a basic set for common management tasks and assessing whether some can land in 7.2 already. The third is OAuth authentication, to authorize agents without generating and sharing application passwords, which would also benefit the REST API and could rely on 7.2’s Secrets API to handle tokens securely. The fourth is an end-to-end user experience, from the moment the agent discovers the site to managing or revoking permissions.

The Community team has acknowledged a privacy issue on event ticket pages: between May 20, 2025 and October 28, 2026, some people who had chosen not to appear on the public attendee list appeared anyway. The ticket edit page showed “Yes” to the question of whether to appear on the list even when “No” had been answered, and saving it, for example to change a name, switched the answer to “Yes.” Names and Gravatars were shown and, for some events, links to websites or social profiles and details such as company or job title; according to the review, no emails, phone numbers, addresses, or food or accessibility answers were exposed. Roughly 1,280 tickets across 168 events were affected, led by WordCamp Asia 2026, WordCamp Europe 2026, and WordCamp Dhaka 2025. Because the earlier response wasn’t logged, the team hid the listing for everyone who could have been affected, about 8,580 tickets, including some who had actually chosen to appear, and fixed the bug the same day it was found. An email will go to organizers and attendees of upcoming events; anyone who wants to reappear must open the link in their ticket email, set “Yes,” and save. For questions about personal data, [email protected] is the contact.

There’s also a more pleasant update for event organizers: CampTix introduces QR code check-in and QR codes on badges. Each attendee receives their own code, in the email and on their ticket page; at the door, the volunteer opens the secret address on a phone, scans the code, confirms with “Yes,” and the row turns green. The scanner warns if the ticket is refunded, cancelled, pending, or already checked in, and a shared code can be reissued to invalidate the previous one.

The next bbPress release is again a security and maintenance one. 2.6.21 strengthens access control in forum feeds, search results, BuddyPress activity, group forums, attachment requests, topic moves, and redirects from old topics and replies. Legacy forum passwords are now applied consistently when WordPress displays topic and reply content, and moderation requests to Akismet must use HTTPS.

On maintenance, forum freshness and child-count queries are improved, metadata is preserved when a database query fails, and original dates and revision content are kept when moderating and editing. Simple orphaned list items are also repaired in WordPress 6.9 and later, generated excerpts are kept without duplicating content, the ugc relationship is added to topic and reply links, and admin icons are updated for WordPress 7.2 and later, in line with the change from Dashicons to SVG.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!

The WordPress Photos team has created PhotoFetch, a plugin that makes it quick and easy to search for royalty-free photos and add them to your website.

Remember that you can listen this program from:

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from October 19 to 25, 2026.

WordPress 7.2 is now in testing: Beta 1 came out on October 20 and, as always, it is for testing environments only, never for production sites.

The planned release date is December 8, which is the one in the announcement and in the release party schedule. The Test team’s testing guide says the 9th, a discrepancy to keep in mind. It is the last major version of 2026 and arrives with the new default theme, Ipsum.

For people who edit content, the most visible change is a batch of editor improvements. The responsive styling introduced in 7.1 is expanded, especially in the Gallery, where you’ll be able to set columns, cropping, and image aspect ratio per screen type. Global Styles gets a “Custom” filter to show only blocks with modified styles, and, back after being postponed in 7.1, inherited values are shown in the block inspector controls. Text shadows with their own controls are added, along with styling of form elements without touching code. Notes gain emoji reactions, their own icon in the toolbar, and a minimized mode, and they move to the canvas margin so they can stay open alongside the block settings bar. There is also navigation link management from the Site Editor sidebar, clearer error messages, and a post inspector rebuilt with the DataForm system.

In media and administration there are several useful changes. Client-side image processing comes to the Media Library, and it finally fixes a limitation from twelve years ago: animated GIF and WebP thumbnails keep their animation. The media inserter is redesigned for very large libraries, and crops are linked to their original image, so the library doesn’t fill up with loose duplicates. The dashboard debuts the “On This Day” widget, switches the admin bar and menu Dashicons to SVG icons, and adds an option to disable metabox reordering, aimed at touchscreen devices. For anyone working in hosting, a performance change deserves attention: WordPress stops combining scripts and stylesheets into large files, loads them separately to make better use of browser caching, and preloads the admin screen most likely to be visited next.

For developers, the big news is the Secrets API, a standard way to store API keys and tokens with encryption, credential rotation, and customizable storage providers, with WP-CLI support and checks in Site Health, based on the proposal from recent weeks. Random content redirects also arrive, along with new capabilities in the Abilities API, the data-wp-html directive of the Interactivity API, and further hardening of the HTML API. The Test team is asking for help with a detailed guide that explains what to test in each feature. Anyone who finds bugs can report them on the forums, in Trac, or in the Gutenberg repository, including WordPress and PHP versions, theme, plugins, and steps to reproduce.

The technology behind WordPress Playground now runs another content management system in the browser. Herman Peeren, a Joomla contributor, has created Joomla Playground, a community project still in an early stage that opens Joomla in a tab, with its admin area and public site, and no local PHP server or database. It relies on two pieces of the WordPress ecosystem: the wasm packages, which run PHP as WebAssembly in the browser, and mysql-on-sqlite, the library that lets MySQL queries run against SQLite, to which he has connected a custom Joomla adapter. It works in Chromium-based browsers, documents Joomla 6.2 and 5.4 with PHP 8.3 to 8.5, and allows saving the site in the browser, importing and exporting ZIP files, and inspecting email without sending it.

What’s interesting for the WordPress side is what Joomla contributes back, because its use exposes cases WordPress alone doesn’t exercise. In SQL compatibility, for example, session identifiers stored as binary values didn’t match the text comparisons Joomla uses and broke login, a case that could become a regression test for the shared library. Saving thousands of loose files in browser storage was slow, so Peeren moved to a shared base ZIP plus a snapshot of the modified files, relying on the Playground filesystem’s change log. By his measurements, saving dropped from 13 seconds to about 0.3. And because a single PHP process was shared, a dropped network connection blocked subsequent requests for minutes, and background search indexing jumped ahead of navigation. Enabling networking through the browser’s fetch and chunking the indexing so it yields its turn roughly halved the time until the demo was usable.

The WordPress Contributor Toolkit, the desktop app for contributing to Core and Gutenberg, reaches version 2.0 with a redesigned interface and translated into ten languages. The Core and Gutenberg workflows we saw in the previous version remain the same. The entire window is built on the WordPress design system, so buttons, notices, and dialogs will be familiar to anyone who uses the block editor, and the site list now shows each site’s server status. There is also a settings dialog with three groups (general, sites, and account), with light, dark, system, or custom themes built from a background and a primary color, and options such as each site’s PHP version or whether whatever was running when you closed the app starts again.

The other major change is language. All interface strings are translatable on translate.wordpress.org, and 2.0 includes Czech, Dutch, English (Canada) and English (UK), Galician, Hungarian, Lao, Polish, Serbian, and Turkish. A language enters the app once it’s at least 80% translated, so the list will grow with each release, and the team itself proposes translating it as a first contribution. By default the app follows the operating system’s language.

There are also improvements aimed at everyday Contributor Day use. After applying a patch or pull request, site details show the changed files as a tree, separating those from the patch and your own, with a button to revert just one without losing what you’re testing. Data read from Trac, such as summary, status, or component, is kept when you close and reopen the app, with a button to refresh it. And the installation is about 350 MB lighter, which matters when everyone downloads at once on the same network.

Emre Erkan, Locale Manager for the Turkish team, has measured how many people with management roles in Polyglots are still active, and the result is rather discouraging. He reviewed the public profiles of the 870 people who are Locale Managers or General Translation Editors across the 203 locales. Only 31% have translated something in the last 90 days, 15% did so between three months and a year ago, 36% more than a year ago, and 17% have no recorded activity since mid-2022. Broken down by locale, in 95 of them, nearly half, no manager or general editor has been active in the last quarter, and in 74 not even in the last year. It matters because they are the ones who open the door for others: without them no one grants the project translation editor role, and those who wait eventually leave quietly. The manual’s inactive-locale process only triggers when a translation is two major versions behind, so a locale can look up to date thanks to two or three people while nearly all of its managers have been gone for years.

In the comments, Emre added a second analysis of editor requests published since 2022: 4,601 entries and 6,640 requests per locale. Half were answered by a manager or editor from the same locale, with a median of nine hours, but 39% never received a reply from their team, and in 1,901 of those cases the only person who handled it was Tor-Björn Fjellner. The most striking part is the pace: between January and October 2026 there were already 2,821 requests, 2.4 times the total for all of 2025, which ties into the wave of machine translations we’ve covered. Tobi confirms it: most locales depend on one or two active editors, and the pressure from developers who send thousands of strings to languages they don’t speak is wearing people out. It’s also noted that project editors go inactive because they only work on the project that interests them and get no notifications afterward, and that imports marked as “current” aren’t recorded in profiles, so the figures skew toward inactivity.

On solutions there is broad agreement. An honorary or emeritus status has been proposed for some time, partly for security reasons, since it’s worth limiting the permissions of those who no longer contribute, especially without two-factor authentication, and partly so newcomers feel needed.

WordPress Credits, the program that connects students from partner institutions with real project contribution work, opens sponsorship tiers for 2027. It started with eight institutions, and in its first year it has worked in 17 countries and reached more than 900 students, figures you can follow on the program’s public dashboard. That growth is the reason for the change: curriculum, translation, tools, and onboarding of new institutions need stable funding, and the current sponsorship system wasn’t designed for that. It will be a pilot, and the team promises to publish what it learns and retire what doesn’t work. Current sponsors have funded mentors and contributed products that students use, and the tiers are built on what they made possible.

There are five tiers: Friend, in kind through Five for the Future, for companies that already sponsor mentors; Supporter, at $5,000 a year; Backer, at $10,000; Champion, at $15,000; and Partner, from $30,000. All appear on the partners page and are mentioned in the mentor feature. From Supporter up you get a logo, a badge for your own website, and an annual report. From Backer, you can name the specific part of the program being funded, with a report on that cost and an educational article about the sponsored product. Champion adds another article with factual, neutral information about more products, an invitation to the annual educational partners session, and a joint webinar or event. The company writes the articles, but they are published on wordpresseducation.org after team review, so that what gets published is useful to students first. Apart from the tiers, any sponsor can donate free access to their products, which the Foundation distributes, with no card required and with a way to export the work so no one is locked in.

The tier the team most wants people to look at is Partner, which funds a complete, named program. The team hasn’t been able to build one until now because they were limited to the available budget. The sponsor would be the exclusive partner of that program, would appear at its launch, and would receive a dedicated report. The team prefers to design it together with the sponsor rather than offer a closed list. Among the ideas: students translating WordPress into under-covered languages, working on accessibility, or building websites for nonprofits that couldn’t otherwise commission them. A program manager will contact each current sponsor to adjust their tier. Campus Connect events are outside these tiers.

There’s already a plugin to use the Photos directory without leaving the dashboard. It’s called PhotoFetch, is published in the WordPress.org plugin directory, and lets you search for photos and import them directly into the Media Library. It has its own screen under the Media Library menu for searching and importing, but it also integrates into the editor’s media picker, as a tab next to the Library tab. The Photos directory gathers images contributed by the public under the CC0 license, that is, free of rights, so the plugin saves you the step of downloading a photo and re-uploading it by hand.

The interesting part is where it came from. A seven-person team built it during the Contributor Day at WordCamp US 2026. Starting from the idea and the research to assess its feasibility, the rest of the day went to features, documentation, and testing. It’s a good example of what a well-used contribution day can deliver.

The BuddyPress team has published the security releases 14.5.3, 12.7.3, and 11.6.3, with patches for the three branches still receiving support. The following day a 14.5.4 also arrived, but don’t be confused: according to the notes for that version, it doesn’t bring new fixes. It’s just a version-number change added to the main branch so sites can update. All the fixes are in 14.5.3, and since the database version doesn’t change, there’s no migration to run.

The six fixed bugs are significant. There are two SQL injections, one blind in profile field management and another from an unbound argument. It also blocks an abuse of the maybe_unserialize function, and prevents users without administrator permissions from assigning themselves member types. The other two have to do with groups: you can no longer comment on activity from groups you aren’t a member of, and the REST API stops revealing details of hidden groups.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!

Getting good translations of the WordPress interface is harder than ever, and AI is to blame.

Remember that you can listen this program from:

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from October 12 to 18, 2026.

Getting good translations of the WordPress interface is harder than ever, and AI is to blame.

Machine translation has helped for twenty years, but now many developers use models like ChatGPT or Claude to translate their plugins and themes in bulk into languages they don’t speak, and expect volunteers to review the output, which takes far more effort than generating it. Each locale team accumulates thousands of pending strings every week, and the usual outcome is spot-checking and approving or rejecting in bulk, with tools that only handle one screen at a time.

At the same time, requests for the project translation editor role have skyrocketed: over the past six months, the team has gone from receiving more per day than it used to per week, and developers aren’t asking for one or two locales, but for ten or twenty.

There are three lines of work. Adapt each locale’s style guide so models can use it, in English and in Markdown; create an automated translator role that can contribute translations but can’t approve or edit those of others, and keep unverified content out of the translation memory; and change the team’s mission, which in addition to training translators will have to teach developers to use machine translation wisely and to internationalize their code properly.

The comments add nuance. For example, one proposal is to limit imports to one hundred strings until an editor approves them; another is that only editors should be able to import and pull requests from the blog; some note that many developers think they need the role to get their translations approved; and others point out that the real incentive is directory visibility, and that an automatic glossary is hard in German because of its compound words.

The most elaborate proposal is not to ban anything, but to make automation visible. The author would declare when importing that they used AI and agree that the strings be marked as unreviewed; editors could release them in bulk or reject them with a single action; they would not enter the translation memory; and users would see the notice before installing, with the option to choose English or disable automatic translations. From Japan, they report that their team reviews only the first strings and leaves change requests, and that their style guide works because many people already feed it to automated tools, with a request form limited to three locales as an idea.

Gutenberg 24.2 is now available, with Notes as the star. They now live in a margin alongside the canvas, so they stay visible while you change blocks or settings, can be minimized or hidden, a deleted note can be undone, and what you’re writing isn’t lost when switching blocks.

The Navigation block gains a single search that covers pages, posts, categories, and tags at once, and the Gallery can sort its images and apply a shared duotone. Design tools keep spreading across dozens of blocks: minimum width and height, shadows, duotone, and image or gradient backgrounds.

For developers, the most important change is that React 19 is now enabled by default, except on sites with a theme or plugin known to have problems, which stay on React 18. This reverses the postponement in WordPress 7.1, and the team asks people to test plugins and themes that use React; it can be disabled in the Experiments area.

Feature Notifications, the project to build a unified notification system for WordPress, is back to life after more than three years stalled: its last version, 0.2.0, dates from April 2023. Jonathan Bossenger, who had to step away in 2023 and has picked the project back up, audited the code and published a plan to reach a 0.3.0, which would be the first truly functional version, able to create, store, display, and dismiss notifications, with the goal of shipping it on December 1, alongside the last release candidate of WordPress 7.2. The foundations are solid, with data models, channel registration, the database schema, and the notification center UI in the admin bar, but the system isn’t connected end to end. The persistence layer is still unimplemented, the REST API returns empty responses, dismissing a notification saves nothing, and the REST controller tests are disabled.

The plan is split into phases that can move in parallel: sorting the open pull requests, building the minimum product with schema migration, repositories, a PHP API for emitting notifications, REST endpoints with a permissions model, persistent dismissal, and a WP-CLI command to generate test notifications. Security and bug fixes come afterward. It will be published as a GitHub release and as a plugin in the directory.

Overall, the return has been welcomed, because dashboard notifications are one of the worst parts of the experience and get worse the more plugins you have.

Continuing the shift toward “server-aware” collaboration, the Core team has published a guide for testing the three candidate sync engines, all in an experimental plugin called Gutenberg Sync Engines.

Yjs is the closest to Google Docs, with live cursors and very fast updates, but it hides conflicts, because one of two simultaneous changes wins without warning, and it requires maintaining two implementations, in JavaScript and in PHP.

DE-RTC is the most similar to the WordPress of old: it only syncs on save, by default every ten seconds, and sets genuine conflicts aside for someone to review. It isn’t real-time, but it’s cheap for modest hosts and lets plugins, scripts, or WP-CLI participate almost like a person would.

Intent-log sends descriptions of what each person did, such as “split this block,” which gives the server context and a readable history, though it processes one update per entry at a time and its merge logic isn’t mature yet.

The underlying debate hits close to hosting. There are five possible transports, from simple polling, which works anywhere, to WebSockets, which requires a separate process, and the guide warns that most shared hosts don’t support long-lived connections, so the typical site will end up on polling, whichever engine wins.

A new bbPress release, again a security and maintenance one, so update again if you run forums. It hardens validation of topic and reply passwords and makes shortcodes stay as literal text when they appear in normal WordPress content loops. The functional addition is a site-wide forum status setting with three modes: open, closed, and frozen; existing sites stay open unless changed.

The rest is maintenance, mostly in the BuddyPress integration: profile actions, group topic routes, activity visibility, and group forum access. Compatibility with third-party theme package subscription links is also restored, moderation forms are preserved after a validation error, and fixes cover notifications, converters, widgets, profiles, theme and reply administration, and restricted content visibility.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!

Connecting remotely to WordPress from your artificial intelligence tool can now be done natively with the MCP Adapter plugin.

Remember that you can listen this program from:

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from October 5 to 11, 2026.

Fifth security batch in the 7.1 version in barely two months: WordPress 7.1.3 fixes seven vulnerabilities and four bugs, with a recommendation to update immediately. None seems as serious as the remote code execution in 7.1.2, but the list is varied: a stored XSS in the admin comments screen, exploitable through pending comments; a denial of service in make_absolute_url; a second-order SQL injection in the WXR export; and a flaw that allowed an Author to feature posts. Added to these are an unauthenticated disclosure of comments on private or unpublished posts, an XSS in Imgur embeds, and an action-name collision in a hook. The patches are being backported down to the 4.7 branch, and all of this fits with what the Core Security Initiative reported about the flood of reports fueled by AI tools.

In the meantime, there is now a release party schedule for 7.2, scheduled for December 8. Beta 1 arrives on October 20; then three release candidates starting November 17, and a dress rehearsal with a 24-hour code freeze on December 7.

Three major changes in WordPress 7.2 Core: HTML, SQL, and CSS standards cleanup.

The most important is the rewrite of the kses function, which has been cleaning HTML from untrusted posts for WordPress’s entire history. The original implementation predates HTML5 and a world where people wrote HTML by hand, and today its almost exclusive purpose is to remove security risks, so the new version relies on the WordPress HTML API instead of regular expressions and chains of functions. It doesn’t change the interface or require modifying plugins or themes, but it does change behavior with unusual input: HTML is normalized (lowercase tags, quoted attributes, rewritten character references), disallowed 

A historic problem in WordPress is back: the users list can always be sorted by first name, but not by last name.

Remember that you can listen this program from:

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from September 27 to october 4, 2026.

Gutenberg 24.1 is, above all, a consistency release for design tools: about 140 of its contributions are devoted to making nearly all core blocks have the same background, color, shadow, and typography options. Background image, size, and gradient, shadows, borders, and link, heading, and button colors now reach blocks such as Accordion, Tabs, Comments, or the Post blocks, and the Group, Author Biography, and Terms List blocks also gain support for text columns. The text shadow that debuted a few versions ago now has its own panel in Global Styles and is available in Paragraph and Heading, and the Cover and Media & Text blocks debut a media selection section in the inspector, just like Image and Site Logo already had.

The Presence API plugin, the piece that shows who is working and where within the WordPress dashboard and which was announced in April, reaches version 0.14.0 with several significant new features. The most relevant is multisite support: the network administrator can now see who is connected across all sites at once, enabled by default on networks that are not large. It also changes how post editing locks are handled, which go from being stored as post metadata to living in the presence table itself; this way, renewing a lock no longer invalidates the post query cache on sites with persistent object caching, a real performance problem. Presence also works with any content type that has an editor, including what someone has open in the Site Editor, and with roles that only edit pages or custom types.

Two aspects stand out above the rest. On privacy, logging is enabled by default, but it can be disabled per site or for the entire network, and there is a section in the privacy policy along with data export and erasure tools; in addition, knowing where each person is remains reserved by default for those who can list users, while everyone else only sees who is connected. And on the AI side, agents that edit through the REST API or through MCP do not send the usual activity heartbeat, so since 0.13 each save records a temporary presence that appears with an “Agent” label in the admin bar and in the editors column. The plugin does not decide who is an agent: it asks the Agent Users plugin or any other that responds through the provided filter. Among the refinements, better performance with a single tab that queries and shares results with the others, Site Health warning if Heartbeat is not keeping presence up to date, and a debugger in the admin bar for development only.

An old WordPress problem has been reopened: on the profile screen, the first name always comes before the last name and no language can change it. In Japanese, Hungarian, Chinese, Korean, or Vietnamese the family name is written first, and WordPress already supports this when displaying the name publicly, but not when entering it. The oldest Trac ticket dates from 2008, and since then the issue has gone from postponement to postponement, waiting for a global solution with a single full-name field that has never arrived, while users in Japan or Malaysia resort to tricks such as putting the family name in the first name field or inverting the fields with CSS.

The proposal is to split the problem in two. First, a small change: that each locale can reorder the profile fields through a translatable string and a filter, without altering the meaning of the data, so there are no compatibility problems. Later on, a site-level setting with three options: first name first, last name first, or a single full-name field. Fumiki acknowledges the bias of the sample: those who participate on Slack or Trac have already gotten used to the English order and respond that it doesn’t bother them, but the person most affected, such as the owner of a small café who builds their website in their own language, almost never shows up there. They ask each locale’s team to share how names are written in official documents, what they do today in WordPress, and whether the change would work for them.

The first comments already add nuance: in Russian the formal order is family name first, but WordPress’s current order doesn’t seem strange because first name, patronymic, and family name is also natural, and the usual approach is to omit the patronymic if there is no field, rather than mixing it with the first or last name. Tor-Björn Fjellner, a Polyglots mentor, argues that the most reasonable option is a single field, because it is impossible to guess where each part goes, and suggests a second field with the sort value. Fumiki sees this as consistent with the W3C’s internationalization recommendations, and adds that what interests them most is knowing how people actually write their names in each region, not the theory.

A contradiction has been detected in the Community handbook about who can organize a meetup event. One handbook page, titled “Any Member Can Organize an Event,” says that any member can do so without filters, while the Five Good-Faith Rules speak of “reliable and trusted” members. The author of the proposal found herself in the middle when someone who had never been to a meetup asked her to organize one and she suggested attending an existing one first; a member then asked her whether anyone can organize or not, and she couldn’t give a clear answer. Her hypothesis is that, when the content was split into separate pages in 2023, the text was copied but the context was lost: in the 2016 version the sentence referred to a specific checkbox in the group’s tools, and the current page’s title turns it into a general principle.

The team’s answer, which reached her by private message and is not written down anywhere, is that any member can organize an event without being a co-organizer, but must coordinate with the co-organizers, who confirm that they are trustworthy and that they follow the rules. That is why it is proposed to confirm this interpretation, remove the “Any Member Can Organize an Event” page, and distribute its content among the group management documentation, the rules, and the record of the case in the handbook audit.

On the Photos team, they have found that the rule against AI-generated images exists, but only verbally. The Slack channel threads since 2023 have been reviewed, and it has been stated on several occasions that a generated image is not a photograph and is not accepted, and the moderators ask that only real photos be submitted. However, neither the guidelines, nor the pre-upload checklist, nor the rejection email, nor the FAQ mention AI, so whoever submits an image doesn’t find out until it is rejected. Nor is it documented how to appeal a rejection, which has left contributors who said they had uploaded real photos without an answer, with the added difficulty that the image is deleted upon rejection.

The proposal is four simple changes: add “AI-generated images” to the sentence in the guidelines that already excludes screenshots and digital art, do the same in the checklist checkbox, expand the rejection reason “Not a photo” or create a dedicated one for AI, and add to the FAQ that anyone who believes it was a mistake can reply to the rejection email attaching the photo. It is limited to fully generated images, and leaves AI editing, such as upscaling or generative fill, for another discussion.

bbPress 2.6.19 is a new security release that applies legacy forum passwords to REST API responses and BuddyPress activity, and reinforces access checks for restricted content in feeds, group forums, and other indirect views. It also hardens moderation and forum role permissions, protects the importer’s credentials and account management, and improves escaping in profiles and administration.

Among the maintenance fixes are corrections in BuddyPress group forum associations and notifications, in converter cleanup, in imported database passwords, in subscription emails, and in reply position.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!

If you want to contribute to WordPress using AI, you can now connect to the Trac MCP server to find tickets, changesets, and everything you need to dig through the backlog of pending work.

Remember that you can listen this program from:

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from September 21 to 26, 2026.

Fourth security release of the series in barely a month and a half, and this time with critical severity: WordPress 7.1.2 fixes a responsibly reported vulnerability that allows an unauthenticated attacker to cause page template resolution to include an arbitrary local PHP file, as long as it is readable, located outside the active theme’s directories. If certain preconditions are met both in the server environment and in the active theme, this can lead to remote code execution. It has its own CVE, CVE-2026-87902.

Update recommended immediately, no excuses this time: the patches have already been backported to all branches with security support, from 4.7 to 7.0, so it’s time to check your version and update as soon as possible.

Direct consequence of the episode we already covered about the launch of WordPress 7.1 on the WordCamp US stage: Anne McCarthy announces that WordPress is abandoning the live on-stage launch format. After two rounds of the experiment, such as State of the Word 2025 and 7.1 itself at WordCamp US, the team acknowledges that tying the launch to a physical event brings more problems than advantages: complex logistics, limits on how many people from the release squad can travel to the event, and the squad itself reporting that running a process that wasn’t designed to be done on a stage adds real, extra stress.

The alternative, proposed by Matt after discussing it with Anne, is to move to a livestreamed Zoom webinar format, with no fixed event date: those who are part of the release squad and of the release itself can share the live session, while everyone else watches and asks questions, allowing more people from the team to participate depending on their time zone, without the cost of traveling to an event. This new format is already kicking off with WordPress 7.2, scheduled for early December, with more details on how to join as the date approaches.

Gutenberg has completed the migration of its JavaScript unit and integration tests, leaving Jest behind in favor of Vitest. The reason comes down to two significant advantages: better native support for modern JavaScript modules, which under Jest required maintaining special configuration every time a dependency adopted that format; and the ability to run component tests in a real browser instead of simulating one, to check things like computed styles, sizes, scroll, or keyboard interaction without relying on imitations. The Vitest tests themselves finished faster than the slowest group of the ones running on Node, so the new browser coverage hasn’t lengthened total run time.

For those who contribute to WordPress core, there is now a public and free MCP server for querying Trac from any AI assistant, with no account or API key needed. It works with Claude, ChatGPT, or any other MCP-compatible client, and allows asking things like what’s still pending on a specific ticket and which pull requests are still open, or requesting a summary of a changeset and its diff, with specific tools for searching tickets, reading a ticket along with its discussion and attachments, checking a changeset, or reviewing the timeline. By default it connects to the Core Trac, but it works the same way with the rest of WordPress.org’s Tracs, such as Meta, Themes, Plugins, bbPress, BuddyPress, or GlotPress, by changing the endpoint.

The WordPress Contributor Toolkit reaches 1.2 with a significant new feature: full support for contributing to Gutenberg as well, not just to core. The flow is parallel to that of Core: when creating a site, you choose whether to contribute to WordPress Core or to Gutenberg, a decision that can no longer be changed afterward and that determines which repository it clones and how it builds it. For Gutenberg, instead of linking a Trac ticket you link a GitHub issue, which brings with it its own pull requests with an “Apply…” button to test them directly, and once the work is done you can open the pull request in the corresponding repository without leaving the application, with device flow authentication that lives only in memory while the application is open.

WordPress Playground’s Dev Tools Dock adds one more tool: an email panel that captures and displays the emails the site generates, without setting up a mail server or checking a real inbox. When WordPress sends a message through its usual path, PHP writes it out to a sendmail-compatible program, and Playground intercepts that message in the browser instead of actually delivering it, displaying it with its subject, sender, recipient, and body, with an HTML preview if the message carries one. It’s useful for almost any plugin that sends emails through WordPress’s normal path: contact forms, welcome or approval messages in memberships, order or booking confirmations, or simply to compare how an email template looks across different themes or WordPress versions.

Third bbPress release in just over a month, though this time without any security surprises: 2.6.18 is a maintenance release focused on legacy forum imports and on password updates at first login. Users imported from legacy forum formats can now update their password when logging in for the first time, even in cases where the original forum database no longer exists; it also fixes topic statuses, reply counts, and forum dates when importing from PHPWind, and restores the Super Moderator edit link on frontend user screens.

The Community team gives updates on the migration of WordPress meetup groups from Meetup.com to events.WordPress.org, the GatherPress-based alternative. After the call for testing at the end of August, which left plenty of useful feedback, the plan for the roughly 700 affected groups is moving forward in three phases: right now work is being done on that feedback; the next step is for real groups to organize real events on the platform to see what works and what breaks, including testing the migration tool that imports data from Meetup.com; and only once the platform and that migration path have held up under real use will it open up to the rest of the groups.

Several things have already been decided: the migration tool will import upcoming events and venues as drafts for the organizer to review before publishing, but it will not copy the member list, since each person will have to join on their own with a WordPress.org account, and for now it will be run by someone from the team itself rather than the group organizer, with past events left out of this first round. Precisely for that reason, the team insists that whoever organizes a group should already start encouraging their members to create a WordPress.org account, because it is going to be an unavoidable requirement to remain in the group after the migration.

Two relevant open questions remain: whether it will be possible to migrate members in bulk by matching Meetup accounts with WordPress.org accounts, something that depends on a pending decision about user data management; and what will ultimately happen to each group’s Meetup.com page, which during the pilot will remain active but redirecting to the new platform instead of running its own parallel attendance list.

Mary Hubbard, Executive Director of the WordPress Project, takes on the presidency of the Open Website Alliance, the body that brings together the organizations behind Drupal, Joomla!, TYPO3, and WordPress to jointly defend free software. The position is rotational among the Alliance’s members, so it’s now WordPress’s turn.

The Alliance was born in 2024 out of the joint work of these four projects in response to the European Union’s Cyber Resilience Act, arguing before lawmakers that their content management systems are not just basic digital infrastructure, but the machinery through which real businesses reach their customers and sell products, and that any security requirement should take that economic role into account without stifling how the communities of developers, translators, and collaborators who maintain the software work.

Hubbard frames the appointment along the same lines as WordPress’s recent signing of the letter on open-weight AI models: the idea that everyone should have the freedom to use, modify, and share the tools they depend on.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!

We now know the roadmap for WordPress 7.2 — what’s being planned for this release, and what shouldn’t make it in.

Remember that you can listen this program from:

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from September 14 to 20, 2026.

WordPress 7.2 is slated for early December 2026, and the team has published the official roadmap for the cycle. As with every roadmap, the team itself notes that everything listed here is under active development, but nothing guarantees it will land as-is in the final release: it’s a roadmap of intentions, not a closed list of commitments.

The item that grabbed the most headlines this week is the default theme itself: it’s called Ipsum, and with it WordPress breaks a decade-plus tradition of naming its themes after their release year. Going forward, each default theme will have its own name and will change whenever the design calls for it, not on the calendar’s schedule. The backstory here is interesting: the team had spent months working on a much more ambitious and expressive theme, codenamed Mētis, meant to showcase everything Gutenberg can already do. After reviewing the direction with Matt, the criteria shifted: the theme bundled with WordPress should be the simplest possible starting point, leaving more elaborate design to exist separately. Mētis lives on as an independent project, but it won’t ship with this release.

Ipsum, named after the classic “lorem ipsum” filler text that occupies a page until the real content arrives, is a blank canvas built for blogs, with dashed lines simulating an editor’s pencil strokes, a handful of type pairings, and style variations that retint the entire page, images included. All the combinations meet WCAG AA. It’s already available to download and test from GitHub, with a very tight feedback window ahead of the 7.2 launch.

Notes, the editor’s internal comment system, takes its most ambitious leap yet: suggestion mode arrives, where instead of simply commenting on a block you can propose an actual text change for someone else to accept or reject — a huge step toward much more direct collaboration between people editing the same content. Also added: emoji reactions on notes themselves, and a dedicated shortcut in the block toolbar to add a note without leaving the writing flow.

The security section brings three heavyweight pieces. Conceptually the most eye-catching is the so-called “sudo mode”: a very early-stage feature proposing to require a one-time re-authentication for especially sensitive admin actions, even with an active session — common in operating systems but new to WordPress; for now only the intent has been announced, with a detailed proposal still pending. The second is the Secrets API, already covered in its initial proposal: it continues moving toward 7.2, with day-one support for WP-CLI while the admin interface is pushed to a later release. The third is a round of improvements and hardening for Application Passwords, with better detection of local environments versus HTTPS, email notifications when a new application password is added, and safer handling of the default role assigned to them. Alongside this is continued hardening work on the HTML processing API, so WordPress parses markup more safely and reliably across core.

The team’s message on AI is very clear and, to be fair, something of a brake: the 7.1 cycle made clear that AI features first need to demonstrate real adoption and practical value before being considered for core, so all the work in this area continues in the AI plugin, with no guarantee of landing in 7.2. Among what’s cooking: more WordPress Abilities, including the first write abilities and not just read ones; an update to the MCP adapter to the latest spec, with plans to publish it as a regular plugin in the directory; MCP activation with minimal configuration directly from the AI plugin itself; experimentation with WebMCP in in-browser agent workflows; an identity and delegation model so agents get an auditable identity with permissions manageable independently from human accounts; site context and editorial guidelines reusable across different AI features; shared embeddings support for semantic search; and AI response streaming in the PHP client.

The roadmap highlights four concrete high-effort accessibility fronts: making admin dashboard notices announce properly to assistive technology and easier to dismiss by keyboard; introducing automated axe-core tests to prevent regressions; allowing metabox reordering to be fully disabled, which has long caused visual-complexity issues and accidental changes on mobile; and removing widgets accessibility mode, to reduce the number of distinct management modes that need maintaining.

A new Description List block arrives, made up of three static blocks that serialize to the 

One of the cycle’s more significant underlying changes: the extensible Site Editor is moving to a new foundation, built on the wordpress/boot routing package, already close to feature parity with the current editor. What matters here isn’t just the technical redesign, but that for the first time it’s opening up to third parties: a server-side view-configuration endpoint will let plugin authors register their own screens and settings inside the Site Editor itself, instead of having to build their own API from scratch every time. Other ongoing projects, like navigation editing, are already building on this foundation instead of duplicating work.

The DataViews and DataForms system keeps refining its extensibility, with view and form configuration registered on the server, and fields and actions also registerable there; as part of this, the post inspector itself — featured image, excerpt, status, date, author, or template — is being migrated to a DataForm, and help is already being requested to test that specific piece. The omnibar, introduced in 7.1, continues iterating with dashicons being replaced by SVG icons, command palette improvements, and ongoing accessibility review. And there’s a new round of improvements to error messages: clearer, easier to diagnose, and with a copy button to make them easy to search or share, following the defensive design principles Matt laid out a few weeks ago. The “On this day” widget also returns, having previously been attempted for 7.1 without success.

Form elements — buttons, text fields, dropdowns, and the previously missing label — will finally be stylable consistently straight from Global Styles, without touching theme.json by hand. The responsive styling introduced in 7.1 is being extended to more controls, with a public API so third-party blocks with custom controls can take advantage of it too. A custom “active” state can now be defined for interactive blocks, such as the current menu item in a navigation, starting with the Navigation Link block and the Tabs block. And, with renewed weight this time, the project to show Global Styles’ inherited styles directly in the block inspector is back — the feature that was shelved in 7.1 after several failed design attempts; now there’s the added question of whether to visibly indicate when a global value has been overridden locally, and how to offer a clear way to revert that change.

Client-side media processing, which debuted in 7.1, is now focused on maturing the system: hardening the upload process, expanding supported formats, and closing out pending performance work. The media inserter is being redesigned with very large media libraries in mind, with more sources for the dynamic gallery and sorting options for the static gallery. The 7.1 media-editing modal is focused on tracking the relationship between an original image and its crops, solving a real problem: today, each crop creates an independent attachment with no recorded link back to the original, which can end up filling the media library with loose duplicates. On performance, the focus is on removing script and style concatenation in favor of preloading, and on improved responsive images, with the Performance team’s Enhanced Responsive Images plugin available for anyone who wants to help test. And visual revisions, introduced in 7.0, keep being polished to make comparing and restoring changes smoother.

One deliberate, well-reasoned absence: real-time collaborative editing is not on the 7.2 roadmap, though work continues in parallel to the release cycle. The team acknowledges there are still important architectural decisions to resolve, and rather than list it here only to have to pull it later, as happened in previous cycles, they’d rather leave it out entirely for now.

While we wait for 7.2 to arrive, WordPress 7.1.1 is already here — the first maintenance release for 7.1. It brings 17 core fixes, 19 fixes in the block editor, and eleven security fixes, so it’s an update recommended immediately: the announcement itself stresses this, as is standard for any security release.

Among the fixed bugs are a stored XSS in wpautop() exploitable by a logged-out visitor via a comment pending approval; an issue in the HTML API that allowed escaping an HTML comment through abrupt closing sequences; a stored XSS in themes with custom-header support; specially crafted URLs that allowed an inactive theme to be automatically installed and previewed from WordPress.org; and an authenticated path traversal in the templates REST controller, reported once again by Anthropic.

The list continues with more heavyweight fixes: a site administrator could network-activate a network-only plugin without it being installed; XML-RPC allowed publishing customizer changes while bypassing the permission check for editing CSS; an arbitrary post overwrite by a Contributor, also reported by Anthropic; a missing permission check that leaked a private parent post’s title through attachment metadata; disclosure of a draft or pending post’s slug by a Contributor without proper authorization; and a bug that allowed any authenticated user to reassign a comment’s parent, notes included. As usual, the patches are being backported to every supported branch, from 4.7 through 7.0.

Gutenberg 24.0 is now available. The most practical addition is that visual revisions finally include the post title, which had been left out until now: seeing title changes alongside body-text changes avoids having to guess when something was renamed. The Gallery introduces a fully customizable grid variation replacing the old non-editable flexible layout, and both the column count and image cropping can be configured differently per device, so a gallery can show four columns on desktop and two on tablet without touching a line of CSS.

The Site Title gains a “fit-text” option, making the text scale to fill the available width instead of staying fixed at a set point size and either wrapping or falling short. Other highlights include a redesign of nearly a hundred icons toward a unified, stroke-based visual language, the ability to indent and outdent a full list item — or several selected at once — with Tab, background images that now accept a URL directly without having to go through the Media Library, and non-breaking spaces becoming visible while editing instead of staying invisible and silently changing the line break.

The Core team working on real-time collaborative editing has explained why the feature remains off the roadmap. The current design merges changes only in the browser, with no server involvement until someone saves, and that leaves three serious gaps: it doesn’t know who authored each change within a session, which could let unauthorized HTML slip in under someone else’s permissions; it can’t participate when an update comes in through the REST API or WP-CLI; and it can’t mediate when two people get out of sync, with a real risk of losing work.

The proposed solution is to make collaboration “server-aware”: instead of exchanging changes directly with each other, each person sends theirs to WordPress, which checks permissions, merges everyone’s changes, and resolves conflicts, rather than leaving it all up to the browser. The trade-off is more server load, so performance will need care, especially on more modest hosting.

There are three sync engines in testing, available as a plugin for anyone who wants to try them and give feedback: one based on the Yjs library, another using three-way merge that syncs only on save, and a third that logs short descriptions of each change instead of the full content.

The “AI-Powered WordPress” course is now live on Learn WordPress, designed to progressively walk through everything that has shipped with the canonical AI plugin since 7.0. It’s structured into four modules: the first three are aimed at anyone who manages or publishes on a WordPress site — owners, writers, editors, or administrators — with no coding required, covering everything from connecting your first AI provider via the Connectors screen, to using the editorial tools to draft, summarize, and classify content, automatically generating accessible alt text, moderating comments with sentiment and toxicity analysis, and controlling what AI is doing on the site through the request log and connector approvals.

The fourth module takes a leap into development, without assuming prior PHP experience, though it helps to have touched theme or plugin files before: it covers connecting assistants like Claude or ChatGPT to a site via the MCP adapter, registering a WordPress Ability so AI tools can discover a custom plugin’s functions, and using the WordPress AI Client to fire prompts from your own plugins and themes. The full course runs an estimated nine hours, requires a site running WordPress 7.0 or higher with admin access, and closes with a section on responsible best practices for publishing and building with AI in WordPress.

Fun anecdote: bbPress has jumped straight to 2.6.17, skipping 2.6.16, because John James Jacoby found a SQL bug right after tagging that version and chose to ship the fix without waiting. It’s another security and maintenance update. It hardens inherited visibility for private and hidden forums, BuddyPress group-forum limits, subscriber access checks, profile editing, REST API and XML-RPC requests, search results, canonical redirects, topic tags, moving replies, splitting topics, and output escaping in general.

The other major piece is a thorough overhaul of the maintenance and counter-repair tools — for topics, replies, forums, subforums, engagement, voices, and user contributions — which now behave better during moderation, moves, merges, splits, deletion, restoration, reassignment, and concurrent requests. Additionally, block themes now get first-class support while bbPress continues using its own PHP templates.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!

While WebMCP is still a proposed Internet standard, it’s already been integrated into WordPress Playground for use with the ChatGPT desktop app, which supports it.

Remember that you can listen this program from:

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from September 7 to 13, 2026.

The WordPress 7.2 Release Squad has now been formed, with Matt Mullenweg back as Release Lead following the call for volunteers. David Baumwald is coordinating the release, George Mamadashvili and Peter Wilson are the Tech Leads, and the team is rounded out by the triage and testing leads, plus the design and development leads for the new default theme, Twenty Twenty-Seven, headed by Henrique Iamarino on design and Maggie Cabrera and Carolina Nymark on development.

As has been the norm since 6.7, 7.2 keeps the small-squad model, relying heavily on each Make team’s representatives to coordinate work from within their own teams rather than centralizing everything in the release squad. Volunteer interest far exceeded the available slots, so anyone not selected this time can still contribute through testing, bug scrubs, triage, or documentation throughout the cycle — which is really where the bulk of each release’s workload shows up.

WordPress Playground now supports WebMCP, a standard still in draft stage that lets a web page expose actions directly as tools an AI agent can discover and use without leaving the browser. It’s a different approach from MCP, which connects to a local or remote server: WebMCP works inside the web page itself, with no intermediary. OpenAI has already added support for this in the built-in browser of the ChatGPT desktop app, under the name “Site tools,” so you can now also work with Playground by asking it in natural language to build a landing page or spin up a reproducible plugin demo.

The interesting technical challenge is that WordPress runs inside a nested iframe within the Playground page, and an agent that only looks at the top-level page can’t see the tools a plugin registers inside that WordPress instance. The solution is a WebMCP proxy that exposes tools registered inside the site to the outside and forwards calls back in, so that a plugin offering, say, an action to create an event draft becomes discoverable and usable by the agent without standing up a separate server.

The team has already tested several real-world workflows: building a complete tourism landing page from a single prompt, putting together a WordPress version-compatibility tracking dashboard with editable cards, and turning a plugin’s features into interactive demos that any visitor can try without installing anything.

The Plugins team has turned on an automated security review for every new release of any plugin in the directory, before it goes out through the update API. Until now, new plugins were reviewed before entering the directory, but subsequent updates went through no systematic check, so a plugin that was safe today could introduce a vulnerability or malicious code in any future version without anyone catching it in time. The specific trigger was a real incident: on July 28, a backdoor made it into an update for a plugin with roughly 20,000 active installs, which the automated review flagged and scored as high-risk, blocking its distribution before it reached any site — with the plugin fully closed 26 minutes later.

The mechanism builds on the six-hour quarantine period that’s existed since June for every plugin and theme update: during that window, several AI models analyze each release’s changes, cross-check results against one another to cut down on false positives, and assign a risk score. If it crosses the high-risk threshold, distribution is blocked automatically without depending on a team member being available at that moment, and all plugin authors are notified by email with the specific findings; a high score doesn’t imply malicious intent, since an unintentionally introduced vulnerability can score just as high as a deliberate attack.

The Community team has proposed setting up a joint educational sponsorship fund for WPCredits and WordPress Campus Connect students, intended as a standard package in the sponsor prospectus for the three flagship WordCamps: Asia, Europe, and US. Until now this has been handled case by case: WordCamp US 2025 hosted two Campus Connect students, and WordCamp Europe 2026 hosted five WPCredits students, with ratings of 8 to 10 out of 10 in the post-event impact report. The proposal aims to turn that ad hoc effort into a repeatable process, with a recommendation form filled out by organizers or mentors, and selection criteria focused on a track record of sustained contribution and the quality of the student’s WordPress profile.

The plan is to launch it first as a pilot at WordCamp Asia 2027, with a cohort of eight students, a funding goal of $30,000, and a minimum sponsor contribution of $3,000, before expanding it to Europe and the US if it goes well. Plenty of open questions remain: how to structure sponsorship into price tiers per slot, where to host a centralized, year-round interest link for sponsors instead of repeating the process for every event, what happens if only half the planned slots get funded, and the logistics of confirming funds with enough lead time for students to arrange flights and visas.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!

The icons that have displayed WordPress since version 3.8 appear set to disappear in WordPress 7.2, where they’ll be replaced with vector graphics.

Remember that you can listen this program from:

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from August 31 to September 6, 2026.

There’s now a schedule for the first maintenance release of the current version: WordPress 7.1.1 arrives September 17. The team itself acknowledges that the volume and severity of reports received in forums, Trac, and the Gutenberg repository since 7.1’s launch justify preparing this maintenance release with more advance notice than usual.

As is standard for these releases, 7.1.1 focuses exclusively on bug fixes: only tickets that are regressions introduced during the 7.1 cycle itself or features deliberately postponed to the end of that cycle get in — no new features.

Gutenberg 23.9 is also available, focused mainly on small day-to-day editing conveniences. You no longer have to hunt for the insert block button when it’s hidden: you can now add directly from the block’s own toolbar, so adding another image to a gallery or a new block inside a group no longer forces you to change selection or scroll to find it. Global Styles, for their part, gain a small indicator dot on each block that has a custom style override, with the option to filter and see at once only the blocks you’ve touched by hand, instead of having to review them one by one.

Among the other updates, independent horizontal and vertical spacing between elements stands out for the Group block with flexible or grid layout, the ability to customize form label styling from theme.json, and Global Styles support for blockquotes, input fields, and dropdowns. You can also add your own duotone color palette from the Global Styles panel itself, instead of relying only on those the theme offers. The rest are internal improvements for accessibility and performance, including noticeably faster block selection in long posts.

There’s a patch underway that replaces the Dashicons in the admin bar and sidebar menu with the new WordPress SVG icons, leveraging the new function that arrived with 7.1. The reason isn’t just aesthetic: icon fonts like Dashicons have several underlying problems. Screen readers announce them unpredictably, since they occupy Unicode code points with no defined meaning and sometimes read as a meaningless character in the middle of a sentence; they break with Windows high contrast mode and other forced color settings, because the system treats them as text; and when the font file fails to load or loads slowly, the result is boxes or strange symbols that look like a broken site, while an SVG simply doesn’t display if it fails.

The change is very visible to the user, so the team is explicitly requesting more feedback than it’s gotten so far on the ticket. A couple of details remain open: the search icon ends up facing the opposite direction from the Dashicon it replaces, and the Posts icon might stop being a pushpin in favor of a pen, though there’s already debate over which fits better.

Dashicons first appeared in WordPress 3.8 Parker, released December 12, 2013. They arrived alongside the admin redesign — the MP6 project — replacing the old icon sprites with a vector icon font, sharper at any resolution. The initial version included 167 icons; in WordPress 3.9 another 30 were added, reaching 197.

A group of contributors held an informal talk at WordCamp US, under Chatham House rules, about WordPress’s relationship with the PHP language and its community. The underlying diagnosis is well known: much of the PHP community doesn’t consider WordPress developers “real” PHP developers, partly because WordPress’s backward compatibility commitment is perceived as slowing PHP’s own evolution, and WordPress barely participates in discussions where new PHP features are decided. That same long compatibility window creates real friction in the plugin ecosystem, whose external dependencies no longer always support PHP versions as old as the ones WordPress still admits.

The data that weighs most heavily is adoption: PHP 7.4 still runs on roughly 18% of websites, with little recent incentive to update beyond security, since those old versions no longer receive patches. There was talk of pushing from the hosting side with a coordinated upgrade, of making PHP 8.x noticeably faster so speed becomes the weighty argument, and underlying concern about PHP 9: if it brings major syntax changes, it could become impossible to maintain a single WordPress version compatible with both PHP 7.4 and PHP 9.

The rest of the talk revolved around tightening ties with the PHP project: resuming the conversation about WebAssembly, which was once dismissed due to lack of interest but now makes more sense given WordPress’s existing use of WASM in Playground; bringing WordPress’s HTML API work to PHP, rather than keeping it internal only; and the idea — still at wish-list level — that plugins with unsafe dependencies could be loaded with restricted permissions, marking as untrusted any code depending on them. As concrete follow-up, there’s talk of reviewing whether the distribution of old WordPress versions itself has changed, and exploring sending automatic warnings to plugin developers when their code isn’t compatible with a given PHP version.

The Code Reference debuts truly executable code examples, powered by WordPress Playground: WordPress 7.1 already includes the first two, with more planned for 7.2. On reference pages there’s now a “Run” button that executes the code snippet directly in the browser, without leaving the documentation or setting up anything locally.

These interactive snippets are defined directly in each method’s DocBlock, within WordPress code itself, with syntax slightly different from a normal code example. The team promises to publish soon a handbook page with all the details for anyone wanting to document their own functions with this same format.

It’s time to update forums with bbPress because version 2.6.15 fixes five security flaws and several compatibility improvements. The patches strengthen permissions when editing topics and replies, splitting or merging topics, updating user profiles, and viewing private or hidden forums; password verification for imports from other systems is also hardened and PHP warnings are fixed in some forum requests. One of the flaws has its own CVE.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!

WordPress is working on an encryption system for credentials stored in the system, both for connector APIs and those used by other plugins and tools.

Remember that you can listen this program from:

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from August 24 to 30, 2026.

The community has received a proposal of major scope for WordPress 7.2: a Secrets API, the first native way to store a credential in WordPress. Today, any plugin that needs to store an API key writes it in plain text in the options table, which means it ends up in every backup, every staging clone, and every shared terminal; with the arrival of AI services with pay-per-use key pricing, losing a credential this way has stopped being a minor problem. The proposal presents simple functions with mandatory encryption and no option to disable it, with no filter that can intercept a plain-text secret when retrieving it, and with support from day one for WP-CLI — specifically to prevent credentials from being exposed in terminal history.

The work plan is somewhat unusual: before touching core, it will be published as a standalone plugin so the community can test it on real sites, and only afterward will the core patch arrive with an API identical to the plugin’s, deliberately postponing the admin interface to 7.3 to avoid rushing an important design decision.

The proposal has already generated serious technical debate in the comments, especially from managed hosting people explaining that their external secret stores are read-only from WordPress and encryption has to be handled in their external HSM, not inside WordPress — something the current proposal doesn’t handle well because it assumes the storage provider never receives the secret in plain text. Feedback is still being actively sought, and everything points to the final design moving considerably from this first version before reaching a real patch.

The AI team confirms data that connects directly to this: the Secrets API for 7.2 has already been tested beforehand, essentially because it’s the same one that’s been running as a key encryption experiment inside the AI plugin for months. The team has formally aligned in favor of bringing it to core in 7.2, though they’re asking that documentation include an easy way to detect if the function is available, to allow cleanly migrating old code with plain-text secrets.

The Security team has announced the Core Security Initiative, a coordinated effort that also explains something we’ve been seeing these past weeks: the avalanche of security patches in the 7.0 series. According to the team itself, the volume of security reports has grown massively in the past year, largely because more advanced AI models make analyzing code for vulnerabilities increasingly accessible — something happening across the entire software ecosystem, not just WordPress. Which is, they say, a good problem: more eyes on the code makes WordPress more secure, but forces scaling how those reports are classified, validated, and resolved.

The initiative leans on three fronts. The first is a more solid and automated release process, with better end-to-end tests, so security patches ship reliably and predictably. The second is reducing the backlog of open reports, by adding more people to the team and volunteers, with the stated goal of reaching zero pending issues. The third is using AI itself to proactively hunt for vulnerabilities before someone exploits them, as a complement to reports coming through responsible disclosure.

WordPress Playground has become something considerably more ambitious than a simple sandbox: it now allows launching any historical version of WordPress in the browser, from 0.7 through 6.2, long before the block editor or REST API existed. The update activates with a new “Include older versions” checkbox in the settings panel, and underneath does fairly sophisticated work: for WordPress 0.7 to 4.9 it uses a PHP 5.2.17 WebAssembly build, while from 5.0 to 6.2 it pins PHP 7.4, because those intermediate versions behave more reliably there than on modern PHP. The selector even shows each version’s codename, so testing WordPress 2.8 “Baker” is as simple as picking it from a dropdown.

The practical utility is clear for anyone developing plugins or themes: reproducing a client’s compatibility report who’s still on WordPress 4.9, actually checking what breaks before deciding to drop support for an old version, or comparing how the classic editor behaved versus the block editor without having to maintain a separate VM with old PHP and a separate database.

A group of contributors is building the Meetup.com alternative for WordPress community groups, based on the GatherPress plugin, and are already asking for help testing it on Events.WordPress.org. The idea is that each group has its own site where people can join and confirm attendance at events, with organizers managing everything from the public side, without going through the admin dashboard. To test it, just log into the test group with a WordPress account, at which point you automatically become a “Member”; there are two other roles with more permissions, “Event Organizer” and “Organizer,” also accessible from the members page itself for anyone wanting to test those views.

The team explicitly asks for a first general impression rather than an exhaustive bug report: joining a group, confirming attendance at an event, seeing sponsors and members, and especially comparing the experience with Meetup to detect what someone used to that platform would miss. The first comments have already surfaced several interesting gaps: the event description editor is much more limited than the usual block editor, the event’s timezone doesn’t display — important for online events with people in multiple countries — and at least one case where leaving a group doesn’t correctly remove the already-saved attendance confirmation for an event. There are also requests for a Spanish-language test site, since the Meta translation team and WordCamp are already working on the new text strings.

WordPress has signed the open letter “Open Weights and American AI Leadership,” which calls on U.S. policymakers not to impose early restrictions on open-weight AI models — the ones anyone can download, inspect, modify, and run on their own infrastructure. The letter was published July 24 and already has over 270 company and organization signatories; the underlying argument is the same that anyone familiar with open source will instantly recognize: technology improves and is more secure the more people can study it and build on it.

Mary Hubbard, WordPress’s CEO, frames the signature precisely in that twenty-year philosophy of the project itself: people who use a technology should be able to shape it to their liking, and open-weight models extend that same freedom to the AI realm. Among the letter’s specific requests to lawmakers are expanding access to computing capacity for startups and researchers, investing in shared resources like public datasets and evaluation tools, maintaining more than one type of model available rather than shrinking the field to a handful of closed systems, and not treating as theft by default common practices like using one model’s output to improve another.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!