The phpinfo() test that saved the support queue

The phpinfo() test that saved the support queue

The hosting support team had a rule that seemed sensible on paper: if a customer opened a ticket about a PHP error, the first response would check which version the site was actually running. Simple. Logical. And completely unsustainable.

By late 2023, that single category of ticket—PHP version mismatches—was consuming nearly forty percent of the team’s daily queue. The pattern was always the same. A customer would migrate a site or update a plugin, the site would throw a white screen or a 500 error, and the ticket would arrive with a title like “site broken after update.” The team would log in, check the PHP version, find it set to something older than what the code required, flip a switch, and close the ticket. Repeat forty times a shift.

“It wasn’t that the customers were wrong to ask,” says Tobias, a senior engineer who helped redesign the workflow. “It was that the resolution was always the same thing, and the customer could have done it themselves in the time it took to write the ticket.”

The change that followed wasn’t about being less helpful. It was about being more useful. The support team stopped treating tickets as the first step and started treating them as the last resort. What emerged was a diagnostic framework that any site owner—regardless of technical comfort—could run through before ever opening a support ticket.

Confirm what’s actually running, not what’s sitting in the panel

Most hosting control panels display the active PHP version somewhere on the dashboard. cPanel puts it under “Software” or “Select PHP Version.” Plesk tucks it into “PHP Settings.” The trick is that “default” and “active” are not the same thing.

A site’s root directory often contains a file called .htaccess or a php.ini that overrides the server-wide setting. A customer might look at the control panel, see PHP 8.1 listed as the default, and assume that’s what the site is using. In reality, a leftover .htaccess directive from an old migration could be forcing the site to run PHP 7.0 without warning anyone.

The fastest way to know for sure is to create a simple PHP file that runs the phpinfo() function. Upload it to the site root, load it in a browser, and the output will show exactly which version is executing that request. The team found that roughly half the tickets they closed could have been avoided if the customer had done this one step first.

The error log says more than the customer does

The error log is where PHP announces exactly what it can’t do. A 500 error or a blank white screen means something failed, but the failure message itself is almost always recorded.

Most hosting panels have a dedicated “Error Log” section. cPanel lists it under “Metrics.” Plesk stores it under “Logs.” If the panel doesn’t show recent entries, the log file itself is usually accessible via FTP at a path like /home/username/logs/error.log or /var/log/apache2/error.log for more hands-on setups.

The common thread across PHP version mismatch errors is a message containing “Compile Error” or “Fatal Error” followed by a function name that doesn’t exist in the active version. A function like str_contains() works in PHP 8.0 and later but throws a fatal error in 7.x. A site running on an older version will produce that exact line in the log every time it tries to load.

“A lot of customers would tell us the site was ‘just broken’ without checking what broke,” Tobias says. “But the log always tells you. You just have to look.”

Temporarily killing the plugin that’s causing the crash

When the error log points to a specific file—typically something in /wp-content/plugins/ or /wp-content/themes/—the next step is to figure out whether that component actually requires a newer PHP version than what’s active.

WordPress itself publishes minimum PHP requirements on its official documentation page. As of late 2024, the CMS recommends PHP 7.4 or later, though many popular plugins have moved to requiring 8.0 or even 8.1. WooCommerce, for instance, officially dropped support for PHP 7.3 in version 8.0. Elementor requires PHP 7.2 as a minimum but recommends 7.4.

The mismatch usually shows up when a plugin update ships with code that uses modern PHP features—named arguments, match expressions, readonly properties—that simply don’t parse in older versions. The plugin developer assumes the host is running something recent. The host’s default is still PHP 7.4. The site breaks.

The cleanest test is to temporarily disable the suspected plugin or switch to a default theme. If the site comes back, the problem is confirmed. Many customers resist this step because they don’t want to lose their site’s appearance or functionality during testing, but a five-minute disruption is better than a day-long ticket queue.

Flip the version, then wait for the reload

Once the required version is identified, the fix is usually a few clicks in the control panel. Most modern hosting dashboards let users select a PHP version per domain or per subdirectory. cPanel’s MultiPHP Manager allows changing the version for a specific account without affecting other sites on the same server.

The critical detail that catches people: PHP-FPM (FastCGI Process Manager) needs to be restarted after the version change. Some control panels handle this automatically. Others don’t. A customer who switches from PHP 7.4 to 8.1 and still sees the same error might not have waited for the service to reload.

A quick check after the change: re-run the phpinfo() test from step one. If the version at the top of the output matches what was selected, the change took effect. If it still shows the old version, something else is overriding it—usually a .htaccess directive or a cached opcode.

The extension that vanished after the upgrade

This is the one that catches even experienced site owners. A PHP version change doesn’t automatically install the same extensions that the previous version had. A site that relied on the ionCube Loader extension on PHP 7.4 might find that extension missing on PHP 8.1. Same for SourceGuardian, or certain custom PHP extensions that the host installed manually for the old version.

The phpinfo() output from step one lists all enabled extensions in a dedicated section. If the site is running the correct PHP version but still throwing errors, the missing extension will show as a function call to something that isn’t loaded—like a call to an ionCube-encoded file without the loader present.

The support team found that about fifteen percent of “PHP version” tickets were actually about missing extensions, not the version itself. The customer saw the error after changing versions and assumed the change was wrong, when the real fix was to request the extension be installed on the new version.

When to open a ticket anyway

There are legitimate reasons to contact support. A customer who has run through the five steps above will always get faster service than someone who hasn’t, because the engineer receiving the ticket already knows the context.

“A ticket that says ‘I checked the error log, it’s a compile error on line 42 of this plugin file, and I need PHP 8.1 enabled on my account’ is a two-minute ticket,” Tobias says. “A ticket that says ‘my site is broken’ is a thirty-minute ticket, because we have to start from zero.”

The team still answers PHP-related questions. They just shifted the expectation: customers who did the diagnostic work first got priority handling. Customers who didn’t got a link to the diagnostic guide and waited in the queue.

The sixty percent drop that stuck

The support team’s internal data showed that the change reduced PHP version mismatch tickets by about sixty percent within three months. The remaining forty percent were cases where the customer genuinely couldn’t solve the problem alone—a server-level configuration issue, a missing extension, or a hosting account limitation that required an engineer to touch the server directly.

A site owner who learned to check the error log and run phpinfo() in 2023 was unlikely to open a ticket for the same problem in 2024. The ticket queue still fills up. It just doesn’t fill with the same question forty times a day anymore.

📷 Photos: Compagnons (Unsplash), Mathurin NAPOLY / matnapo (Unsplash)