Title: John Blackbourn – Make WordPress Core

---

#  Author Archives: 󠀁[John Blackbourn](https://profiles.wordpress.org/johnbillion/)󠁿

 [  ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/)
6:39 pm _on_ May 22, 2026     
Tags: [PHP ( 78 )](https://make.wordpress.org/core/tag/php/),
[PHP 8.0 ( 6 )](https://make.wordpress.org/core/tag/php-8-0/), [php-compatibility ( 5 )](https://make.wordpress.org/core/tag/php-compatibility/)

# 󠀁[PHP support clarification, spring 2026 edition](https://make.wordpress.org/core/2026/05/22/php-support-clarification-2026/)󠁿

**tl;dr:** Use of the “betaBeta A pre-release of software that is given out to a
large group of users to trial under real conditions. Beta versions have gone through
alpha testing in-house and are generally fairly close in look, feel and function
to the final product; however, design changes often occur as part of the process.”
label for PHPPHP The web scripting language in which WordPress is primarily architected.
WordPress requires PHP 7.4 or higher support has been retired and has been retroactively
removed from all versions.

 * WordPress 6.9 and 7.0 are now documented as fully supporting PHP 8.5
 * WordPress 6.8 and later are now documented as fully supporting PHP 8.4
 * WordPress 6.4 and later are now documented as fully supporting PHP 8.3

Due to the acknowledgement that WordPress is rarely used in isolation (without any
theme or plugins), support for each version of PHP 8 has [up until now been labelled as “beta”](https://make.wordpress.org/core/2020/11/23/wordpress-and-php-8-0/)
until its usage surpasses 10% on any given version of WordPress.

Since version 8.0, the PHP team has regularly shipped stable updates in the 8.x 
series. This means the work required to make plugins and themes compatible with 
the newer versions is much lower, and as such use of the “beta” label has been retired.
The label has been removed retroactively from all versions. This will provide clarity
and confidence to users, and encourages web hosts, developers, and users to continue
updating to the latest versions of PHP.

Refer to the handbook page for documentation on [PHP compatibility and WordPress versions](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/).

## What prompted this change?

[The criteria for removing the “beta support” label from any given version of WordPress](https://make.wordpress.org/core/2023/06/20/proposal-criteria-for-removing-beta-support-from-each-php-8-version/)
were adopted in 2023 after remaining PHP compatibility issues were resolved. [Use of the “compatible with exceptions” label was retired in April last year](https://make.wordpress.org/core/2025/04/09/php-8-support-clarification/)
and the number and significance of reported compatibility exceptions remains extremely
low.

Additionally it’s become apparent that the “beta” label has made some end users 
and web hosts reluctant to update to newer versions of PHP, and caused some developers
of plugins and themes to delay testing and supporting newer versions of PHP.

This label has served its purpose over the years, but can now be retired in order
to continue increasing the adoption of newer versions of PHP throughout the ecosystem.

## What’s the minimum supported PHP version?

The minimum _recommended_ PHP version remains at 8.3. The minimum _supported_ PHP
version is 7.4 since WordPress 7.0. See [the Requirements page](https://wordpress.org/about/requirements/)
for all the info.

## How and why should I update PHP?

Keeping PHP up to date on your web server ensures your websites remain as performant
and secure as possible. Read [the guide to updating PHP](https://wordpress.org/support/update-php/).

_Props to [@garyj](https://profiles.wordpress.org/garyj/) [@westonruter](https://profiles.wordpress.org/westonruter/)
and [@jorbin](https://profiles.wordpress.org/jorbin/) for pre-publishing feedback._

[#php](https://make.wordpress.org/core/tag/php/), [#php-8-0](https://make.wordpress.org/core/tag/php-8-0/),
[#php-compatibility](https://make.wordpress.org/core/tag/php-compatibility/)

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcore%2F2026%2F05%2F22%2Fphp-support-clarification-2026%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/)
2:00 am _on_ March 25, 2026      

# 󠀁[WordPress 6.9.2 retrospective](https://make.wordpress.org/core/2026/03/25/wordpress-6-9-2-retrospective/)󠁿

The WordPress 6.9.2 release on March 10th wasn’t the smoothest, so some members 
of the Security Team did an internal retrospective to identify how the project can
continue to improve release processes, with the aim of ensuring that users continue
to have trust in minor releases. Here’s an overview of what went well, what didn’t
go so well, and all the action points as a result.

## 6.9.2

The Security Team decided on a plan to fully ship 6.9.2 prior to starting the backports
that are provided as a courtesy to older branches. Normally the commits to trunktrunk
A directory in Subversion containing the latest development code in preparation 
for the next major release cycle. If you are running "trunk", then you are on the
latest revision., the currently supported branchbranch A directory in Subversion.
WordPress uses branches to store the latest development code for each major release(
3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that
branch. Sometimes, a major version of WordPress and its minor versions are collectively
referred to as a "branch", such as "the 4.0 branch"., and relevant backportbackport
A port is when code from one branch (or trunk) is merged into another branch or 
trunk. Some changes in WordPress point releases are the result of backporting code
from trunk to the release branch. branches are all completed before the release 
process starts, but this increases the time to release the supported branch and 
greatly increases the time pressure on the team.

The team agreed that it was a good idea to handle trunk and 6.9 prior to committing
the backports, that the approach worked well, and that it facilitated shipping 6.9.2
as fast as possible.

## 6.9.3

Shortly after the release, [an issue in 6.9.2 was reported on the support forums](https://wordpress.org/support/topic/no-pages-displaying-after-wp-updates-to-6-9-2/)
that affected classic themes using an unusual approach to template loading. The 
team paused the backport work to investigate, and decided that it warranted a fast-
follow 6.9.3 release out of an abundance of caution.

The fix was shipped in 6.9.3, around eight hours after 6.9.2.

## 7.0 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 4

It’s uncommon for a security release of WordPress to ship during the beta period
of the next major releasemajor release A release, identified by the first two numbers(
3.6), which is the focus of a full release cycle and feature development. WordPress
uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are 
sequential and comparable in scope.. This is not intentional, the situation simply
doesn’t arise often. In the twenty year history of WordPress it appears to have 
happened three times previously (3.9.2, 4.0.1, and 6.3.2).

Shortly after the release of 6.9.2, several community members asked if a new beta
of WordPress 7.0 would be released containing the security fixes. This was not originally
planned but of course makes sense, as the project should encourage as many people
as possible to test beta releases and not leave them on a known insecure version
until the next scheduled beta.

As a result, WordPress 7.0 beta 4 was released at the same time as 6.9.3 and included
both the security fixes from 6.9.2 and the template loading fix from 6.9.3.

## 6.9.4

Around twenty hours after 6.9.2 was released, the Security Team received a report
that some of the fixes listed in the release announcement for 6.9.2 were missing
from the package. The team quickly determined that three of the ten commits that
were made to trunk did not get successfully merged into the 6.9 branch and were 
missing from the package as a result.

The merge commits were missed due to human error, but the problem should have been
easily caught by the release process. There is no step in the minor releaseMinor
Release A set of releases or versions having the same minor version number may be
collectively referred to as .x , for example version 5.2.x to refer to versions 
5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that
software. Minor Releases often make improvements to existing features and functionality.
process to independently double check that all commits were successfully merged 
into the active branch. Sounds obvious in hindsight, but it’s a checklist oversight
that’s never been spotted.

## Backports

Officially only the latest version of WordPress is supported. The Security Team 
historically has a practice of backporting security fixes, as necessary, as a courtesy
to sites on older versions in the expectation the sites will be automatically updated.

Backporting the fixes from 6.9.2/6.9.3 to 22 older branches proved to be very time
consuming. While several of the branches were ready ahead of time, several were 
still being worked on close to release.

 * Backports back to 6.4 were completed by end of day on Tuesday March 10th.
 * Backports back to 5.3 were completed by end of day on Wednesday March 11th, mainly
   due to time constraints from contributors.
 * Remaining backports were blocked by a bugbug A bug is an error or unexpected 
   result. Performance improvements, code optimization, and are considered enhancements,
   not defects. After feature freeze, only bugs are dealt with, with regressions(
   adverse changes from the previous version) being the highest priority. with the
   wordpress.orgWordPress.org The community site where WordPress code is created
   and shared by the users. This is where you can download the source code for WordPress
   core, plugins and themes as well as the central location for community conversations
   and organization. [https://wordpress.org/](https://wordpress.org/) svn server
   pre-commit hook that prevented pushing to the 5.2 branch and earlier, and issues
   with branches not syncing to the build server. The wordpress.org systems team
   members applied several fixes, and backports back to 4.7 were released by end
   of day on Friday March 13th.
 * The 6.0 branch (which will be version 6.0.12) remains _unreleased_ due to [an unresolved issue with the build](https://make.wordpress.org/systems/2026/03/09/ref-https-core-trac-wordpress-org-ticket-64083comment61-a-commit-was/).
   At the time of writing this branch remains unprotected.

Backporting security fixes to a large number of branches (22 at the time of writing)
continues to be a source of contention between the security team and project leadership.
While the effort required from the security team to backport fixes to a branch is
generally proportional to the age of the branch, the bulk of the work is actually
taken up by the human processes that are needed to manage such a large number of
branch releases. The team are in the planning stages of some work to increase automation
and streamline the backporting processes so time from human contributors can be 
better spent elsewhere.

## Action points

As a result of the issues with 6.9.2, its fast-follow releases, 7.0 beta 4, and 
backporting, the security team and coreCore Core is the set of software required
to run WordPress. The Core Development Team builds WordPress. team have some action
points that will be addressed in the coming days and weeks:

 * Add unit testunit test Code written to test a small piece of code or functionality
   within a larger application. Everything from themes to WordPress core have a 
   series of unit tests. Also see [regression](https://make.wordpress.org/core/author/johnbillion/?output_format=md#regression).
   coverage for handling stringable objects in the `template_include` filterFilter
   Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/Hooks](https://codex.wordpress.org/Plugin_API/Hooks).
   They provide a way for functions to modify data of other functions. They are 
   the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated
   manner, and should never have side effects such as affecting global variables
   and output. that was addressed in 6.9.3. While this is not strictly supported,
   the otherwise full front end breakage that can occur means we’re essentially 
   locked in to supporting it now.
 * Update minor release checklist page to:
    - Add info about double verification of merge commits
    - Update the TTL adjustment to be a requirement instead of a nice to have
    - Remove outdated noise from the checklist, including codex changes
    - As a general rule, there should be no reason to skip a step unless it’s clearly
      documented why that might happen
    - Add planning info about releasing a minor during a beta or RCrelease candidate
      One of the final stages in the version release cycle, this version signals
      the potential to be a final release to the public. Also see [alpha (beta)](https://make.wordpress.org/core/author/johnbillion/?output_format=md#alpha-beta).
      phase
    - Before bumping versions and performing a tagging commit, the built asset on
      the Test Build Processes workflow should be used to confirm things work as
      expected.
 * Backport related Build/Test Tool changes to older branches.
    - Ensure PHPUnit reports notices and warnings as exceptions.
    - Ensure all local environment scripts have `catch()` mechanisms in place.
 * Create ways to make it easier to test built assets on the Test Build Processes
   workflow.
    - Playground supports testing this asset from a pull request but not an individual
      commit.
    - A script could be created to download the built asset and extract the zip 
      file into the `build` directory locally for testing.

Longer term, Matt Mullenweg has asked what AI-assisted tooling can be used to review
changes going into releases in order to assess risk of breakage, generally assist
with review, and improve quality control. This is a wider concern not specific to
security releases. Hopefully we’ll hear more about that in due course.

_Thanks to [@peterwilsoncc](https://profiles.wordpress.org/peterwilsoncc/), [@dmsnell](https://profiles.wordpress.org/dmsnell/),
[@audrasjb](https://profiles.wordpress.org/audrasjb/), and [@sergeybiryukov](https://profiles.wordpress.org/sergeybiryukov/)
for reviewing this post prior to publishing._

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcore%2F2026%2F03%2F25%2Fwordpress-6-9-2-retrospective%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/)
9:24 pm _on_ January 9, 2026     
Tags: [7.0 ( 71 )](https://make.wordpress.org/core/tag/7-0/),
[dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), [dev-notes-7-0 ( 22 )](https://make.wordpress.org/core/tag/dev-notes-7-0/),
[PHP ( 78 )](https://make.wordpress.org/core/tag/php/)   

# 󠀁[Dropping support for PHP 7.2 and 7.3](https://make.wordpress.org/core/2026/01/09/dropping-support-for-php-7-2-and-7-3/)󠁿

Support for PHPPHP The web scripting language in which WordPress is primarily architected.
WordPress requires PHP 7.4 or higher 7.2 and 7.3 will be dropped in [WordPress 7.0, currently scheduled for release in April 2026](https://make.wordpress.org/core/7-0/).
The _minimum recommended version_ of PHP will remain at 8.3, but the new _minimum
supported version_ of PHP will be 7.4.0.

The minimum supported version of PHP was last raised in July 2024 to 7.2.24. Since
then usage of PHP 7.2 and 7.3 has dropped [below 4% of monitored WordPress installations](https://wordpress.org/about/stats/).

Historically, the project has used 5% as the baseline usage percentage that a PHP
version must fall below before it can be considered for a well-earned retirement.
Now that usage of PHP 7.2 and 7.3 combined has fallen well below that, the process
to increase the minimum supported PHP version can proceed.

The goal of increasing the minimum supported version of PHP is to ensure the long-
term maintainability of WordPress. The benefits to increasing the minimum supported
PHP version manifest over time across multiple areas, including the pluginPlugin
A plugin is a piece of software containing a group of functions that can be added
to a WordPress website. They can extend functionality or add new features to your
WordPress websites. WordPress plugins are written in the PHP programming language
and integrate seamlessly with WordPress. These can be free in the WordPress.org 
Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. and theme ecosystem, tooling and
libraries for AI, the long-term perception of the WordPress project, developer relations,
and eventually within the WordPress codebase itself, including its developer tooling
and automated testing infrastructure.

[Discussion around this minimum version bump can be found here on the Trac ticket](https://core.trac.wordpress.org/ticket/62622).

## What about PHP 8 and higher?

WordPress coreCore Core is the set of software required to run WordPress. The Core
Development Team builds WordPress. is fully compatible with PHP 8.0 to 8.3 and is
[beta compatible](https://make.wordpress.org/core/2025/04/09/php-8-support-clarification/)
with PHP 8.4 and 8.5.

[A full breakdown of which PHP versions are compatible with each version of WordPress can be found in the WordPress Core Handbook.](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/).

## What about security support?

Sites that are running PHP 7.2 or 7.3 will remain on the 6.9 branchbranch A directory
in Subversion. WordPress uses branches to store the latest development code for 
each major release (3.9, 4.0, etc.). Branches are then updated with code for any
minor releases of that branch. Sometimes, a major version of WordPress and its minor
versions are collectively referred to as a "branch", such as "the 4.0 branch". of
WordPress once 7.0 is released. While only one branch officially receives security
updates, [fixes are backported down to WordPress 4.7 as a courtesy when possible](https://make.wordpress.org/security/2025/06/18/security-updates-will-cease-for-wordpress-versions-4-1-through-4-6/).

## What about the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. 󠀁[https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/)󠁿 plugin?

[The minimum supported version of PHP will also be increased to 7.4 in the Gutenberg plugin](https://github.com/WordPress/gutenberg/issues/74456).

## Going forward

There are no plans to bump the minimum supported PHP version on a set schedule. 
The Core team will continue to monitor PHP version usage and work with the Hosting
team to encourage users and hosting companies to upgrade their versions of PHP as
swiftly as possible. The 5% usage threshold will continue to be used as the standard
for the foreseeable future.

[At the time of publishing, the PHP version usage is as follows:](https://wordpress.org/about/stats/)

 * 8.5: 0.23%
 * 8.4: 4.90%
 * 8.3: 16.74%
 * 8.2: 27.29%
 * 8.1: 15.39%
 * 8.0: 5.69%
 * 7.4: 22.20%
 * 7.3: 2.04%
 * 7.2: 1.81%

## Update PHP today

If you need more information about PHP or how to update it, [check out this support article that explains more, guides you through the process, and provides instructions for contacting your web hosting provider for assistance](https://wordpress.org/support/update-php/).

_Props to all those that have contributed to this discussion recently. Thanks to
[@desrosj](https://profiles.wordpress.org/desrosj/), [@westonruter](https://profiles.wordpress.org/westonruter/),
and [@jorbin](https://profiles.wordpress.org/jorbin/) for feedback and proof-reading
this post_.

[#7-0](https://make.wordpress.org/core/tag/7-0/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/),
[#dev-notes-7-0](https://make.wordpress.org/core/tag/dev-notes-7-0/), [#php](https://make.wordpress.org/core/tag/php/)

 [  ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/)
3:38 pm _on_ November 21, 2025     
Tags: [6-9 ( 87 )](https://make.wordpress.org/core/tag/6-9/),
[dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), [dev-notes-6-9 ( 25 )](https://make.wordpress.org/core/tag/dev-notes-6-9/),
[php-compatibility ( 5 )](https://make.wordpress.org/core/tag/php-compatibility/)

# 󠀁[PHP 8.5 support in WordPress 6.9](https://make.wordpress.org/core/2025/11/21/php-8-5-support-in-wordpress-6-9/)󠁿

[PHP 8.5 was released on November 20th](https://www.php.net/archive/2025.php#2025-11-20-3).
Contributors to WordPress have been busy in recent months preparing for this version
and we’re happy to report that all issues reported against PHPPHP The web scripting
language in which WordPress is primarily architected. WordPress requires PHP 7.4
or higher 8.5 have been addressed in WordPress 6.9 RC2. Compared to previous PHP
releases relatively few changes were required, mostly to address new deprecations
and warnings. Take a look at [the PHP 8.5 support tracking ticket](https://core.trac.wordpress.org/ticket/63061)
if you’re interested.

> Due to the acknowledgement that WordPress is rarely used in isolation (without
> any theme or plugins), support is labelled as “betaBeta A pre-release of software
> that is given out to a large group of users to trial under real conditions. Beta
> versions have gone through alpha testing in-house and are generally fairly close
> in look, feel and function to the final product; however, design changes often
> occur as part of the process. support” until at least 10% of all WordPress sites
> are running that version or later, as this indicates good compatibility across
> the wider ecosystem of plugins and themes.
> _[PHP Compatibility and WordPress Versions page in the WordPress Core Handbook](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/)_

Following the established guidelines, support for any given version of PHP is labelled
as “beta support” until at least 10% of all WordPress sites are running that version
or later. When WordPress 6.9 ships on December 2nd, support for PHP 8.5 and 8.4 
will be labelled as “beta support”. PHP versions 8.3 back to 7.2 are fully supported.

If you discover a bugbug A bug is an error or unexpected result. Performance improvements,
code optimization, and are considered enhancements, not defects. After feature freeze,
only bugs are dealt with, with regressions (adverse changes from the previous version)
being the highest priority. or compatibility issue while running WordPress with 
PHP 8.5, [please create a ticket on Trac](https://core.trac.wordpress.org/newticket?keywords=php85).

## Summary

As always, reading through the [complete upgrade document](https://github.com/php/php-src/blob/PHP-8.5/UPGRADING)
is recommended.

Even as WordPress CoreCore Core is the set of software required to run WordPress.
The Core Development Team builds WordPress. continues to expand its support for 
new versions of PHP, support for older versions will remain as-is in WordPress 6.9,
staying at PHP 7.2.24 and higher. This will continue to be evaluated and no change
will be made until usage numbers show that the impact on users will be minimal.

**WordPress continues to encourage all users to run the latest and greatest versions
of PHP, including PHP 8.5.**

_Props [@desrosj](https://profiles.wordpress.org/desrosj/), [@jorbin](https://profiles.wordpress.org/jorbin/)
for reviewing this post._

[#6-9](https://make.wordpress.org/core/tag/6-9/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/),
[#dev-notes-6-9](https://make.wordpress.org/core/tag/dev-notes-6-9/), [#php-compatibility](https://make.wordpress.org/core/tag/php-compatibility/)

 [  ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/)
12:56 pm _on_ July 11, 2025     
Tags: [developer-experience ( 3 )](https://make.wordpress.org/core/tag/developer-experience/),
[PHP ( 78 )](https://make.wordpress.org/core/tag/php/)   

# 󠀁[Proposal: PHPStan in the WordPress core development workflow](https://make.wordpress.org/core/2025/07/11/proposal-phpstan-in-the-wordpress-core-development-workflow/)󠁿

**tl;dr** Several official WordPress projects use PHPStan for static code analysisStatic
code analysis "...the analysis of computer software that is performed without actually
executing programs, in contrast with dynamic analysis, which is analysis performed
on programs while they are executing." - [Wikipedia](https://en.wikipedia.org/wiki/Static_program_analysis)
of PHPPHP The web scripting language in which WordPress is primarily architected.
WordPress requires PHP 7.4 or higher files as part of their development tooling 
and quality control. It’s used by thousands of WordPress plugins and themes to catch
and prevent bugs before they’re committed. Let’s use it for WordPress coreCore Core
is the set of software required to run WordPress. The Core Development Team builds
WordPress. too.

## What is PHPStan?

[PHPStan](https://phpstan.org/) is a mature, popular, and well-maintained static
code analysis tool for PHP. From the PHPStan website:

> PHPStan scans your whole codebase and looks for both obvious & tricky bugs. Even
> in those rarely executed `if` statements that certainly aren’t covered by tests.
> You can run it on your machine and in CI to prevent those bugs ever reaching your
> customers in production.

PHPStan provides a means of scanning 100% of the PHP code in a project and identifying
whole classes of bugs relating to code correctness within the context of the project
as a whole, even before executing, testing, or writing tests for the code.

Another static code analysis tool that is already in wide use in WordPress is PHP_CodeSniffer(
PHPCSPHP Code Sniffer [PHP Code Sniffer,](https://github.com/squizlabs/PHP_CodeSniffer)
a popular tool for analyzing code quality. The [WordPress Coding Standards](https://github.com/WordPress/WordPress-Coding-Standards/)
rely on PHPCS.), which checks adherence to coding standards that primarily relate
to code formatting (although the WordPress Coding StandardsWordPress Coding Standards
The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published
in the WordPress [Coding Standards Handbook](https://developer.wordpress.org/coding-standards/).
May also refer to [The collection of PHP_CodeSniffer rules](https://github.com/WordPress/WordPress-Coding-Standards/)(
sniffs) used to format and validate PHP code developed for WordPress according to
the PHP coding standards. provides additional rules for security, performance, and
internationalisation best practices). PHPStan doesn’t care about coding style, it
is un-opinionated and only tests the _validity_ and _correctness_ of code using 
[increasingly strict levels of rules](https://phpstan.org/user-guide/rule-levels)
which allow it to be gradually introduced into an existing code base, even one the
size and age of WordPress. It is complementary to PHPCS, not a replacement.

## What is being proposed?

On [#61175](https://core.trac.wordpress.org/ticket/61175), [@westonruter](https://profiles.wordpress.org/westonruter/)
notes that:

> PHPStan is a vital static analysis tool for identifying bugs in code. Previously
> it has been used to identify problems in core by manually running PHPStan on the
> core codebase.

This post proposes that:

 * PHPStan gets added as a development dependency to WordPress with the required
   settings and [a configured baseline](https://phpstan.org/user-guide/baseline).
 * PHPStan analysis runs as a required check during CI on GitHubGitHub GitHub is
   a website that offers online implementation of git repositories that can easily
   be shared, copied and modified by other developers. Public repositories are free
   to host, private repositories require a paid subscription. GitHub introduced 
   the concept of the ‘pull request’ where code changes done in branches by contributors
   can be reviewed and discussed before being merged by the repository owner. [https://github.com/](https://github.com/)
   Actions.
 * Documentation on usage of PHPStan gets added to the core handbook.
 * These changes are implemented during the WordPress 6.9 development cycle.

[@justlevine](https://profiles.wordpress.org/justlevine/) has kindly been working
on the bulk of the core implementation, the baseline, and the CI workflow [in this pull request on GitHub](https://github.com/WordPress/wordpress-develop/pull/7619).
Work on a documentation page for the handbook is yet to start.

The advantage of implementing a baseline is that PHPStan analysis can be introduced
without having to make sweeping changes to the core codebase in order to pass all
of the PHPStan rules from day one. The analysis will apply to code changes going
forward, and existing issues in the baseline can continue to be addressed just as
they have been in recent releases.

## Benefits of PHPStan

Adopting PHPStan improves our codebase and development workflows in several ways:

 * **Catch bugs in untested code**: Unit, integration, and E2E tests only cover 
   the code they execute. PHPStan can find bugs in code that isn’t explicitly tested,
   and make sure that code changes don’t introduce new bugs even in old code that
   has no tests.
 * **Prevent logic and type errors**: Unlike the enforcement of code formatting 
   in PHPCS, PHPStan can trace the flow of code execution and identify critical 
   errors that would otherwise only be caught at runtime. This is increasingly important
   as we work to maintain compatibility with the increasingly strict type safety
   requirements of PHP.
 * **Improve contributor experience (for humans and 🤖)**: PHPStan provides immediate,
   automated feedback to contributors, helping new, veteran, and even agentic developers
   catch their mistakes and learn how to navigate the WordPress codebase. This reduces
   the burden on committers during code review and helps AI tooling use WordPress
   as accurately as possible.
 * **Incremental adoption**: PHPStan provides levels of strictness that can be adopted
   incrementally, as well as ways to ignore rules and baseline errors in preexisting
   code without interrupting the codebase. This keeps in line with the [policy against unnecessary code refactoring](https://make.wordpress.org/core/handbook/contribute/code-refactoring/).

Taken together, using PHPStan will help the project maintain and improve the quality
and correctness of the WordPress codebase, paving the way for faster development,
fewer bugs, and the safe adoption of newer PHP features over time.

While _not a part of this proposal_, PHPStan also offers benefits such as type narrowing,
IDEIDE Integrated Development Environment. A software package that provides a full
suite of functionality to software developers/programmers. Normally an IDE includes
a source code editor, code-build tools and debugging functionality. hinting, documentation,
and code validation features like generics, callable signatures, integer ranges,
[and lots more](https://phpstan.org/writing-php-code/phpdoc-types). These enhancements
can be implemented as and when appropriate.

## Concerns

[When the implementation of native TypeScript in Gutenberg was proposed](https://make.wordpress.org/core/2021/03/18/proposal-native-typescript-support-in-gutenberg/),
there were some concerns raised:

 * The use of TypeScript could raise the barrier to entry for contributors.
 * TypeScript may not be here forever (ie. it could be outlasted by the underlying
   language).

If similar concerns are applied to the implementation of PHPStan:

 * Like any tool, there is an element of learning involved and there is always a
   risk of raising the barrier to entry, however that should not be a reason to 
   refrain from introducing new tooling that provides an overall benefit to the 
   project. Contributors who have not used PHPStan before may not be familiar with
   its error messages and may need guidance addressing issues that it reports, but
   handbook documentation, guidance from others, and general familiarisation over
   time will help. We’ll likely also find that the new generation of PHP developers
   is familiar with PHPStan due to its wide usage in many other popular and newer
   projects.
 * Unlike TypeScript, PHPStan isn’t a language itself that needs to be interpreted
   or transpiled in order to convert it to the PHP code that runs WordPress. If 
   the PHPStan project were to disappear, WordPress would continue to work, the 
   PHPStan checks could be removed, and another static analyzer could be implemented
   if necessary. That said, PHPStan is an active and well-maintained project so 
   this shouldn’t be a concern.

You might have heard that PHPStan is only used to check type declarations, but this
is not correct. In fact it only takes types into account when you start using it
at level 3 or higher, and its scope is far beyond just type safety. Take a look 
through [the PHPStan rule levels](https://phpstan.org/user-guide/rule-levels) to
see what it covers.

You might have heard that PHPStan only works for object-oriented codebases, this
is also not correct. There is nothing inherent about PHPStan that restricts it to
analyzing only OOP code. It works great with functional, procedural, and OOP code,
with and without namespaces, and mostly whatever else you can throw at it, including
excellent support for incomplete code.

There are two alternatives to PHPStan: [Psalm](https://github.com/vimeo/psalm) and
[Phan](https://github.com/phan/phan). All three of these static code analysis tools
are mature, popular, and well-maintained. PHPStan is being proposed because it’s
the most popular out of these three tools (both inside and outside of the WordPress
ecosystem), and because it’s the one that is most familiar to contributors to other
official WordPress projects, and contributors and committers to WordPress core. 
Implementing PHPStan will not prevent developers using Psalm or Phan to scan their
plugins, themes, or projects, or indeed to scan WordPress core using those tools
too.

## What about GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. 󠀁[https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/)󠁿?

The Gutenberg repo does not use PHPStan, however it would benefit from doing so 
in the same way that WordPress core will. [A proposal to implement PHPStan into the development of Gutenberg can be found here](https://github.com/WordPress/gutenberg/issues/66598).
It’s not strictly part of this proposal, but the teams do need to determine whether
this is a prerequisite.

## Does this affect end users?

End users and website owners are not _directly_ affected by this change. PHPStan
itself does not affect PHP at runtime in much the same way that TypeScript doesn’t
affect JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming
language commonly used to create interactive effects within web browsers. WordPress
makes extensive use of JS for a better user experience. While PHP is executed on
the server, JS executes within a user’s browser. [https://www.javascript.com](https://www.javascript.com/)
at runtime. The purpose of this class of tooling is to allow developers to maintain
code at a higher standard.

The effect this has on end users, consumers, developers, and web hosts is a higher
quality application that is more maintainable, reliable, and correct, and will continue
to be so over time. 

## Next steps

 * This proposal can stay open for a couple of weeks as several northern hemispherical
   contributors and committers are enjoying well-earned holidays.
 * Work needs to continue on the pull request that adds the configuration, baseline,
   and CI.
 * Continued communication needs to happen with the Gutenberg team to determine 
   whether PHPStan scanning in Gutenberg is a prerequisite.
 * A documentation page for the handbook needs to be drafted.

The latest version of PHPStan will be used (currently 2.1.17). This requires PHP
7.4 or greater which means the implementation of PHPStan depends on the minimum 
supported version of PHP in WordPress being increased to 7.4, [which is under consideration for WordPress 6.9](https://core.trac.wordpress.org/ticket/62622).
Therefore the 6.9 development cycle needs to be announced before this change can
be implemented. In the meantime there is no need to be concerned about PHPStan failures
on PHP 7.2 and 7.3 in the pull request.

Further technical details can be found on ticketticket Created for both bug reports
and feature development on the bug tracker. [#61175](https://core.trac.wordpress.org/ticket/61175).

## Elsewhere

If you’re curious about how other projects use PHPStan, here are some links.

PHPStan is used by [thousands of WordPress plugins, themes, tools, and projects](https://github.com/search?q=path%3Acomposer.json+%22wordpress%22+%22phpstan%22&type=code),
and [25,000 packages across the PHP ecosystem](https://packagist.org/packages/phpstan/phpstan).

It’s been in use for years by several other official WordPress projects, including:

 * [WP-CLI](https://github.com/wp-cli/wp-cli)
 * [Performance Lab](https://github.com/WordPress/performance)
 * [Plugin Check plugin](https://github.com/WordPress/plugin-check)
 * [Two Factor plugin](https://github.com/WordPress/two-factor)
 * [SQLite Database Integration plugin](https://github.com/WordPress/sqlite-database-integration)
 * [WPGraphQL plugin](https://github.com/wp-graphql/wp-graphql)
 * [WordPress Coding Standards](https://github.com/WordPress/WordPress-Coding-Standards)
 * [Twenty Twenty-One](https://github.com/WordPress/twentytwentyone) and [Twenty Twenty-Two](https://github.com/WordPress/twentytwentytwo)

It’s also been used previously by individual contributors to remediate many issues
in WordPress core, most recently in [#63268](https://core.trac.wordpress.org/ticket/63268).

If you are interested in using PHPStan as part of the development tooling in your
pluginPlugin A plugin is a piece of software containing a group of functions that
can be added to a WordPress website. They can extend functionality or add new features
to your WordPress websites. WordPress plugins are written in the PHP programming
language and integrate seamlessly with WordPress. These can be free in the WordPress.
org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party., theme, or project, you should take
a look at [the phpstan-wordpress package by Viktor Szépe](https://github.com/szepeviktor/phpstan-wordpress)
which provides WordPress-specific extensions for PHPStan.

## Acknowledgements

Thanks to [@justlevine](https://profiles.wordpress.org/justlevine/) [@westonruter](https://profiles.wordpress.org/westonruter/)
[@swissspidy](https://profiles.wordpress.org/swissspidy/) [@sergeybiryukov](https://profiles.wordpress.org/sergeybiryukov/)
and others for their work on PHPStan fixes in recent releases and for helping with
this proposal.

[#developer-experience](https://make.wordpress.org/core/tag/developer-experience/),
[#php](https://make.wordpress.org/core/tag/php/)

 [  ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/)
10:19 am _on_ July 7, 2025     
Tags: [PHP ( 78 )](https://make.wordpress.org/core/tag/php/),
[PHP 8.0 ( 6 )](https://make.wordpress.org/core/tag/php-8-0/), [php-compatibility ( 5 )](https://make.wordpress.org/core/tag/php-compatibility/)

# 󠀁[Proposal: Remove the “beta support” label from PHP 8.3 for WordPress 6.8](https://make.wordpress.org/core/2025/07/07/proposal-remove-the-beta-support-label-from-php-8-3-for-wordpress-6-8/)󠁿

**Update:** This change has been agreed and implemented.

[WordPress 6.4 to 6.8 are labelled as having “beta support” for PHP 8.3](https://make.wordpress.org/core/2025/04/09/php-8-support-clarification/).
The coreCore Core is the set of software required to run WordPress. The Core Development
Team builds WordPress. software itself is compatible and has been since November
2023, but due to the acknowledgement that WordPress is rarely used in isolation (
without any theme or plugins) this support is labelled as “betaBeta A pre-release
of software that is given out to a large group of users to trial under real conditions.
Beta versions have gone through alpha testing in-house and are generally fairly 
close in look, feel and function to the final product; however, design changes often
occur as part of the process. support”.

[Last month, combined usage of PHP 8.3 and higher surpassed 10% of all WordPress websites](https://johnbillion.github.io/wp-stats/php.html).
I am proposing two small adjustments to [the criteria for removing the “beta support” label from each PHP version](https://make.wordpress.org/core/2023/06/20/proposal-criteria-for-removing-beta-support-from-each-php-8-version/):

 1. Remove the “for at least 3 months” clause from the “Enough sites” indicator. 10%
    of all WordPress sites is [somewhere well north of 3 million](https://wordpress.com/blog/2025/04/17/wordpress-market-share/)
    and the 3 month clause seems unnecessary at that scale.
 2. Allow the label to be retroactively removed from the current major releasemajor
    release A release, identified by the first two numbers (3.6), which is the focus
    of a full release cycle and feature development. WordPress uses decimaling count
    for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable
    in scope.. There is no need to wait for the next major release to update the support
    status if its only remaining criteria is based on usage numbers.

With these two small adjustments, the “beta support” label for PHPPHP The web scripting
language in which WordPress is primarily architected. WordPress requires PHP 7.4
or higher 8.3 can be removed from WordPress 6.8. If there are no objections then
I’ll make this change this week.

## What does this change mean for users and extenders?

Declaring PHP 8.3 as fully supported will help continue to provide clarity and confidence
to users and to encourage web hosts and users to continue updating to newer versions
of PHP. Users and extenders of WordPress can be confident using and recommending
more up to date versions of PHP when the WordPress project continues to test, support,
track, and encourage use of newer versions both in the core software and throughout
the ecosystem.

## What about PHP 8.4?

PHP 8.4 was released in November 2024 and [its usage is currently at 1.5%](https://wordpress.org/about/stats/),
therefore its “beta support” status will remain in place for now.

## What about PHP 8.5?

Hold your horses, [PHP 8.5 is still in development](https://core.trac.wordpress.org/ticket/63061)
and its release is planned for November 2025.

_Thanks to [@jorbin](https://profiles.wordpress.org/jorbin/) for proof-reading and
suggestions prior to publishing._

[#php](https://make.wordpress.org/core/tag/php/), [#php-8-0](https://make.wordpress.org/core/tag/php-8-0/),
[#php-compatibility](https://make.wordpress.org/core/tag/php-compatibility/)

 [  ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/)
9:14 am _on_ April 9, 2025     
Tags: [PHP ( 78 )](https://make.wordpress.org/core/tag/php/),
[PHP 8.0 ( 6 )](https://make.wordpress.org/core/tag/php-8-0/), [php-compatibility ( 5 )](https://make.wordpress.org/core/tag/php-compatibility/)

# 󠀁[PHP 8 support clarification](https://make.wordpress.org/core/2025/04/09/php-8-support-clarification/)󠁿

**tl;dr:** Use of the “compatible with exceptions” label for PHPPHP The web scripting
language in which WordPress is primarily architected. WordPress requires PHP 7.4
or higher 8 support has been retired and has been retroactively removed from all
versions.

 * WordPress 6.3 and later is now documented as fully supporting PHP 8.0 and 8.1
 * WordPress 6.6 and later is now documented as fully supporting PHP 8.2
 * WordPress 6.8 and later is now documented as fully supporting PHP 8.3
 * Support for PHP 8.4 remains in betaBeta A pre-release of software that is given
   out to a large group of users to trial under real conditions. Beta versions have
   gone through alpha testing in-house and are generally fairly close in look, feel
   and function to the final product; however, design changes often occur as part
   of the process. as of WordPress 6.8

[WordPress has supported PHP 8 since version 5.6 back in 2020](https://make.wordpress.org/core/2020/11/23/wordpress-and-php-8-0/),
but due to the acknowledgement that WordPress is rarely used in isolation (without
any theme or plugins) this support has been labelled as “beta support”, and later
as “compatible with exceptions” following the guidelines that were adopted as a 
result of [the proposal for criteria for removing the “beta support” label from each PHP 8+ version](https://make.wordpress.org/core/2023/06/20/proposal-criteria-for-removing-beta-support-from-each-php-8-version/).

In order to provide clarity and confidence to users and to encourage web hosts and
users to continue updating to the latest versions of PHP, use of the “compatible
with exceptions” label has now been retired. Documented support for any given version
of PHP will now go straight from “beta support” to fully supported once the agreed
criteria for removing that label have been met. The label has been removed retroactively
from all versions.

[PHP compatibility of all WordPress versions is documented here in the handbook and has been updated to reflect this change](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/).

## What prompted this change?

The criteria for removing the “beta support” label were adopted in 2023 just prior
to the release of WordPress version 6.3. In that version a significant amount of
work was done to resolve remaining PHP compatibility issues and to switch to using
the “compatible with exceptions” label for PHP 8.0 and 8.1. The same was done in
WordPress 6.6 for PHP 8.2, and the number and significance of these documented compatibility
exceptions is now very low.

Since then it’s become apparent that some end users and web hosts remain reluctant
to update to PHP 8 when the documented support in WordPress is still labelled as“
compatible with exceptions”, despite the actual support being complete as far as
most sites are concerned (over 60% of WordPress sites run PHP 8+). The label has
served its purpose over the last 18 months but now risks being detrimental to the
continued adoption of newer versions of PHP.

Removing this label — while still documenting the exceptions where necessary — will
help continue the adoption of newer and fully supported versions of PHP and provide
confidence to the remaining 40% of sites to update.

## What are the criteria for removing the “beta support” label?

These criteria have not changed. The criteria are:

 * Enough sites: At least 10% of all WordPress sites running on a specific or newer
   PHP version for at least 3 months.
 * Issues:
    - All reported and known compatibility issues are resolved.
    - All accepted incompatibilities are documented as exceptions from full compatibility.
 * BC: Full backward compatibility is maintained for all older PHP versions WordPress
   supports, demonstrated with automated tests for each compatibility change.

[Usage of PHP 8.3 and higher is at 8.9% of all WordPress sites as of April 2025](https://wordpress.org/about/stats/).
Once this surpasses 10% and assuming no further compatibility issues are reported
then it’s expected that the beta label for PHP 8.3 support will be removed in the
subsequent major releasemajor release A release, identified by the first two numbers(
3.6), which is the focus of a full release cycle and feature development. WordPress
uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are 
sequential and comparable in scope. of WordPress.

## What’s the minimum supported version?

The minimum supported version of PHP remains unchanged at 7.2.24+.

Props to [@desrosj](https://profiles.wordpress.org/desrosj/) [@joemcgill](https://profiles.wordpress.org/joemcgill/)
[@garyj](https://profiles.wordpress.org/garyj/) for input on this change.

[#php](https://make.wordpress.org/core/tag/php/), [#php-8-0](https://make.wordpress.org/core/tag/php-8-0/),
[#php-compatibility](https://make.wordpress.org/core/tag/php-compatibility/)

 [  ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/)
2:01 pm _on_ February 17, 2025     
Tags: [6-8 ( 91 )](https://make.wordpress.org/core/tag/6-8/),
[dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), [dev-notes-6-8 ( 15 )](https://make.wordpress.org/core/tag/dev-notes-6-8/)

# 󠀁[WordPress 6.8 will use bcrypt for password hashing](https://make.wordpress.org/core/2025/02/17/wordpress-6-8-will-use-bcrypt-for-password-hashing/)󠁿

Note: This article has been updated with additional technical information about 
the structure of password hashes that may be relevant to developers of plugins that
directly handle them.

The underlying algorithm that’s used to hash and store user passwords in the database
will be changed in WordPress 6.8 from phpass portable hashing to bcrypt. The adoption
of bcrypt hardens password security in WordPress by significantly increasing the
computational cost of cracking a password hash.

In addition, application passwords, user password reset keys, personal data request
keys, and the recovery mode key will switch from using phpass to the cryptographically
secure but fast BLAKE2b hashing algorithm via Sodium.

No action needs to be taken by site owners or users as a result of these changes.
Passwords and security keys that were saved in prior versions of WordPress will 
continue to work after updating to 6.8. Users don’t need to change or reset their
passwords, logged in users will remain logged in, and their sessions will remain
valid.

When a user first subsequently logs in after the update – or when they next change
their password – their password will automatically get rehashed with bcrypt and 
resaved in the database. Application passwords and security keys will not get automatically
rehashed, but an existing hash will remain valid if it was generated prior to WordPress
6.8 and used before it expires.

Note that post passwords will continue to use phpass portable hashing for now. This
may change in the future after further investigation has been done on how best to
improve the hashing and checking mechanism of post passwords.

## Portability

Hashes that are generated by the phpass portable hashing algorithm are portable 
between different sites, environments, and servers. This portability doesn’t change
with this switch to bcrypt and BLAKE2b, so you can move your database from one server
to another and update to newer versions of PHPPHP The web scripting language in 
which WordPress is primarily architected. WordPress requires PHP 7.4 or higher and
WordPress and the password hashes will continue to function as expected.

## Updates to password handling functions

The `wp_hash_password()` and `wp_check_password()` functions have been updated to
use the PHP native `password_hash()` and `password_verify()` functions with the 
bcrypt algorithm and SHA-384 pre-hashing. Both functions retain support for the `
$wp_hasher` global object in case that’s being used to implement an alternative 
hashing mechanism.

The `wp_check_password()` function retains support for passwords that were hashed
using phpass, which means existing password hashes won’t be invalidated.

A new `wp_password_needs_rehash()` function has been introduced as a wrapper for`
password_needs_rehash()`. If a pluginPlugin A plugin is a piece of software containing
a group of functions that can be added to a WordPress website. They can extend functionality
or add new features to your WordPress websites. WordPress plugins are written in
the PHP programming language and integrate seamlessly with WordPress. These can 
be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. needs to adjust its logic then the`
password_needs_rehash` filterFilter Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin_API/Hooks](https://codex.wordpress.org/Plugin_API/Hooks).
They provide a way for functions to modify data of other functions. They are the
counterpart to Actions. Unlike Actions, filters are meant to work in an isolated
manner, and should never have side effects such as affecting global variables and
output. can be used. The function is also pluggable, so it can be overridden if 
absolutely necessary.

Pre-hashing with SHA-384 is implemented in order to avoid the 72 byte length limit
imposed on passwords by bcrypt. Password hashes are therefore stored with a `$wp`
prefix to distinguish them from vanilla bcrypt hashes which may be in use via a 
plugin. By default this means the full prefix will be `$wp$2y$`.

## New fast hashing functions

The following functions have been introduced as wrappers for the cryptographically
secure but fast BLAKE2b algorithm via Sodium:

 * `wp_fast_hash()`
   Used to hash a string that is randomly generated using sufficiently
   high entropy, preferably over 128 bits for values that don’t have a corresponding
   expiry mechanism.
 * `wp_verify_fast_hash()`
   Used to verify a hash generated via `wp_fast_hash()`,
   with fallback support for phpass portable hashes.

## Do developers need to do anything?

Code that calls `wp_hash_password()` and `wp_check_password()` will continue to 
work as expected and does not need to change.

Code that _directly_ handles phpass hashes may need to be updated, for example:

 * Code that assumes the existence of the `$P$` prefix on hashes. The code will 
   need to be updated so it either doesn’t need to inspect the prefix of the hash
   at all, or updated to handle both the new prefixes and hashing algorithms and
   legacy hashes:
    - The `$wp$2y$` prefix will be the new default for user passwords in WordPress
      and represents a SHA-384 pre-hashed bcrypt hash.
    - The plain `$2y$` prefix may be used by existing plugins that use bcrypt hashes
      without pre-hashing.
    - The `$generic$` prefix for a BLAKE2b hash used for application passwords and
      security keys.
    - A hash starting with `$argon2` if a site opts in to using an Argon2 algorithm(
      see below). Note that any non-bcrypt algorithm won’t use pre-hashing and therefore
      won’t include `$wp` at the start of the prefix.
    - The old `$P$` prefix for a phpass portable hash which will remain in wide 
      use.
    - A legacy plain MD5 hash, which is a 32 character hexadecimal string.
 * Code that otherwise directly interacts with the hashed value of a user password.
   If such hashes are validated directly, this should be done via `wp_check_password()`.
 * Code that otherwise directly interacts with the hashed value of an application
   password, password reset key, personal data request key, or the recovery mode
   key. If such hashes are validated directly, this should be done via the new `
   wp_verify_fast_hash()` function.
 * Any plugin that overwrites the pluggable `wp_hash_password()` and `wp_check_password()`
   functions. Unless these functions specifically implement another hashing algorithm,
   they can be removed in order to allow the bcrypt implementation in 6.8 to take
   effect.

Alternative authentication mechanisms such as single sign-on (SSO), social login,
or one-time login are unlikely to be affected by this change, however you should
still verify whether your specific implementation includes any handling of password
hashes or security keys. Multi-factor (MFA and 2FA) implementations are also unlikely
to be affected by this change.

## What about Argon2?

Servers that support Argon2 can enable its usage with this single line of code in
WordPress 6.8 and later:

    ```wp-block-code
    add_filter( 'wp_hash_password_algorithm', fn() => PASSWORD_ARGON2ID );
    ```

If necessary, the `password_algos()` function should be used to first check for `
argon2id` support. Unfortunately it’s not possible to rely on Argon2 being available
on all servers because it requires both `libargon2` to be available on the server
and for PHP to be built with Argon2 support enabled. The `sodium_compat` library
does not provide an implementation of Argon2.

## Acknowledgements

We can’t pretend that switching to bcrypt for user-generated passwords is a recent
proposal. Ideally the switch would have been made back when the increase to the 
minimum supported version of PHP facilitated this change. However, this change _has_
now been made and it helps future-proof further improvements to password hashing,
including increases to the bcrypt cost in newer versions of PHP.

Many thanks go to [the Roots team](https://roots.io/about/) for maintaining their
[bcrypt password hashing package for WordPress](https://github.com/roots/wp-password-bcrypt)
as well as the many contributors on the TracTrac An open source project by Edgewall
Software that serves as a bug tracker and project management tool for WordPress.
tickets and GitHubGitHub GitHub is a website that offers online implementation of
git repositories that can easily be shared, copied and modified by other developers.
Public repositories are free to host, private repositories require a paid subscription.
GitHub introduced the concept of the ‘pull request’ where code changes done in branches
by contributors can be reviewed and discussed before being merged by the repository
owner. [https://github.com/](https://github.com/) pull requests.

## Further technical information

Further technical information, technical FAQs, and implementation details can be
seen [on the GitHub pull request for this change](https://github.com/WordPress/wordpress-develop/pull/7333)
and [in the discussion on the Trac ticket](https://core.trac.wordpress.org/ticket/21022).

In case you need to know:

 * User passwords are stored as a hash in the `wp_users.user_pass` field in the 
   database.
 * Application passwords are stored as a hash in a JSONJSON JSON, or JavaScript 
   Object Notation, is a minimal, readable format for structuring data. It is used
   primarily to transmit data between a server and web application, as an alternative
   to XML. serialized object in the `wp_usermeta` table using the `_application_passwords`
   key.
 * User password reset keys are stored as a hash in the `wp_users.user_activation_key`
   field in the database.
 * Personal data request keys are stored as a hash in the `wp_posts.post_password`
   field in the database against the post that represents the personal data request.
 * The recovery mode key is stored as a hash in the `recovery_keys` option in the`
   wp_options` database table.

_Thanks to [@desrosj](https://profiles.wordpress.org/desrosj/) and [@joehoyle](https://profiles.wordpress.org/joehoyle/)
for helping review this post._

[#6-8](https://make.wordpress.org/core/tag/6-8/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/),
[#dev-notes-6-8](https://make.wordpress.org/core/tag/dev-notes-6-8/)

 [  ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/)
9:24 pm _on_ April 8, 2024     
Tags: [6-6 ( 57 )](https://make.wordpress.org/core/tag/6-6/),
[dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), [PHP ( 78 )](https://make.wordpress.org/core/tag/php/)

# 󠀁[Dropping support for PHP 7.0 and 7.1](https://make.wordpress.org/core/2024/04/08/dropping-support-for-php-7-1/)󠁿

Support for PHPPHP The web scripting language in which WordPress is primarily architected.
WordPress requires PHP 7.4 or higher 7.0 and 7.1 will be dropped in WordPress 6.6,
scheduled for release in July 2024. The new minimum supported version of PHP will
be 7.2.24. The _recommended_ version of PHP remains at 7.4 or greater.

WordPress currently supports PHP version 7.0 or greater. The minimum supported version
was last adjusted in WordPress 6.3 in August 2023, and since then usage of PHP 7.0
and 7.1 has dropped to a combined 2.45% of monitored WordPress installations [as of April 2024](https://wordpress.org/about/stats/).

There’s no concrete usage percentage that a PHP version must fall below before support
in WordPress is dropped, but historically the project maintainers have used 5% as
the baseline. Now that usage of PHP 7.0 and 7.1 combined is well below that at 2.45%,
the process to increase the minimum supported PHP version in this release can move
forward.

The benefits to increasing the minimum supported PHP version manifest over time 
and in multiple places, including within the pluginPlugin A plugin is a piece of
software containing a group of functions that can be added to a WordPress website.
They can extend functionality or add new features to your WordPress websites. WordPress
plugins are written in the PHP programming language and integrate seamlessly with
WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. and theme ecosystem, within the 
long term perception of the WordPress project, within developer relations, and over
time within the WordPress codebase and its developer tooling.

[Discussion around this minimum version bump can be found here on the Trac ticket](https://core.trac.wordpress.org/ticket/58719).

## What about PHP 8?

WordPress coreCore Core is the set of software required to run WordPress. The Core
Development Team builds WordPress. is compatible with PHP 8.0 and 8.1 with exceptions.
Support for PHP 8.2 and PHP 8.3 is considered betaBeta A pre-release of software
that is given out to a large group of users to trial under real conditions. Beta
versions have gone through alpha testing in-house and are generally fairly close
in look, feel and function to the final product; however, design changes often occur
as part of the process. since WordPress 6.4. [Please see the PHP Compatibility and WordPress Versions page in the handbook for full information](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/).

## What about security support?

Sites that are running PHP 7.0 or 7.1 will remain on the 6.5 branchbranch A directory
in Subversion. WordPress uses branches to store the latest development code for 
each major release (3.9, 4.0, etc.). Branches are then updated with code for any
minor releases of that branch. Sometimes, a major version of WordPress and its minor
versions are collectively referred to as a "branch", such as "the 4.0 branch". of
WordPress which will continue receiving security updates as it does currently. [The current security policy is to support WordPress versions 4.1 and greater](https://make.wordpress.org/security/2022/09/07/dropping-security-updates-for-wordpress-versions-3-7-through-4-0/).

## What about the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. 󠀁[https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/)󠁿 plugin?

The Gutenberg plugin, which is used for development of the blockBlock Block is the
abstract term used to describe units of markup that, composed together, form the
content or layout of a webpage using the WordPress editor. The idea combines concepts
of what in the past may have achieved with shortcodes, custom HTML, and embed discovery
into a single consistent API and user experience. editor, has a separate release
schedule from WordPress core and officially supports the two most recent releases
of WordPress. The Gutenberg development team will likely also increase the minimum
supported version of PHP to 7.2 in time for WordPress 6.6. [See this issue on the Gutenberg repo for when this was last changed in WordPress 6.3](https://github.com/WordPress/gutenberg/issues/52344).

## Going forward

There are no plans to bump the minimum supported PHP version on a schedule. The 
core team will continue to monitor usage of PHP versions and work with the hosting
team to encourage users and hosting companies to upgrade their versions of PHP as
swiftly as possible. The 5% usage baseline will continue to be used for the foreseeable
future.

[The PHP usage stats as of April 2024 look like this](https://wordpress.org/about/stats/):

 * 8.3: 1.20%
 * 8.2: 12.07%
 * 8.1: 16.34%
 * 8.0: 12.25%
 * 7.4: 42.80%
 * 7.3: 4.79%
 * 7.2: 3.80%
 * 7.1: 0.95%
 * 7.0: 1.50%

## Update PHP today

If you need more information about PHP or how to update it, [check out this support article that explains more and guides you through the process](https://wordpress.org/support/update-php/).

_Props to all those that have contributed to this discussion recently. Thanks to_
[@chanthaboune](https://profiles.wordpress.org/chanthaboune/)_ for feedback and 
proof-reading this post_.

[#6-6](https://make.wordpress.org/core/tag/6-6/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/),
[#php](https://make.wordpress.org/core/tag/php/)

 [  ](https://profiles.wordpress.org/johnbillion/) [John Blackbourn](https://profiles.wordpress.org/johnbillion/)
5:45 pm _on_ July 5, 2023     
Tags: [PHP ( 78 )](https://make.wordpress.org/core/tag/php/)

# 󠀁[Dropping support for PHP 5](https://make.wordpress.org/core/2023/07/05/dropping-support-for-php-5/)󠁿

Support for PHPPHP The web scripting language in which WordPress is primarily architected.
WordPress requires PHP 7.4 or higher 5 will be dropped in WordPress 6.3, scheduled
for release on August 8th 2023. The new minimum supported version of PHP will be
7.0.0. The _recommended_ version of PHP remains at 7.4 or greater.

WordPress currently supports PHP version 5.6.20 or greater. The minimum supported
version was last adjusted in WordPress 5.2 in 2019, and since then usage of PHP 
5.6 has dropped to 3.9% of monitored WordPress installations [as of July 2023](https://wordpress.org/about/stats/).

There’s no concrete usage percentage that a PHP version must fall below before support
in WordPress is dropped, but historically the project maintainers have used 5% as
the baseline. Now that usage of PHP 5.6 is well below that at 3.9% and dropping 
by around 0.1% every few weeks, plans to increase the minimum supported PHP version
can move forward.

The benefits to increasing the minimum supported PHP version manifest over time 
and in multiple places, including within the pluginPlugin A plugin is a piece of
software containing a group of functions that can be added to a WordPress website.
They can extend functionality or add new features to your WordPress websites. WordPress
plugins are written in the PHP programming language and integrate seamlessly with
WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. and theme ecosystem, within the 
long term perception of the WordPress project, within developer relations, and over
time within the WordPress codebase and its developer tooling.

[Discussion around this minimum version bump can be found here on the Trac ticket](https://core.trac.wordpress.org/ticket/57345).

## What about PHP 8?

Support for PHP 8.0, 8.1, and 8.2 in WordPress coreCore Core is the set of software
required to run WordPress. The Core Development Team builds WordPress. is very good,
and [a proposal for the criteria for removing the “beta” support label for each new PHP version has been published](https://make.wordpress.org/core/2023/06/20/proposal-criteria-for-removing-beta-support-from-each-php-8-version/).

## What about security support?

Sites that are running PHP 5.6 will remain on the 6.2 branchbranch A directory in
Subversion. WordPress uses branches to store the latest development code for each
major release (3.9, 4.0, etc.). Branches are then updated with code for any minor
releases of that branch. Sometimes, a major version of WordPress and its minor versions
are collectively referred to as a "branch", such as "the 4.0 branch". of WordPress
which will continue receiving security updates as it does currently. [The current security policy is to support WordPress versions 4.1 and greater](https://make.wordpress.org/security/2022/09/07/dropping-security-updates-for-wordpress-versions-3-7-through-4-0/).

## What about the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. 󠀁[https://wordpress.org/gutenberg/](https://wordpress.org/gutenberg/)󠁿 plugin?

The Gutenberg plugin, which is used for development of the blockBlock Block is the
abstract term used to describe units of markup that, composed together, form the
content or layout of a webpage using the WordPress editor. The idea combines concepts
of what in the past may have achieved with shortcodes, custom HTML, and embed discovery
into a single consistent API and user experience. editor, has a separate release
schedule from WordPress core and officially supports the two most recent releases
of WordPress. This means that the Gutenberg plugin will continue to support PHP 
5.6 for the time being, most likely until WordPress 6.4 is released. [See this issue on the Gutenberg repo for further information](https://github.com/WordPress/gutenberg/issues/52344).

## Going forward

There are no plans to bump the minimum supported PHP version on a schedule. The 
core team will continue to monitor usage of PHP versions and work with the hosting
team to encourage users and hosting companies to upgrade their versions of PHP as
swiftly as possible. The 5% usage baseline will continue to be used for the foreseeable
future.

[The PHP usage stats as of July 2023 look like this](https://wordpress.org/about/stats/):

 * 8.2: 2.11%
 * 8.1: 9.37%
 * 8.0: 14.05%
 * 7.4: 51.13%
 * 7.3: 7.92%
 * 7.2: 6.29%
 * 7.1: 1.38%
 * 7.0: 2.05%
 * 5.6: 3.93%

## Update PHP today

If you need more information about PHP or how to update it, [check out this support article that explains more and guides you through the process](https://wordpress.org/support/update-php/).

_Props to all those that have contributed to this discussion recently. Thanks to
those who provided feedback and proof-reading of this post:_ [@azaozz](https://profiles.wordpress.org/azaozz/)
[@chanthaboune](https://profiles.wordpress.org/chanthaboune/) [@flixos90](https://profiles.wordpress.org/flixos90/)
[@hellofromtonya](https://profiles.wordpress.org/hellofromtonya/) [@javiercasares](https://profiles.wordpress.org/javiercasares/)
[@joemcgill](https://profiles.wordpress.org/joemcgill/) [@jorbin](https://profiles.wordpress.org/jorbin/)
[@jrf](https://profiles.wordpress.org/jrf/) [@peterwilsoncc](https://profiles.wordpress.org/peterwilsoncc/)
[@sergeybiryukov](https://profiles.wordpress.org/sergeybiryukov/)

[#php](https://make.wordpress.org/core/tag/php/)

# Post navigation

[← Older posts](https://make.wordpress.org/core/author/johnbillion/page/2/?output_format=md)