Leaving WordPress, going to static HTML

Ok, it’s not me in general leaving WordPress an going back to static HTML. But sometimes there is a need exactly for such. Static HMTL will out of the box always be superior in terms of page performance. And as well in terms of security no matter which CMS we look at. But in this case it wasn’t about speed or security (well a bit). But the need to preserve content that was created and financed by public money.

The story why leaving WordPress in favor of static HTML

Back in 2019 the organization of the annually Comic-Salon in Erlangen for 2020 kicked off and COVID kicked in. One specific topic would have been the apparently very vibrant comic scene from the Democratic Republic of Congo (DRC). Invitations were already given out to local artists to visit Erlangen and now everything should go down the drain? The plan was to postpone the topic to the very first Comic-Salon after COVID. To keep the topic alive meanwhile a blog was created..

The original WordPress site

The requirements were quite something:

The blog should be run in three languages (german, english, french).
It had to be blazing fast as internet in DRC is limited and expensive.
all rules about accessibility (a11y) had to be applied as the customer was a public authority.
A design done by an agency had to be translated into code.
For the ease of working Gutenberg and it’s possibilities at that time (reusable blocks, custom blocks, patterns) was a given.

Long story short: everything was achieved. By the planned day for the now cancelled Comic-Salon 2020 the blog “Popular Images” went online. The development took only six weeks from contract to go-live. A very big shoutout to my team that did an amazing job to deliver in time. And also to the project managers Rainer Hertwig and Stefan Becker in Erlangen. Rainer’s input about a11y was invaluable. Stefans tight decision making was essential for us to fast progress the development of the site.

EOL of a website

Fast forward to 2022 – COVID is over, travel restrictions that prohibited the visit of the Congolese artists didn’t apply anymore. With some final posts about the event the website basically lost it’s purpose. To keep the content nonetheless, some decisions had to be made:

Option 1: keep it as a WordPress installation and invest in continuous maintenance. The site was already maintained from the go-live date to keep it updated and secured. Also regular renewals of subscriptions for tools like Multilingual Press and another plugin for a flip-book would be needed. OR
Option 2: freeze it into static HTML that doesn’t need any maintenance at all but lose some interaction on the site (comments e.g.)

The interaction with the side already faded after the event mid 2022. As the page needed to be kept for archive purposes only, option 2 was chosen. Which meant that some dynamic features like the before mentioned flip-book, the search and the commenting would be dropped.

The technical part to convert a WordPress site to static HTML

I already transformed smaller projects with the plugin “Simply Static” very seamlessly. My assumption was that it will do so with this site as well and as easy as it can get. Developer rule no. 1 came into place: “Never make assumptions!”. To cater for the multilingual part the choice in 2020 was Multilingual Press 3 (MLP3). MLP3 by design requires a multisite installation. In this case it was setup in subdirectories https://popularimages.org/de/, …/fr/, …/en/. My guess would be that a subdomain installation might have been slightly more complicated that the subdirectory setup already was. But again: that’s just a guess. Thankfully Patrick Posner the author of Simply Static came to my rescue and guided my in how to get the most of it. Thanks Patrick!

Preliminary operations

It still took some iterations to optimize the outcome. Needless to say: to keep everything untouched on the live site a new development environment was setup by copying the complete site with Duplicator to another server. The very first task was to get rid of all plugins that don’t contribute anything tho the frontend rendering. This included also caching and image optimizer plugins. The rules that WP-Rocket and Imagify had created, would later be added manually to the .htaccess file.

The mentioned flip-book was substituted by gallery blocks to keep the pictures as such, but just the animation of turning pages was dropped. As this feature was used on only a few posts it wasn’t a too big compromise. Same applied for the Search which was part of the menu which was adjusted accordingly.

Finally the commenting was switched off. By this you get rid of the comment form at the end of every post, but keep comments that were already submitted. Some plugins that switch off comments will do this for the complete section. This will keep the comments in the database but won’t show them in the frontend!

The actual transformation from WordPress to static HTML

The settings of Simply Static needed the inclusion of the subfolders for the language versions to make sure the complete site would be transformed and exported.

Post production

Due to the multisite some limitation still there. Especially the redundancy of media files that are kept for each language version had to be addressed. Multiple version of the same file would just use webspace on the server. All images were transferred to one simple folder structure, following the WordPress nomenclature of /wp-content/uploads/year/month/. A simple regular expression (regex) to tweak the links containing /wp-content/uploads/sites/"no"/year/month/ to take out /sites/"no"/ was applied. In the same step /wp-content/ (it’s no longer WordPress, isn’t it?) could be replaced it with a simple /assets/. Of course the folders had to be renamed accordingly.

The folders “/feed/”, “/wp-json/” and the file “wlwmanifest.xml” were deleted as they don’t add anything to the site. Another regex to cater for the different language versions was created to delete the links in the header pointing to these files and folders.

The permalinks for the custom post type “Artists” (“Akteure” in german, “Auteurs” in french) were not transformed properly, but came out as /post.php?post="IDNo” – not sure if I made something wrong or if this might be a limitation of Simply Static, but nothing that a bit of some more regex couldn’t solve. Did I mention BBEdit – my favorite code editor? The Multi-File Search with the bespoke regular expressions^* saved a lot of time.

^* full name, because: what’s the plural of regex? regexs? regexess? regrets?

Some simple search and replace could be applied to get rid of the generator meta or some comments within the code that otherwise would just increase the file size. But this was already beautification of the code.

My biggest learnings in this journey

It already helped me a lot that I build websites in the mid 90’s from scratch and static. The understand of HTML is still needed if you want to have a good outcome. The automation tools have their limitations, some manual reworking will always apply that requires HTML/CSS/JS knowledge. I admit my knowledge of JS is too limited. With some more maybe even the flip-book could have been saved.

Especially where AJAX and JSON is involved all page grabbers (Simply Static is basically nothing else) have limitations. Some iterations with wget/curl and several online and offline page grabber tools didn’t have a better outcome. Another site I examined for the same reason of archiving was heavily relying on “Ultimate Member” and already simple shortcodes to list members comprising of a lot of AJAX and JSON will fail to be grabbed.

Still: whenever WordPress has come to an end and a static page is wanted SimplyStatic is my number one tool to choose.