Static HTML Served WordPress From Raspberry Pi

It has been quite some time since my last post, in no small part due to the unreliability of the Raspberry Pi running WordPress. I implemented several of the optimizations mentioned around the web to speed up the Pi's performance:
1. Quick Cache WordPress plugin,
2. Running Linux off of a USB thumb drive.
I think the quick cache wordpress plugin made the biggest difference.

The site seemed to run good with these, but there was a deal breaker: creating new pages/posts. MySQL would frequently crash due to auto-saving of the posts, as the posts were being written. Also, at the end of the post, when trying to save it, I would have to be lucky to get the post finally published because it crashed so often.

Time for a change

I was at first planning on taking down the WordPress install completely. Instead, I decided to make it static. This was handily accomplished with the following:

# Waits 5 seconds between requests, # Mirrors whole site lukesnow.no-ip.biz, # stores message log to Output. wget -w 5 -m lukesnow.no-ip.biz -o output.log

The next step was moving the old WordPress installation to a backup folder, and then replacing it with the contents of the mirrored site output by the wget command. I did this, but then the pages just wouldn't load properly. I notice weird "extensions" on some of the pages being served, e.g.: ../index.html@p=168. The problem was that Nginx didn't know what to do with this type of file. I added the following lines to the server block:

location ~* \.(html\@p\=.*)$ { root /srv/http; default_type text/html; }

I believe the \~* tells nginx to look for a case insensitive match, and then the following regular expression tells nginx to match all files ending in *.html@p=..., where ... is any expression at the end. The root directory is just that; next, I had to specify that the default mime type was html.

Issues

There was another tweak that had to be made. For some odd reason, I had set the default type to application/octet-stream. While the WordPress install had worked fine with this, the static page version of WordPress didn't like it. I changed the default type to text/css (in the http section).
Also, at some point I was getting errors like "...style.css" not found, while debugging from within the Firefox Browser (thanks to my brother Matt for helping me figure out the right tool for the job!). I looked for the style.css file, and found that it was named "...style.css@ver=4.0" instead. So I wrote this little script to simply make a copy of all .css files having this issue, and rename them without the @ver=4.0 (starts from http/ directory):

#!/bin/bash

# Next for loop: debug...
# Takes input: ./http/wp-content/themes/twentyfourteen/style.css@ver=4.0
# Echos : ./http/wp-content/themes/twentyfourteen/style.css
# for fl in \$(find ./http/ -name "*\@*ver*"); do echo \${fl%%\@*}; done

# Now, instead of just echoing, makes a copy without the @ver=4.0:
for fl in \$(find ./http/ -name "*\@*ver*"); do
cp \$fl \${fl%%\@*};
done

Success

At this point, the statically served page was working great, as you can hopefully see now. My overarching plan for continuing to use WordPress was to move the WordPress installation to my Ubuntu Linux desktop (costing \$90/year to run, see the post on the kill-a-watt) for publishing, and then use wget to generate static pages, pushed to the Raspberry Pi for serving (\~\$3.50/year!). I had tried several WordPress plugins for generating static sites, but none of them seemed to cut it.

This was a rather long and involved process, and probably shouldn't have been as hard as it was for me. I eventually found that the problem was with my nginx.conf file, in that I hadn't properly defined the mime types... I had this:
DIDN'T WORK:
include /etc/nginx/mime.types;
GOOD (change to this, placed in the http block):
include mime.types;

Conclusion of the Matter

I now have WordPress up and running on my Linux desktop, and can also serve static WordPress pages on my Raspberry Pi. I am not sure if I will continue with WordPress, and the hassle of publishing on the Desktop, then pushing to the Pi, or abandon WordPress for a flat CMS (I have been considering Pico). I would continue to keep the old WordPress blog linked from whatever CMS I go with, if I do decide to change... It is with great Joy! that I run the following on my humble Pi:
systemctl disable mysqld.service
The Pi Is Peppy Again. Thanks for reading! More to follow.

Comments !