Building a Static WordPress

Photo by Vidsplay from StockSnap

Now that I have Nginx in Front of WordPress, I thought the next logic step was to try and hide my WordPress even more. What exactly would this mean? In my mind, I figured that I would restrict access to all of the backend functions of my WordPress site to just my IP Addresses. From there, I would simply serve static versions of the content.

Part of the reason that I can do this is because my site is mostly static. I don’t allow comments or other dynamic plugins. The site is only used to publish my blog posts and that’s about it. I also setup WordPress to use the permalink format of /%year%/%monthnum%/%post_id%/

First Step, Mirror the Site to a Private Repo

Just as the heading states, I needed to first get all of my content available outside of WordPress. Luckily, I realized that I had a few previous blog posts:

that could help me accomplish the initial steps. I won’t completely bore you with the details contained in these posts. I’m going to assume that you can get a basic idea of how to setup the private repo using Creating a Private GitHub Repo. You can setup your repo however you like but for future planning purposes, I decided to create a html directory inside of it to house the website files. My initial repo looked like the following:

 % ls -al
 total 8
 drwxr-xr-x   5 salgatt  staff   160 Dec 31 08:46 .
 drwxr-xr-x  49 salgatt  staff  1568 Jan  7 12:32 ..
 drwxr-xr-x  15 salgatt  staff   480 Jan  7 09:05 .git
 -rw-r--r--   1 salgatt  staff    18 Dec 30 18:57 README.md
 drwxr-xr-x   4 salgatt  staff   128 Jan  5 21:31 html 

With the private repo created, I needed to get all of my content into the repo for later use by Nginx. I just did a wget to pull only the page content down. The reason I did this is because there were a number of js and css files that are required for the admin pages and possibly for other “things” that I might not use right away:

 % cd html
 % wget --mirror --follow-tags=a,img --no-parent https://blog.shellnetsecurity.com
 --2021-01-07 16:37:24--  https://blog.shellnetsecurity.com/
 Resolving blog.shellnetsecurity.com (blog.shellnetsecurity.com)... 157.230.75.245
 Connecting to blog.shellnetsecurity.com (blog.shellnetsecurity.com)|157.230.75.245|:443... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 17266 (17K) [text/html]
 Saving to: ‘blog.shellnetsecurity.com/index.html’
 

 blog.shellnetsecurity.com/index.html       100%[=======================================================================================>]  16.86K  --.-KB/s    in 0.09s   
...
 --2021-01-07 16:37:41--  https://blog.shellnetsecurity.com/author/salgatt/page/2/
 Connecting to blog.shellnetsecurity.com (blog.shellnetsecurity.com)|157.230.75.245|:443... connected.
 HTTP request sent, awaiting response... 200 OK
 Length: 41746 (41K) [text/html]
 Saving to: ‘blog.shellnetsecurity.com/author/salgatt/page/2/index.html’
 

 blog.shellnetsecurity.com/author/salgatt/p 100%[=======================================================================================>]  40.77K  --.-KB/s    in 0.1s    
 

 2021-01-07 16:37:44 (398 KB/s) - ‘blog.shellnetsecurity.com/author/salgatt/page/2/index.html’ saved [41746/41746]
 

 FINISHED --2021-01-07 16:37:44--
 Total wall clock time: 19s
 Downloaded: 56 files, 2.7M in 3.4s (821 KB/s) 

My wget command runs the –mirror command to ummm mirror the site. I do the –follow-tags=a,img so that I only nab the html plus images and follow only href tags. Finally, I want to stay within my site and not download any other sites’ content by issuing –no-parent. With that, I now have a blog.shellnetsecurity.com directory in my repo’s html directory.

 % ls -al
 total 0
 drwxr-xr-x   4 salgatt  staff  128 Jan  5 21:31 .
 drwxr-xr-x   5 salgatt  staff  160 Dec 31 08:46 ..
 drwxr-xr-x  18 salgatt  staff  576 Jan  7 08:38 blog.shellnetsecurity.com 

Now, I need to get all of my static content into the repo as well. In order to do that, I just did a simple copy of the static files from my container running wordpress using kubectl cp:

 % kubectl cp -n wordpress wordpress-85589d5658-48ncz:/opt/wordpress/wp-content ./blog.shellnetsecurity.com/wp-content
 tar: Removing leading `/' from member names
 % kubectl cp -n wordpress wordpress-85589d5658-48ncz:/opt/wordpress/wp-includes ./blog.shellnetsecurity.com/wp-includes
 tar: Removing leading `/' from member names 

These copy commands grab ALL files in these two directories. The idea is that I’m grabbing the js and css for any plugins running in my WordPress and any theme related files. Since these directories contain PHP files and other files I don’t need in my static repo, I remove them with a nice little find command:

 % find blog.shellnetsecurity.com/wp-includes -type f -not -name '*.js' -not -name '*.css' -not -name '*.jpg' -not -name '*.png' -delete
 % find blog.shellnetsecurity.com/wp-content -type f -not -name '*.js' -not -name '*.css' -not -name '*.jpg' -not -name '*.png' -delete 

At this point, I now have a repo that should have all of the content ready to go. I commit all of the changes and push the changes to main.

Serve the Static Repo

Like I said before, I’m not going to clutter this post with the details that can be found in Building a Kubernetes Container That Synchs with Private Git Repo. Assuming you have this all ready to go, I’m going to cut straight to the configuration portion. I’m assuming the nginx container is mounting the private repo at /dir/wordpress_static. I am also going to build upon the nginx configmap that was created in Adding Nginx in Front of WordPress. I’m first going to change the root directory to be the static WordPress blog:

         root /dir/wordpress_static/html/blog.shellnetsecurity.com; 

I also need to change some of my original reverse proxy mappings to serve most content from static but still leave a few requests go to my WordPress

         location /status {
                 return 200 "healthy\n";
         }
 
         location / {
                 try_files $uri $uri/ /index.html;
         }
 
         location /sitemap {
                 proxy_pass https://wordpress;
                 proxy_ssl_verify off;
                 proxy_set_header Host blog.shellnetsecurity.com;
                 proxy_set_header X-Forwarded-For $remote_addr;
         }
 
         location /wp-sitemap {
                 proxy_pass https://wordpress;
                 proxy_ssl_verify off;
                 proxy_set_header Host blog.shellnetsecurity.com;
                 proxy_set_header X-Forwarded-For $remote_addr;
         }
 
         location /wp-json {
                 allow 1.1.1.1;
                 allow 2.2.2.2;
                 deny all;
                 proxy_pass https://wordpress;
                 proxy_ssl_verify off;
                 proxy_set_header Host blog.shellnetsecurity.com;
                 proxy_set_header X-Forwarded-For $remote_addr;
         }
 
         location /wp-login {
                 allow 1.1.1.1;
                 allow 2.2.2.2;
                 deny all;
                 proxy_pass https://wordpress; 
                 proxy_ssl_verify off;
                 proxy_set_header Host blog.shellnetsecurity.com;
                 proxy_set_header X-Forwarded-For $remote_addr;
         }
 
         location /admin {
                 allow 1.1.1.1;
                 allow 2.2.2.2;
                 deny all;
                 proxy_pass https://wordpress;
                 proxy_ssl_verify off;
                 proxy_set_header Host blog.shellnetsecurity.com;
                 proxy_set_header X-Forwarded-For $remote_addr;
         }
 
         location /wp-admin {
                 allow 1.1.1.1;
                 allow 2.2.2.2;
                 deny all;
                 proxy_pass https://wordpress;
                 proxy_ssl_verify off;
                 proxy_set_header Host blog.shellnetsecurity.com;
                 proxy_set_header X-Forwarded-For $remote_addr;
         }

Through some trial and error, I found that I needed to have all of the following paths allowed for my admin functionalities:

  • /wp-admin
  • /admin
  • /wp-login
  • /wp-json

Since these are required for admin functions, I have made sure to run my IP restrictions on them and only allow my addresses to access them. For now, I am managing my sitemaps from within WordPress so I also allowed requests from any clients to go directly to my WordPress server still (something I’ll correct in a future post when I talk about automation). Aside from these exceptions, I’m using try_files to find the other content. This means that requests for any other content will be sent into the root directive, aka /dir/wordpress_static/html/blog.shellnetsecurity.com, aka the private repo! Notice the trailing /index.html on the directive? That just means that I’ll serve /index.html whenever the page isn’t found.

With that, I am now serving content from my mirrored content that is running from the private repo. I can still manage my WordPress site like I normally do from the backend and generate content and make changes and life is mostly good.

I am an idiot

Yes, you don’t need to tell me this! I know there are some obvious flaws in what I’ve setup like:

  • What happens when I post a new article?!
  • What do I do when WordPress is upgraded?
  • What happens when a plugin is upgraded?
  • Do you know that doing a wget for just pages won’t download pretty little images?
  • Did you know that serving /index.html for css/jpg/png/js files is ugly?
  • This manual process is terrible!

I know! I have already begun to tackle these and I’ll have more details on that when I write my Automating Static WordPress Updates (Currently in Draft). As a sneak peak to all of this, there’s a really cool WordPress plugin that will send various notifications to Slack. Oh the fun that we will have when talking about using Slack as a message bus and writing and app and and …. ok I’ll contain my excitement for now!