Choosing a PHP version per site without breaking the network

PHP Selector lets each account choose its own PHP version and its own set of extensions, independently of the server default and independently of every other account. On a network built over several years, this is what keeps an old site alive without holding the new ones back.

The situation it exists for

Networks accumulate. A site built four years ago runs a theme that has not been touched since, and it breaks on a modern PHP release. A site built last month wants the newest version for speed. On a server with one global PHP version, those two requirements are in direct conflict and somebody loses.

Per account selection removes the conflict. The old site stays on the version it works with, the new one runs current, and neither decision affects the other.

How to choose a version

1. Default to the newest version your software supports. Newer releases are meaningfully faster and receive security fixes. For WordPress this is usually the version its own requirements page recommends, not the oldest one it tolerates.
2. Change one site first. Never sweep a version change across a whole network in one action. Pick the least important site, move it, use it for a day, then continue.
3. Watch the error log, not the front page. A site can look perfect while filling the log with deprecation notices that become fatal errors in the next release. The log is the early warning.
4. Write down what is pinned and why. A site left on an old version for a reason nobody remembers becomes a site nobody dares to touch.

Extensions are per account too

The extension list is selectable alongside the version. Two points are worth knowing:

• Enabling extensions you do not need costs memory in every process. On an account with a modest memory ceiling, a long list of unused extensions is a real cost.
• A missing extension usually shows up as a specific feature failing rather than the site going down, which makes it easy to misdiagnose as an application bug.

The trap on a multi-site network

Sites in the same account share the same PHP version. If you have placed several sites in one account and one of them needs an old release, you have just pinned all of them. When you plan the layout, treat the PHP requirement as one of the grouping criteria alongside traffic and ownership.

This is the same reasoning that decides which sites share an account at all, covered in Network Planning. Sites with genuinely different platform needs are usually better off separated, and separation is cheap when each site already has its own dedicated address.

Before and after a change

Two minutes of preparation prevents most of the trouble:

• Take a backup first. Version changes are reversible, but a broken site plus a stale backup is not a good afternoon.
• Know your rollback. Switching back is a single selection, so the risk is time rather than data. Make sure you know where the setting is before you need it.
• Check scheduled tasks. Cron jobs that call PHP directly by path can keep using the old binary after the site has moved. They are the most common thing left behind.
• Clear the cache. Opcode and page caches can serve pre change output for a while and make a successful switch look like a failed one.

The component reference is at docs.cloudlinux.com. If a version change is part of a larger move onto our platform, the sequencing is in Moving In, and the caching layer that usually matters more for speed than the version number is in Speed and Caching.