WordPress Podcast (English)

Since December 2022, security updates were provided from version 4.1 onwards, but now only version 4.7 and above will receive security updates.

Remember that you can listen to this program from Pocket Casts, Spotify, and Apple Podcasts or subscribe to the feed directly.

Program transcript

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 June 16th to 22nd, 2025.

It was back in December 2022 when WordPress announced it would cease providing retroactive security support for versions 3.7 through 4.0. Two and a half years later, the minimum version receiving these security backports will be 4.7.

Officially, only the latest WordPress version—currently WordPress 6.8—is supported, yet the Security Team makes an effort to apply security patches to older versions as well. Specifically, if a security issue is discovered, they apply the patch without altering anything else.

This means approximately 20 to 25 unsupported WordPress versions receive these updates, keeping the web safer.

However, currently nearly 90% of sites run WordPress 6.0 or higher, and over 95% use WordPress 5.0 or newer, which implies maintaining older versions amounts to maintaining ghost sites that have likely been forgotten.

Remember, to keep your site secure and compatible, it’s always best to use one of the latest three major WordPress versions.

Speaking of WordPress versions, WordPress 6.8.2 is approaching, with a tentative release date set for Tuesday, July 15th. Over the next three weeks, reviews will occur to incorporate proposed improvements; on July 8th, a Release Candidate will finalize the changes, and the new minor version should be launched on the 15th.

Around 20 core tickets and 10 editor tickets are scheduled to be included in this version.

During WordCamp Europe 2025, a WP Café was held with a central theme: Five for the Future. Among everything discussed during those hours, a summary has been published with a strategic and proactive tone: it begins with a deep analysis of “Five for the Future,” and calls on various community stakeholders—from volunteers to sponsors—to completely redefine what counts as contributions beyond code, ensuring sustainability, inclusive recognition, transparent governance, and standardized team processes.

There’s an insistence on replacing the ambiguous 5% commitment with a clear framework covering education, event organization, mentorship, moderation, translation, documentation creation, and infrastructure support; also proposed are streamlined communications with summaries and applying rigorous measurement theories to avoid conflicting interpretations.

The summary emphasizes consensus around addressing burnout with fair funding mechanisms (scholarships, stipends, or grants) and reactivating the Sustainability Team; boosting reliable metrics and dashboards (Contributor Dashboard and Bitergia) for accountability; structuring contributor onboarding and offboarding processes; and leveraging AI to synthesize scattered knowledge without dehumanizing interactions.

In the comments, Mary Hubbard, executive director of the WordPress project, reaffirms these key points: clearly defining contribution criteria including non-technical work, redesigning the recognition system with badges and concrete metrics, monitoring real contributions with data tools, documenting onboarding and offboarding of teams, and fostering decentralized contributor autonomy. Generally, the spirit of “ask forgiveness rather than permission” is encouraged, and clear deadlines for delivery are proposed for the third quarter.

The Plugins team is proposing blocking plugin updates when unacceptable code is detected, such as Freemius premium versions, which are incompatible with WordPress licenses.

Thus, when patterns known to be incompatible are detected, uploads to the repository will automatically be blocked, returning a message explaining the reason.

The Polyglots team proposes a transparent, step-by-step workflow for handling low-quality translation contributions that create extra burden for volunteer validators. First, a reviewer contacts the translator via the integrated discussion tool, offering guidance; if there’s no response or improvement within a few days, the translator receives a public notification in the #polyglots Slack channel; if there is still no reaction, the case gets documented with screenshots and links on the Polyglots blog tagged #block-spammer; finally, if poor submissions continue, a temporary suspension of translation rights is applied via a custom plugin, accompanied by a user notification linking to an explanatory post.

However, some concerns have emerged: how to clearly define what constitutes “low quality,” meaning the number of errors, inaccuracy percentage, or style guide violations; also, how many validators must endorse the measure and how many errors justify the initial alert; ensuring platform notifications are enabled by default; trusting the judgment of project editors (PTE) and general editors (GTE); and perhaps renaming the label to something less punitive.

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!