Header Image - FOSS adventures

Using Google PageSpeed Insights to speed-up Fossadventures.com

I wanted to optimize the load time of Fossadventures.com. I had performed some tests on Google PageSpeed Insights a couple of weeks ago and my scores were 76/100 for mobile devices and 55/100 for the desktop. The big ticket item was to enable Gzip compression. I researched the subject and the solution appeared to be a simple adjustment of the Nginx configuration (1, 2). Thanks to Nginx and Digital Ocean for the excellent tutorials, which work just as well on openSUSE. My only remaining question was which MIME types to include. I found a nice compact list on Github and based my list on that.

The second suggestion was to optimize the images on the site. I decided to start with the header image, as this was a large image that is visible everywhere. I downgraded the JPEG quality from 85 to 75 and adjusted the Chroma sampling to 4:2:0. I performed a visual inspection of the old and new header image with help of Gwenview. As I didn’t see a big difference, I decided to use this optimized image for the website. I will probably use these settings for all future posts.

The third suggestion was to eliminate render-blocking JavaScript and CSS content. I discovered that my chosen theme (Cannyon) loaded some Google web fonts by default. By disabling this option, the load speed increased even further. Thanks Google for the advice.

I retested Fossadventures.com on Google PageSpeed Insights and my new results are 94/100 for mobile devices and 79/100 for the desktop. That is a solid improvement!

Published on: 14 May 2018

Out with the HHVM, in with the PHP

A regular routine:

systemctl restart hhvm
chown nginx:nginx /var/run/hhvm/server.sock
chown nginx:nginx /var/run/hhvm/server.pid
systemctl restart nginx

This might be abracadabra for many people. But what it means is that once a day, Fossadventures was not available because HHVM crashed. I wondered about the root cause, so I looked into the logs of HHVM. Fatal error! Caused by the WordPress plugin Wordfence. After searching online, it became clear that Wordfence didn’t support HHVM (1) because of stability issues. And that (2) HHVM was no longer supported / tested by WordPress. So I decided to switch to PHP-FPM.

I found a very good instruction (3) on how to do this. I changed the number 5 into the number 7 to get the latest PHP installed. And I needed to adjust the php-fpm.conf file in the /etc/php7/fpm/php-fpm.d/ directory instead of the one in the ~/fpm directory. But that was a lesson I had already learned from the virtual hosts and Nginx adventure.

The second cool thing was the installation of phpMyAdmin. I had already purchased a book on MariaDB (4) which contained a lot of info on command line administration. But having a web-interface that’s displaying the structure of the WordPress database is very neat. It increases my understanding of the overall layout and structure of the database. In fact, I find it so cool that I have now ordered a book (5) on phpMyAdmin as well. Now I just need to find some time to read it.

Over the last few days I have noticed a big change in the stability of Fossadventures. No more restarting HHVM. PHP just works. Out with the old, in with the new.

Published on: 23 April 2018

Let’s Encrypt with Certbot and Firewalld

The next step towards making Fossadventures.com a great website is enabling HTTPS. This was much easier than I expected thanks to Let’s Encrypt and the fantastic Certbot tool. I used this openSUSE instruction page.


Step 1: add the required repo with the command:

sudo zypper addrepo https://download.opensuse.org/repositories/devel:/languages:/python/openSUSE_Tumbleweed/devel:languages:python.repo


Step 2: update the repositories:

sudo zypper refresh


Step 3: install the Certbot application:

sudo zypper install certbot python-certbot python-certbot-nginx


Step 4: run the Certbot application:

sudo certbot --nginx


I needed to answer some basic questions:

  • For which domains the certificates needed to be applied (www.fossadventures.com, fossadventures.com)
  • Whether HTTPS access is required or optional (required)
  • Verification of the DNS records
  • If you want to be added to the EFF mailing list

And “voila” the setup was finished.


Step 5:  update the firewall. I used the commands below. The last command was used to see if the updates were properly applied.

sudo firewall-cmd --zone=public --add-service=https --permanent

sudo firewall-cmd --zone=public --add-port=443/tcp --permanent

sudo firewall-cmd --reload

sudo firewall-cmd --list-all


The final test was to access my website with Firefox… and… success! Wow. That was much easier than expected.

Published on: 10 April 2018

Securing WordPress with plugins

It’s time to spend some attention to the security of this website. From years of reading ICT technology news, I was painfully aware that WordPress websites are a prime target for hackers. And from my initial week of having the website online, I had already discovered a couple of visits from malicious IP addresses in my access log.

The book “WordPress Visual Step by Step for Beginners 2018” recommends installing the Wordfence Security plugin. This is an Endpoint protection solution. Another solution that I had read about was Cloudflare. I was interested in the differences and found this article on the Wordfence website. Biased? Certainly. But I do agree with some of the arguments and decided to install the Wordfence plugin as a basic security measure. I can always add Cloudflare on top of that.

Then I looked for articles on hardening a WordPress website and found these (1, 2) two articles. I really appreciate the blog of WP Engine. A good find was the “WPS Hide Login” plugin, which made it very easy to implement measure #13. The blog by Bjørn Johansen was very helpful in implementing measure #14.

I have disabled Comments on my website. The main goal of my website is to inform and not to interact. Contact Form 7 and Flamingo are plugins that work together to enable the contact form and to store the messages on the WordPress server. This provide readers with a basic way to interact. The nice thing (from a security standpoint) is that I am able to add a “reCAPTCHA” button on the bottom of my contact form. Which should reduce the amount of spam.

Published on: 4 April 2018

Solving Permalinks with Nginx Virtual Host file

After reading the initial 3 chapters of the book Nginx HTTP server – Third Edition, I was ready to tackle the permalinks problem again. I started adjusting the nginx.conf file with renewed knowledge. Something interesting happened when I adjusted the server_name to .fossadventures.com and tested the nginx.conf file. The test indicated that this server name was already in use.

I decided to look for additional .conf files in /etc/nginx. And then found the culprid in the vhosts.d folder. This xxx.conf file contained the configuration of my website. I created a copy “xxx2.conf” and started editing it according to the solution described in my last post. Why not try to create a more pleasing 404 page as well? I copied the Cannyon theme its 404.php page into a separate directory and put the directive to this error page in my xxx.conf file.

Then I stopped Nginx, renamed the current xxx.conf file into xxx.conf.back and renamed xxx2.conf into xxx.conf. After restarting Nginx, my site finally showed pretty permalinks. And best of all, when someone puts in an invalid url, they will see a pretty 404 error page.

Published on: 3 April 2018