If you’re using CloudFlare to host your DNS, there is a plugin for the official Let’s Encrypt client Certbot you can use to easily acquire and renew wildcard certificates from Let’s Encrypt.Continue reading “Wildcard certificate from Let’s Encrypt with CloudFlare DNS”
Recently DigitalOcean released new pricing plans where they basically doubled the RAM for the same price of the old plans. But to get the benefits for your existing droplets, you have to upgrade all of your existing droplets in a process that involves shutting them down, selecting the new plan, waiting for the upgrade to happen and power on the droplets again. I have tens of droplets and had no intention of doing this manually, so I wrote a script to use the DigitalOcean API to automate a mass-upgrade of all droplets.
For 20 years or so, there has been the debate over whether you should use www or not in your web site’s canonical hostname. So should you use www or not?
Nginx is an extremely efficient and quite flexible web server. When you want to do a redirect in Nginx, you have a few options to select from, so you can choose the one that suits you best to do an Nginx redirect.
Continue reading “How to do an Nginx redirect”
Let’s install an SSL-certificate from Let’s Encrypt for Nginx.
Running a real cronjob is much more reliable than WordPress’ built-in “maybe-will-trigger” solution. But if you’re running a multisite network, you have to add a crontab entry for every site you set up – which is tedious. Thanks to WP-CLI, we can use a small bash script instead, which will run all due events for all sites for us. Oh, and it works for single sites as well.Continue reading “Run all due cron events for WordPress with WP-CLI”
Depending on your time zone, PHP 7 was finally released on 3rd/4th of December 2015. Even though the general recommendation for production servers is to wait for a little bit and gather some experiences before upgrading, some of us want to jump right on and upgrade to PHP 7.
Security vulnerabilities are often exploits of software that fails when trying to deal with unexpected input. Other times they are exploits of a misconfiguration or a service that unintentionally was open to the public.
For the above reasons, we should limit as much as possible what services are exposed to the public and limit as much as possible what they do and accept from the visitors. To follow those security principles, we should only allow the HTTP methods for which we, in fact, provide services. Under all normal circumstances, that would be the methods
In your WordPress site, there are directories that include PHP files that visitors should never be able to access directly. They are only there for WordPress to function as an application that runs on your server. But because of WordPress’ directory and file structure, they are kind of accessible to the public. All of them are meant to be part of a larger application – WordPress, that is – and should not cause any harm if called directly – that we know. Some of the files execute some code even when ran standalone. An attacker might know of a clever way to make that code run in an unexpected manner, causing harm. To be on the safe side, we should deny access to all these PHP files from the outside world. Since we block access to them in our Nginx configuration, PHP will still run them as usual and WordPress will work just fine.
If you have a static IP address, like from your office, or your own private VPN, you can increase your security tremendously by restricting all logins to that IP address. The effect is that even if an attacker knows your login credentials, they will not be able to log in or access any part of the WordPress Dashboard.