ABOUT THIS EPISODE
Connecting remotely to WordPress from your artificial intelligence tool can now be done natively with the MCP Adapter plugin.
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 <script> and <style> elements are removed along with their content instead of leaving loose code on screen, and incomplete fragments are trimmed before the ambiguous point.
In the database, WordPress 7.2 adds NO_BACKSLASH_ESCAPES to the list of unsupported SQL modes. With that mode active, MySQL treats the backslash as a normal character, and queries with escaped values can fail or return wrong data. Some hosts enable it, and it caused problems that were very hard to trace. From now on, when connecting, WordPress turns it off for the session only, without touching the server’s global configuration, and most sites won’t notice anything.
The third change is smaller: there is a proposal to update the core CSS coding standards so that Stylelint, already used in Gutenberg, can be integrated and enforce them automatically. The two relevant changes are: a single blank line between sections and blocks, since the current rule doesn’t distinguish between the two cases; and avoiding the order property and reverse values.
The AI 1.4.0 plugin is now available. The most eye-catching addition is the Markdown feeds experiment: when enabled, the site offers a Markdown version of its content at /feed/markdown/, and any post or page can also be requested in that format, aimed at AI agents and tools that work better with Markdown than with rendered HTML. Comment moderation adds a value score, from 0 to 1, measuring how much a comment contributes to the post where it’s published, as an additional signal alongside toxicity and sentiment: a comment can be perfectly polite and say nothing. In addition, content translation adds nine target languages and lets you retry a failed translation without restarting the workflow, and alt text generation now respects the decorative image checkbox in the Image block.
For version 1.5.0, text-to-speech, internal link suggestions, integration with the Gutenberg media editor, role- and user-based access control, and content traceability with C2PA are announced, along with write abilities for content, users, terms, and media, in line with the CRUD pattern discussed for 7.2.
The MCP Adapter, the component that translates WordPress Abilities into the MCP protocol so assistants like Claude or ChatGPT can discover and use them, finally arrives in the WordPress.org plugin directory with version 0.7.0.
Until now you had to download it from GitHub or bundle it as a Composer dependency, which put it out of reach for most users and forced each plugin to manage its own copies and conflicts. Once installed, it provides a default MCP server with three basic tools, automatically exposes any public Ability on the site, and lets developers create their own servers with custom tools, resources, and prompts. That said, it only provides the server infrastructure: it doesn’t include an MCP client or an interface for a complete end-to-end agentic workflow.
The most revealing part is the reasoning behind why it remains a plugin and doesn’t go into core: the MCP specification is still changing, with a major update that broke compatibility less than three months ago, and that clashes with the schedule of mass distribution and WordPress’s backward-compatibility promise. As a canonical plugin, it can move at the pace of the protocol, and other plugins can depend on it without duplicate or outdated copies, thanks to plugin dependencies and automatic installation. Version 0.7.0 adds support for the new stateless specification from July 2026, while keeping clients connected to earlier versions. The team itself still labels it experimental, with the goal of reaching a stable 1.0 based on developer feedback.
The Accessibility team has changed course on the accessibility-ready themes issue we’ve been following. It has been announced that the work to make the tag conditional in the theme directory is nearly finished. What matters for theme publishers is that no theme will be removed from the directory for failing to meet the requirements anymore, that there will be no approval delays for requesting the tag, and that requesting it will now be treated as a request to be listed in the corresponding listing. Some configuration work remains, so applying the changes to which themes appear under the tag is delayed a bit.
It’s a fairly different outcome from the October 1 threat the team had raised in July, and it matches the solution already sketched in the comments on that post: making the tag depend on an approval recorded in the directory and not only on the theme’s style.css, so the team can remove it directly without having to pull the entire theme. The team itself sells this as a trust gain: since they’ll be able to remove the tag from anyone who doesn’t comply, its value as a reliability signal goes up considerably.
The Community team raises an everyday problem: when an event ends, its website freezes, with a schedule of past dates, a buy-ticket button that no longer works, and a countdown stuck at zero, just when more people may come looking for information. The proposal, valid for WordCamps, Campus Connect, or any WordPress event, is to turn the website into a closing page without rebuilding it from scratch, reorganizing the content to shift from announcing the event to recounting what happened and inviting people to keep participating.
The approach has four parts: photos linking to the full gallery, with credit to each photographer and the reuse license; talks with title, speaker, PDF slides, and a link to WordPress.tv, publishing the slides first and adding the videos when they’re ready; a clearly visible call to action to join the local meetup, perhaps the most important part, since someone visiting the website after the event has already shown interest; and a section with recaps, testimonials, and articles written about the event.
It’s being put into practice on the website for WordCamp Costa Rica 2026, held September 18 and 19 and still being transformed, and they propose adding this task to the post-event checklist. The benefits range from keeping the website useful for months and recognizing speakers, photographers, and volunteers, to creating an archive for the next organizing team and showing future sponsors what the event achieved.
On another front, there’s a proposal to give a stable framework to something that has already worked three times: having students take part in the major WordCamps. It started as an experiment at WordCamp US 2025, gained momentum at WordCamp Asia 2026, and reached its milestone at WordCamp Europe 2026, where students from two universities and a secondary school in Kraków took the stage to present the websites they had built over the year. A sponsorship tier was also introduced there so WPCredits graduates could attend, and their impact went beyond the session room: they volunteered, took part in Contributor Day, shared their experience in a session, and left wanting more. The underlying argument is about a funnel: every student who builds a site or presents their work is a future contributor, organizer, or plugin author.
The proposal is a lightweight, repeatable framework, to be piloted in 2027 starting with WordCamp Asia, with four components: one or two people from each organizing team who act as a liaison with Education; one to three slots reserved in the program, with no fixed format, from main stage to workshop or Contributor Day; sponsorship or travel assistance pathways, because getting there remains the biggest barrier for students from other countries; and flexible deadlines, since academic calendars don’t line up with a speaker call schedule.
A few common metrics are also proposed, such as number of students, participation in Contributor Day, and how many remain involved at three or six months. The proposal also asks local WordCamps to adopt it, since they’re usually the first point of entry.
BuddyPress 15.0 is delayed until January 19, 2027. The release has taken longer than expected, and dates had already been moved before: WordPress 7.2 is scheduled for December 8-10, so this leaves room to test BuddyPress against its stable version without the final release falling in the middle of the holidays. The plan is a beta on December 15, with feature freeze, and a release candidate on January 5, with string freeze, leaving three weeks between the two because of the holidays. It’s the starting point, not a limit: if testing calls for it, there will be another beta or another RC, and the dates are targets, not guarantees.
The most important piece of this release is version 2 of the REST API, and the team wants developers to have time to understand the changes before testing the beta. The idea is to publish a week earlier, on December 8, an introduction to the API, a notice of deprecated features, and a guide for those using the standalone BP REST API plugin. They do warn that unfinished documentation won’t block the release. WP-CLI compatibility and other team integrations will also be reviewed before the final version.
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!
