The short answer: run the newest version your application actually supports, and find out which one that is by testing rather than by guessing.
The longer answer is worth the two minutes, because both directions of this decision cost something.
Why not just run the newest
Newer PHP is genuinely faster and gets security fixes. PHP 8 is substantially quicker than PHP 7 on the same code, and versions past end of life stop receiving patches entirely, which is a real risk on a public site.
But PHP major versions remove things. Code that ran fine for years can fatal on the newer runtime, and the failure is often not on the page you tested. A theme’s admin screen, a payment callback, a nightly cron job: these break in places you do not look at during a quick check.
Why not just stay put
Staying on an end-of-life version means running code with known, published, unpatched vulnerabilities. It also gets harder to leave over time, because the gap you eventually have to jump keeps widening, and the plugins you would upgrade to have themselves dropped support for your version.
Sitting on PHP 5.6 in 2026 is not stability. It is a decision to accumulate risk quietly.
How to actually choose
- Ask the application first. WordPress, Laravel, Drupal and the rest all publish a supported PHP range. Start there, not with the highest number available.
- Then ask the plugins and themes. This is where WordPress sites get caught. The core supports the new version; one abandoned plugin does not.
- Pick the newest version everything in that list supports. Not the newest that exists.
- Re-check every six months or so. The answer changes as your dependencies get updated.
For most current WordPress sites in 2026 that lands on PHP 8.2 or 8.3. For an actively maintained Laravel application it is usually 8.3 or 8.4. For an old bespoke PHP application nobody has touched since 2016, it may genuinely be 7.4, and the honest next step is budgeting to fix that rather than pretending it is fine.
Test the upgrade without risking the site
A per-site PHP selector means the version is not an account-wide setting. That makes the safe path available:
- Put a copy of the site on a staging or secondary site, switch that copy to the new version, and exercise it properly. Log in to the admin, submit a form, run a checkout, trigger the cron job.
- Turn error display on for the copy while testing, so failures are loud rather than a blank white page.
- Then move the live site, and keep the old version in mind as a one-click way back if something surfaces in the first day.
On our plans the selector covers PHP 5.6 through 8.5 and is set per site, with 8.4 as the default, so both the test copy and the rollback are a dropdown rather than a support ticket.
What breaking usually looks like
Two symptoms cover most of it:
- A blank white page. PHP hit a fatal error and display is off. The reason is in the error log, not the browser.
- A specific feature stops, everything else is fine. Almost always one plugin or one library using something the new version removed.
Neither means the upgrade was a mistake. Both mean something in your dependency list needs updating, and you now know which thing before it became a security incident instead.