How to Update the PHP Version in Plesk (Safely, Per Site)

Why Outdated PHP Is a Security Risk

PHP versions get roughly two years of active support plus one of security-only patches — after that, nothing. Every vulnerability found in an end-of-life version is public and scanned for at scale, so an old interpreter is a known target, not just a slow one. The secondary costs compound too: newer PHP runs faster, and current themes and frameworks refuse old versions, so an outdated interpreter blocks the site's next update.

The routine below makes the upgrade a five-minute risk instead of a gamble: compatibility check, change, verify, rollback. Big jumps deserve a rehearsal — the staging guide sets one up.

Step 1: Check Plugin and Theme Compatibility

Open the site's PHP Settings screen and note the current version first — that is your rollback point. Then inventory what runs on the site: every plugin, every theme, and any hand-written code. Check each maintained item's changelog or documentation for the PHP version you plan to move to; anything abandoned years ago is the usual cause of a broken upgrade, so replace or remove it before you switch. Take a fresh backup — the Plesk Backup Manager guide covers the click path — so a bad surprise costs minutes, not the site.

For a WordPress site, updating plugins and themes to their latest releases before the PHP change removes most incompatibilities in advance.

Step 2: Change PHP in Plesk PHP Settings

Go to Websites & Domains, open the domain you are changing, and click PHP Settings (on newer panels the domain card shows a PHP button with the current version next to it). Keep the PHP support checkbox ticked, pick the target version from the dropdown — a current 8.x release is the safe default — leave the handler as configured unless support has advised otherwise, and click OK. The change applies to that domain only and takes effect shortly; the domain card now shows the new version.

The dropdown lists only the versions your host has installed on the server. If the one you want is missing, ask the host to add it rather than settling for an older line.

Step 3: Test and Roll Back if Needed

Reload the site in a private browser window so cache cannot hide the result. Walk the pages that matter: the front page, a product or article page, the contact form, and the admin login. A working site finishes the job; repeat the same three steps on the next site when you have several.

Anything broken — a white screen, a fatal-error message, a form that dies — is fixed the same way it was made: back to PHP Settings, re-select the previous version you noted in Step 1, click OK, and the site is back within moments. Then read the error text: a named plugin or theme usually identifies the culprit, which you update or replace before retrying. If the error text means nothing to you, email support@webji.services with the exact message — the 24/7 desk (Hindi and English) reads it with you.

Running Mixed PHP Versions Across Sites

The change you made applies to one domain, and that is the point: the shop can run a current 8.x release while an older site keeps the version it was built on until its rebuild is scheduled. Subdomains inherit the parent domain's version unless you set theirs separately, so a change on the main site reaches its subdomains by default.

Mixed versions are a staging post, not a destination — every site still on an EOL line is carrying risk, so schedule the stragglers. When everything is current, keep it that way: ask the host when a new PHP line lands on your server and test each site once. The Plesk hosting plans ship current PHP lines per domain, so the baseline is already there.