PHP 8.4 and 8.5 for WordPress

The label was retired in May 2026

On 22 May 2026 the WordPress core team retired the “beta” label on PHP support. The label was removed retroactively. The reason was that the PHP 8 series ships regular stable releases, and the plugin and theme work is smaller than it used to be. The old rule wrote “beta” until a PHP 8 release passed 10 percent of WordPress installs. That sentence is gone.

The same note makes three lines plain. WordPress 6.9 and 7.0 are documented as fully supporting PHP 8.5. WordPress 6.8 and later are documented as fully supporting PHP 8.4. WordPress 6.4 and later are documented as fully supporting PHP 8.3. “Fully supported” means core. A plugin sits outside that table.

The recommended minimum PHP version stays at 8.3. Since WordPress 7.0, the supported minimum is 7.4. 7.0 dropped PHP 7.2 and 7.3. 7.4, 8.0, and 8.1 remain on the list for backward compatibility. The PHP group has already closed those three branches. WordPress running does not mean that branch still receives patches.

Which branch is patched, and until when?

PHP’s own calendar is separate from the WordPress table. Each branch gets about two years of active support, then two years of security fixes only. Read in October 2026, the table is this. PHP 8.2 active support ended on 31 December 2024. Security support ends on 31 December 2026. PHP 8.3 active support ended on 31 December 2025. Security support runs until 31 December 2027. PHP 8.4 keeps active support until 31 December 2026, and security support until 31 December 2028. PHP 8.5 keeps active support until 31 December 2027, and security support until 31 December 2029.

8.1 and older are not on that table. The last 8.1 release is 8.1.34, and security support closed on 31 December 2025. 8.0.30, 7.4.33, and older are closed too. If the hosting account still shows 7.4, WordPress 7.0 can start. Starting does not mean that PHP is safe.

The hosting handbook writes production separately. PHP 8.4 or newer is recommended for production. 8.4 is described as fully supported for WordPress 6.7 and later. 8.5 is described as fully supported for WordPress 6.9 and later. The handbook asks hosts to test the whole stack before a new PHP becomes the production default. The core team says the same thing. WordPress does not run alone.

The real limit is the plugin

Core saying 8.5 does not mean your shop plugin says it. WooCommerce, cache, payment, and form plugins write their own PHP line. If one plugin stops at 8.3, the site drops that plugin when you move to 8.5. What drops is usually checkout or login, not the home page. That is why a version change is not the first test on the live site.

The order is short. Read the running PHP in the panel. Write down the PHP each plugin asks for. The plugin that lags sets your target. If that plugin has a newer release, install it on staging. Then raise PHP on staging. Submit the form, put a product in the cart, log in as admin, and empty the cache. If you see a white screen or a checkout error, do not change production. The WooCommerce 11.2 checkout fix is in a separate article. That fix does not replace a PHP upgrade. They can happen in the same month. They are not the same job.

A site still on 8.2 closes its security calendar on 31 December 2026. From October, a little more than two months remain. A site still on 8.3 receives security patches until the end of 2027, but not active development. New bug fixes are on the 8.4 and 8.5 branches. The target for a new or rebuilt site is the newest branch the plugins allow. On most sites that target is 8.4. If the plugins declare 8.5, move to 8.5. If they do not, stay on 8.4.

Read the WordPress version and PHP together

6.8 is “no” in the PHP 8.5 column. 8.5 needs 6.9 or 7.0. Running 6.8 on 8.4 is full support in the document. Moving 6.8 to 8.5 is not in the document. Security release 6.8.11 does not change this table. The last patch on the 6.8 branch does not add 8.5 support. If you want PHP 8.5 without changing the branch, core has to become 6.9 or 7.0 first. The editor side of 7.0 is in the Armstrong article. The 6.8 security patches are in the security article.

The other direction exists too. Installing 7.0 and staying on PHP 7.4 is possible in the document. Possible is not the recommendation. 7.4’s own patches ended in 2022. WordPress carries that version only for backward compatibility. The production target is 8.4.

The OwnHost card has no PHP line

The Personal and Pro cards on the WordPress hosting page list disk, site count, backup, and Nginx. They do not list a PHP version. Do not read this article as “OwnHost provides 8.5”. Read the version in the panel. If the panel has no switch, open a support ticket. Do not invent the number on the card.

Personal is $0.79 a month, or $8.99 a year. It lists one site, 15 GB NVMe, 2048 MB of RAM, one-click install, free SSL, Nginx, and a weekly backup. Pro is $3.29 a month, or $26.99 a year. It lists ten sites, 4096 MB of RAM, a daily backup, and staging. A PHP test needs staging. That line is on the Pro card. Personal has no staging. Trying it on the live Personal site is not the path this page recommends.

The Nginx line does not replace the PHP version. The web server accepts the request. PHP runs WordPress. They are not the same settings screen. NVMe disk does not raise the PHP branch either. Speed and the patch calendar are separate lines. The patch calendar comes first, then speed.

Leave 8.2 before December 2026. If you stay on 8.3, write down that it is a security-only branch. 8.4 is the handbook’s production recommendation. 8.5 is open when core is 6.9 or 7.0 and the plugins are ready. See all three on staging, then change production.