nginx redirecting http requests to https

If you have your nginx server setup with valid SSL certificates to support https, you can redirect all http incoming requests to https with a simple 301 ‘Permanently Moved’ response to the client.

Returning a 301 is considered best practice for enforcing an http to https upgrade.

This post covers this approach, which involves configuring a server block for port 80 to always respond with a 301 response including the https url:

server {
    listen 80;
    listen [::]:80;
    server_name www.example.com; 
    return 301 https://www.example.com$request_uri;
}

The example config in the above article also shows how to redirect first to your server defined with no subdomain, and then additionally redirect from the request with no subdomain to your www subdomain, e.g from http://www.example.com to https://example.com then to https://www.example.com. Apparently the way nginx caches server names there’s performance advantages to redirect to a no-name subdomain first. Redirecting directly to your www subdomain obviously still works too.

WordPress migration complete! (From OpenShift Online to a VPS)

If you’re reading this then I’ve successfully migrated this WordPress site from Red Hat OpenShift Online to hosting in a Virtual Private Server (VPS). I had a rather long list of tasks for the migration, including:

  • Exporting content from the old site and importing to the new
  • Re-issuing my SSL certificate and installing on the new server
  • Updating my DNS config
  • Unassociating my deployed app on Openshift with my domain name / alias
  • Installing my WordPress plugins, such as reCAPTCHA, view counter, the importer etc

I’m probably still missing some minor config items, but at this point I think I’m far enough to make the switch, so the site is now live on my new VPS hosting.

Given that I’m only running on a 2 core, 512MB RAM VPS, the new site is surprisingly snappy, and dare I say it, noticeably quicker than when it was running before on OpenShift Online? I’m sure I’ve still got plenty to tweak and configure, but so far so good, and I’m pleased with the transition!

Manually disabling WordPress plugins

If you’re adding new plugins to your WordPress site, depending on the plugin type you can end up with your site being inaccessible if the plugin configuration is wrong. A good example is adding Google’s reCAPTCHA plugin. If you activate the plugin but the config is not correct, for example if your site id is not matching your domain name, AND if you’ve added the reCAPTCHA on your login form, you can end up in a position where you’re completely unable to log on to your site.

Luckily if you can ssh into your server, you can disable a plugin easily by just removing or renaming the plugin folder, for example in your wp-content/plugins folder.

More info in this article.