BU BÖLÜM HAKKINDA
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.
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!
