Website not accessible when on PHP-FPM of newly installed PHP version

OS type and version CentOS 7
Virtualmin version 2.001

I have just installed PHP 7.4 following the guidelines provided on Multiple PHP Versions – Virtualmin.

But when I change the PHP version for the main site of my virtual server to 7.4 (under PHP options), I can only see a blank page when trying to access it. Using developer tools (web browser), the frontpage gets a 200 OK status from server, but the response is completely blank.

Some additional info:

  1. When I change the PHP script execution method to FCGId, the website loads correctly.
  2. When I change the PHP version of the website to PHP 7.2 (which is installed by default in Virtualmin), then it loads correctly (even with PHP-FPM selected as script execution method).
  3. Both FPM selated services on systemd (php-fpm.service and php74-php-fpm.service) have active (running) state.
  4. I have a sub-server (another website) configured on this same virtual server, and it loads correctly under the new PHP version (when changing it under PHP options of the sub-server), even with PHP-FPM execution method selected.
  5. The error log (under /var/log/virtualmin) of the virtual server gets no additional entries when trying to access the website. The access log only receives entries when trying to access the other website (configured as sub-server on the same virtual server, as explained on item 3).

So the issue is related strictly to PHP-FPM for the newly installed PHP version (7.4), and only on the main website (the sub-server website loads correctly).

Any ideas how I should troubleshoot this?

Thank you in advance for any support!


You may be missing modules for php 7.4.

@tpnsolutions ,

Attached is the list of PHP modules installed for version 7.4.

Some important notes:

  1. When I run “re-check configuration” under system settings, in one of the lines it lists correctly the new version available for FPM-PHP.
  2. As previously said, the service php74-php-fpm.service shows active (running) state.
  3. As previously said, another website (configured on the same virtual server as “sub-server”) loads correctly even with FPM-PHP version 7.4 selected.

So for me, it doesn’t seem to be a “module missing” issue.

The first thing I would check for would be short tags in my php ( <? instead of <?php ). More recent PHP versions are also less tolerant of missing quotation marks ( for example, $_COOKIE[PHPSESSID] instead of $_COOKIE['PHPSESSID'] ).

It could also be a database call that’s not supported in current MariaDB, or a syntax error in a call.

In short, any PHP error that the previous PHP version ignored (or in the case of short tags, was set to ignore) could cause newer PHP to vomit, causing Apache to render a plain, white, blank page.

Or more bluntly stated, when the page is blank, the problem most likely is in your code.


@RJM_Web_Design ,

Thank you for your explanation. But I don’t think I have yet to start doing this type of troubleshooting.

Some additional background on my post: I am trying to migrate my 2 sites from a cPanel account to Virtualmin. So I’ve used the Virtualmin “migrate virtual server” tool for cPanel accounts, and have since tried to solve all issues that appeared before “shutting down” the other server where both sites are currently live.

Under this cPanel account, both sites (using Wordpress) are already running on PHP 7.4, and PHP-FPM is the script execution mode there. So I don’t think that the current PHP code is not compliant with PHP 7.4. The only difference between my current stack (live sites on my cPanel server) is that I am migrating to MariaDB (instead of MySQL) in Virtualmin. But as far as I know, there should be no issue with this change. And as already explained on previous messages, the site already loads correctly on PHP 7.4, as long as I don’t choose PHP-FPM as script execution mode.

Doesn’t cPanel implement kludges to smooth out incompatibilities due to deprecation in newer versions of PHP? It could be that they enabled something like allowing short tags in php.ini. Virtualmin doesn’t reproduce non-standard modifications like that (you can enable most of them yourself, however, though I personally wouldn’t advise it).

Also, “WordPress” is actually a mix, not a monolithic entity. All it would take is one piece of deprecated PHP in, for example, a theme file or plugin to crash the whole site.

All I can say with certainty is that I’ve been coding in PHP for more than 20 years, and I’ve yet to come across a blank page that wasn’t due to something that I messed up or overlooked in the code.

What does the error log say? That’s probably where this quest should have started.



Is there anything in the “error_log” when you are experiencing the issues?

I started to troubleshoot from the Wordpress side, looking at the Wordpress error log, and then the root cause was very clear: there were some tables missing within the database. So in the end, it had nothing to do with PHP versions and configuration (what I thought was the issue when creating this post). I think in one of the sites, the missing tables were not necessary to render the front page, whereas on my main site it couldn’t load it (after changing from PHP 7.2 to PHP 7.4).

I remember that when I was migrating my cPanel account to Virtualmin, no errors were shown when importing the databases, I even installed phpMyAdmin on the server, and at a quick glance I didn’t realize that some tables were missing.

So I had to manually import my databases, and while doing that, some tables could not get imported because of “unknown collation utf8mb4_unicode_520_ci” (probably it has to do with migrating from MySQL to MariaDB directly). So I had to replace this collation with utf8mb4_unicode_ci and then the full migration of database took place (using phpMyAdmin built-in import function).

After that, the main site could load correctly under PHP 7.4, without any errors.

Conclusion: Maybe the Virtualmin developers could improve the cPanel migration script to throw some error message when some tables within the databases fail to be migrated.

1 Like

This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.