Avoiding Blank PHP Responses after upgrading to Ubuntu 16.04, and php7.0-fpm

Earlier this week I finally made the plunge to upgrade my VPS to Ubuntu 16.04. With a minor hiccup surrounding supervisord (which I probably can avoid if I go the systemd route) not being enabled at boot, the upgrade was simple for both my WSGI and Node webapps.

I can not say the same thing about my WordPress/PHP installations. (Installations that I hope to transition off to Rookeries once that software becomes more stable.) It took me a few hours to track down and resolve the problems. Hence I am posting this article, to hopefully save someone else’s time when they do the same upgrade.

Upgrading to PHP 7.0

Ubuntu 16.04 makes the switch away from PHP 5 to PHP 7. So I had to switch to php7.0, php7.0-fpm, and php7.0-mysql from their PHP 5 equivalents. The location of the running UNIX socket has changed from /var/run/php5-fpm.sock to /var/run/php/php7.0-fpm.sock, as did the PID files.

Updating the PHP-FPM configuration

Running WordPress using FPM (Fast Process Manager) and NGINX, requires turning off the path translation in php.ini file. This can be done by uncommenting the line cgi.fix_pathinfo=0 found in the configuration file /etc/php/7.0/fpm/php.ini. Again these files have moved from the old location. After you’ve done this remember to restart the FPM service using the new systemd utilities: sudo systemctl restart php7.0-fpm.

Updating the NGINX configuration and Solving the Blank Response

This is the tricky part. After updating my NGINX configurations to the new UNIX socket path, and restarting NGINX, I found that I got blank PHP responses. Everything else worked, expect that any PHP page would not render. And not render by not rendering any content in the body of the responses. That led me down a few rabbit holes, and researching how to re-architecture my setup using Docker. Eventually I stumbled across a blog entry with the solution to the blank PHP response issue.

In a nutshell, with the NGINX upgrade one of the parameters needed for FastCGI went missing namely the fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; bit. Oddly this parameter appears in /etc/nginx/fastcgi.conf and not the /etc/nginx/fastcgi_params file that I normally include in my NGINX configs. Anyways after adding this line and restarting NGINX using sudo systemctl restart nginx everything worked correctly. Below I’ve included a sample NGINX configuration that should work.

Sample NGINX Configuration /etc/nginx/site-enabled/example-site.conf

server {
server_name .example-site.com;
index index.php;
root /srv/www/location_of_wordpress_install;
listen 80;

access_log      /var/logs/nginx/site-access.log;
error_log       /var/logs/nginx/site-error.log info;

location / {
    try_files       $uri $uri/ /index.php$args;

location ~ \.php$ {                        
    fastcgi_split_path_info     ^(.+\.php)(/.+)$;
    fastcgi_pass    unix:/var/run/php/php7.0-fpm.sock;
    fastcgi_index   index.php;
    fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
    include         fastcgi_params;

location ~* \.(js|css|png|jpg|jpeg|gof|ico)$ {
    expires         max;
    log_not_found   off;


The Joys of Seamless Upgrades

Upgrades often is a naughty word in programming and system administration.  When a system admin or programmer starts an upgrade, often it is with clenched teeth and an expectation something will break, explode or spontaneously combust.  So congrats to the WordPress guys for releasing another seamless, non-breaking, and easy to do upgrade.  And yes this blog now runs on the latest greatest WordPress 2.8.6.

Now if only upgrading my Drupal sites could be as simple and trivial.

Upgraded to WordPress 2.8

I am continually amazed by the ease of working with WordPress.  Not only do the themes and plugins just work, so does everything else.  I upgraded my WordPress install to the latest and greatest 2.8 .  Simple, clean and issue-less upgrade.  This is how technology should work.  Get out of the way and perform the tasks the user needs to do.  And perform the tasks quickly, efficiently and perfectly everytime all the time.

In addition to that, I can proudly say that less than 20% of the older blog entries remain “Uncategorized”.  I plan on tagging, categorizing and editing the remaining entries.  With any luck, I have this blog configured perfectly before my upcoming birthday.  Hurrah!

Do You Really Think I Study???

Many people still believe students study before exams. Right… Some students still believe they should. I, however join the ever-increasing ranks of slackers and non-studiers. That said, I will look over my notes, before taking the exam. My definition of studying… kind of unconventional.

My rationale? If I did zero work the entire semester, I sure am not going to learn anything in a single night. So instead I read over my notes. And do other things.

Today, I foolishly decided would be reinstall-Ubuntu day. Most of the morning and a good part of the afternoon consisted of backing up and reinstalling. I tried installing the newest Kubuntu. Alas, it refused to accept a JFS root directory. I wanted JFS, cause I like a fast, responsive file system. Not like Reisers which is fast and crashes hard. Not like XFS that runs like if every machine was a six-million dollar rack with more RAIDs and CPUs then a centipede has legs. And ext3, thats an ancient system… old but reliable. Still old though. After jousting with Kubuntu Edgy Eft, I popped in my Ubuntu Dapper Drake and decided to go the upgrade route.

So I am sitting right now, 30 minutes into an upgrade, copying back my backed up data, one DVD at a time. When I am done the copying, I will study. Right…