WordPress recently made a few changes to its recommended requirements and now recommends using PHP 7 and HTTPS. I had some time this weekend and set out to upgrade my site and document some of the issues I ran into in the process.
For both of these tasks, I followed the tutorials at DigitalOcean, which were terrific. Even so, I ran into a few snags—some of which were specific to WordPress.
Setting up HTTPS
The first problem I encountered while setting up HTTPS was a result of upgrading my server configuration before changing my siteurl
and home
settings (in Settings > General ). Since WordPress was redirecting requests to the non-HTTPS URL, the server fell into a redirect loop and crashed.
I fixed this issue by using WP-CLI to update the relevant options from the command line, since I was locked out of my admin. I could have gotten this working by defining constants in my wp-config.php
file as well, but it would be nice if WordPress detected this problem and showed some kind of “upgrade your site” page rather than sending 301 redirects.
Another difficulty I ran into was that the DigitalOcean tutorial told me to set the server block to listen 443 ssl;
, when it should have been listen 443 default_server ssl;
. After making that change, I was able to see the site over HTTPS.
The whole process ended up being way easier than I had expected. That said, there were a few things that were broken because of mixed content errors.
Issues I noticed after upgrading to HTTPS
- Chrome blocks oEmbeds and shows an “insecure content” warning in the address bar when the external site is not running HTTPS. It would be nice if WordPress detected this and blocked the embed to avoid browser warnings.
- Images included in previous posts still retain the HTTP scheme, which didn’t surprise me. What was unexpected was that
srcset
attributes—which are dynamically created when the page loads—retained HTTP URLs unless the image was generated from a caption shortcode, which seems odd. - My user account on this site was using
http://joemcgill.net
as the website. It would be cool if this was automatically upgraded when I made the switch to HTTPS, but nothing was broken because of this. - It would also be nice if links to local content within old posts could be upgraded.
I used Ryan Markel’s HTTPS-All-The-Things plugin to fix several of these issues in the mean time (though the oEmbed bug still exists).
Upgrading PHP 7
Upgrading to PHP 7 was also a fairly painless process, save for a dumb mistake on my part, which was kind of funny:
Ha. Then I broke things while upgrading to PHP7. Neat.
— Joe McGill (@joemcgill) December 10, 2016
Turns out I mistyped the location of PHP7.0-fpm.sock
in my nginx config, which crashed my site 🙈.
PHP 7 began working once I fixed my configuration, but the site threw a fatal error because my debug-media plugin called gd_info()
, which wasn’t available. Installing GD fixed this right up and I quickly modified the plugin, which helped me realize that I also needed reinstall ImageMagic to take advantage of cool features like PDF thumbnails.
The JetPack Publicize module displayed an error because I didn’t have multibyte support enabled nor the XML extension for PHP 7. I install those extensions manually and now things seem to be working ok.
Comments
2 responses to “This site now runs on HTTPS and PHP 7”
Howdy Joe,
Just file a bug on Core Group and checking out some Committer’s blog 😉
I just upgrade all WordPress on my server to PHP 7.1 and HTTPS too, I am aware that WordPress had re-direct issue but if you follow DigitalOcean’s how-to and redirect all 80 request to 443 like this, it should not go in to a loop as WordPress is just sending normal 80 request but nginx turn them to HTTPS:
server {
listen 80;
return 301 https://$host$request_uri;
}
And do check if nginx’s location / settings are correct.
For the ssl default_server problem, this is really strange since nginx don’t need to specific the default ssl server, the first configuration file nginx loads will be the default server.
Hi Richard,
Thanks for stopping by. I did have my nginx config set to automatically redirect to 443 so perhaps there were other factors involved. I’ll need to do some more investigation. On the second issue, I have several sites configured in nginx, and this site wasn’t the first loaded. The interesting thing for me in all of this was documenting which roadblocks I ran into while trying to make these upgrades.