The TLDR; I have moved away from WordPress to a statically generated site using a fork of Publish by John Sundell. This post, and two other device availability posts were done using the new workflow.
I came to the realization the other day that I have been building websites for 25 years now, and doing programming, of some sort, for even longer. The tools that I have used to build websites have changed throughout the years. Sometimes it has been tools provided by the website hosting company, like those from AOL, GeoCities, MySpace, Tripod, and the like. Other times it has been something like Microsoft's FrontPage (note, I only used that for work. I never used that on my own site), and yet even other times it was even just creating webpages by hand through the use of Notepad or Notepad++ on Windows, and TextWrangler or BBEdit on the Mac.
However, the modern approach is creating a website is to use a content management system, or CMS. There are a variety of different Content Management Systems available, but the most common CMS today is wordpress.org. According to an article on Tech Radar, WordPress powers 40% of the web. With WordPress you have the choice of either hosting it on your own server or having someone else host it for you. WordPress has its own commercial site for having them host your site available at wordpress.com
Early in my foray into building websites I used hosted solutions, like AOL members, GeoCities, and Tripod. These sites allowed you to build static websites. There had been dynamic languages before, like ColdFusion, but I had not gotten into those. However, the idea of building a dynamic website is one that I did not forget about.
While at my job I needed to find a way of providing a means of easily being able to add and update data to a Microsoft Access database. That is when I started looking at Classic ASP from Microsoft. This worked, but it was limiting in that it had to be used on Microsoft software. Sometime in 2003, or early 2004. I came across a different scripting language called php. PHP can be run on most operating systems, Windows, macOS, and almost every linux distro available today.
Around the same time, the idea of creating a dynamic website was still in the back of my mind. I came across a new type of site called a "weblog", today commonly shortened to "blog" (note, I will die on hill that blog is the encompassing website, and "blog post" is an individual item on a blog). At the time there were only a couple around. The one that I had used was called "pivotlog", which you can technically still download, but I do not recommend it because it has not been updated since 2006 and it likely will not run on today’s modern PHP.
Back in either late 2004 or early 2005, I switched over from pivotlog to WordPress and I have been using that since then. Since I do not know exactly when I switched, let us just say it has been 17 years using the same content management system, so I am not new to WordPress. Let us briefly look at some of the features added to WordPress over the years.
WordPress
WordPress is a user friendly open source Content Management System that provides admins, editors, and contributors an easy way to publish WordPress has undergone a significant number of changes since 2005. Just a few of the additions made to the product include:
- Autosave
- Custom Fields
- Comment Spam blocking
- Widgets
- Drag and Drop
- Custom Menus
- Plugins
- XML-RPC
- Image Captions
- Image Galleries
- Child Themes
This is just a small sample of the features that have been added since 2005. Starting with version 5.0 of WordPress, released in December of 2018, WordPress introduced a whole new editor called the "Block Editor". This took the standard editor and converted into one which you can modify with various blocks. This was an interesting update at the time and it did take some getting used to, but eventually I did get used to it. The "Block Editor" is actually a project called "Gutenberg" and it did allow more people to easily add content to their WordPress sites. Gutenberg is not limited to just WordPress, but can be used on a number of other types of sites as well.
Throughout my time of using WordPress I have consistently updated theme, almost every time that WordPress would introduce a new theme, I would update my site to use that new theme, or a version of it. Sometimes this was easy, other times it was more difficult. But, I have tried to refresh the site’s design over time.
Block Theme
Starting with version 5.9, released in January of 2022, WordPress introduced a new type of theme called a "Block Theme". A block theme is one that takes the concepts of the "Block Editor" and applies them to themes. The first theme with this is aptly named, Twenty Twenty-Two. The themes released by WordPress are designed to be one that show off what WordPress is capable of, but yet still quite practical for most users. I spent a significant amount of time trying to get used to the new theming approach and I was eventually able to build a new child theme based on the Twenty Twenty-Two theme to suit what I needed. The idea of the Block Theme is a good one, in theory. However, over the last 10 months it has not evolved all that much and it does have some downsides.
The first downside is that it does require an new way of thinking, in both of creation of blocks and how to manage changes the site's theme going forward. For many, they will adapt, but when you first start using the Block Theme interface, is not all that intuitive, at least it was not for me.
The second downside is that there are a lot of extra icons added. As an example, on my WordPress theme there were 12 different SVG icons added that did not really serve much of a purpose. I did not have this with previous themes. It is possible that I am doing something wrong, but I suspect that may not be the case.
The third downside is that there is a lot of inline styling with block themes. For most people this is probably best, but I prefer to have a vast majority of the CSS in a single place, because it makes it so much easier to keep up to date.
Beyond this, WordPress in general adds a bunch of extra markup, in the form of comments, around WordPress specific items, like blocks, figures, galleries and the like. While these comments do not have any impact in terms of functionality, it does add some additional content that needs to be transmitted for each request. Again, in the grand scheme this is not a lot of data on a per-page basis, but in the aggregate it can be add up.
All of that is to say that I am moving away from WordPress and going to a statically generated site.
Reasons for Moving Away from WordPress
There are a number of different reasons that I am moving away from WordPress.
Constant Updates
WordPress has its core set of features and when you are just getting started, this may be enough. But over time you will likely want to add additional functionality. This is accomplished through what WordPress called "plugins"". There are some plugins, like Akismet and Jetpack, that are created by WordPress themselves. However, a vast majority of the plugins are done by third-parties. Each additional plugin that you add is another item that you have to update. More than once in my history of using WordPress, I have had an update to a plugin either significantly change the way things were done, or I have it had mess up my site entirely. The latter has not happened much lately, but it has happened.
Even with the handful of plugins that I have enabled, there are still constant updates. Yes, you can enable automatic updates, but I do not enable them due to the sheer number of times that I have had issues. What this means is that I need to constantly be checking for updates and this process can take down the website for a short period of time. Most updates are very quick, but some (I am looking at you Gutenberg Editor and Jetpack), can take a lot longer.
Issues with the Block Editor
Over the last couple of years the block editor has become increasingly problematic for me. Not in the fact that it exists, but in the fact that I have to keep fighting with it to add new blocks to a post where I want them. As you might be aware I use Macs for most of my computing and my preferred browser is Safari. The primary reason for this is that Chrome and Firefox have long been hogs of resources on the Mac. This may be changing as of late, but the Mac is still mostly an afterthought for both Google and Firefox. Furthermore, I prefer using a browser which will not slow down my system, particularly one that will not bog down the system even when it is not open.
It seems to me that Safari is the last consideration for WordPress and therefore if there are bugs while using Safari, they are either actively ignored or they are just pushed further down the list of items to fix. It is somewhat understandable, but it is bad form for those who prefer to use Safari and Macs.
Updates and Security
As mentioned above, WordPress now powers 40% of all websites on the internet. This means that it has become a significant target for malicious attackers. WordPress is very good about keeping the core, and their plugins, up-to-date with any security fixes. But that is not always the case for third-party plugins. I have been seeing an increasing number of plugins that have had security issues. In most cases the issues are rectified, and other times they are not.
Along with plugins, I go through my website logs from time to time and I see an increasing number of bots who keep trying to use known exploits in wordpress to try and compromise the website, and therefore compromise the server that it runs on.
Loading Speed
WordPress can load very quickly, provided that you are using a content delivery network, or CDN. A CDN will cache a copy of a website geographically close to you, so that it can load very quickly. Even with caching, any dynamic site still takes time to load and render the page. A static site will, by its very nature, be significantly faster than any dynamic site. This is because the only limiting factor for loading a static page is the read speed of the disk on the hosting site and most sites these days are using solid-state drives which are much faster than traditional spinning hard drives.
Usage Changes
Over the course of time the way that I use WordPress has changed. WordPress has the ability to have multiple users, and multiple roles for those users. In the past I have contemplated the notion of having others post to my site, but I came to the realization that this site is my own site. If I were to do another site (there are no plans on doing so), and others were willing to contribute then I would likely look at another CMS.
Another change in usage is when it comes to comments. I used to allow comments on the site, even from registered users, but I disabled them a long time ago due to spam and having to moderate them. Along with this, I used to have a lot more plugins enabled, but I have reduced the number used. Most of the plugins I had enabled were either custom ones I had written for functionality on the site, or ones that were from WordPress itself.
With all of that in mind, let us look at my new site software, starting with the goals I had in mind for a new site
Goals for a new website
I have been thinking about re-working my website for a while and I have been thinking of making it a static site. I converted my old podcast site from a WordPress site to a static site. The reasons for converting that site was that I stopped doing that podcast, so there was no new content. Furthermore, I would not have to worry about updates to WordPress. Because there were no new episodes, it would be a one-time conversion and it was worth the effort to convert it.
For that conversion I simply pulled the data from the database table and then put the HTML of each episode into its own file. This type approach would not necessarily work for this site, because I would need a way of being able to update it regularly. I mean, it could be done, but with an RSS Feed, tagging, and many generated items, this would be an impractical approach, another solution was needed.
There were two primary goals for a new site. One, it must improve speed, which generally occurs with statically generated sites. Two, it needed to be able to keep the structure of the new site to be very similar to the old site. This includes website organization, like posts, tags, and more. The rationale for this was that there are other sites that link back to the old posts, and I wanted to preserve that structure and those links. If it was a dynamic site, I could have added redirection to accomodate a new structure, but this is honestly alot easier.
When I finally made the decision to start looking at various static site generators. I ended up choosing to go with one called Publish, by John Sundell. There are a couple of reasons why I decided to go with Publish over other static site generators.
First, and foremost, it was based on Swift. Given that I build apps on the side, as well as for my day-job, using a programming language and integrated development environment, and various tools, that I already knew meant that I had that much less to learn for a new system. Secondly, with Publish you are able to not only generate your site, but run and test it locally. This way you can see how it will look before actually deploying it to your live site.
Publish
As just mentioned Publish uses Swift, specifically it uses a few Swift Packages to be able to run and generate the site. The way Publish works is that it takes a set of Markdown files and converts them from Markdown into static pages. Publish uses a pipeline of different functions to be able to accomplish this, which you can learn about if you so desire. Out of the box Publish is pretty good, it comes with a standard theme that you can customize to your liking.
As I started using and learning more about Publish I started to run into some limitations. The reason for these limitations makes sense, however I could not easily find a way to make the adjustments needed within the constraints provided. So, I needed to fork the package and add my own customizations.
### Customizations
Publish allows you to perform a number of customizations out of the box, like customzing the theme, defining sections, and more. However, the way that Publish does some HTML generation did not work that well with my goal of keeping the existing structure of the website. In order to do this I needed to create my own fork of Publish. The customizations that I have made for my version are:
- Ability to set the path for a Location. This was needed for keeping the structure of my site.
- Allowed setting of items in a section. This was needed for some of the sections, without having to manually re-create the items or have duplicates.
- Changed output directory from "Output" to "html". This is a personal preference.
- Changed the "tags" path to "tag". Again, this was to keep the existing structure.
- Pagination. This is pagination of not only the home page, but also tag pages. This took quite a bit of time to figure out, but there were some who already did pagination with Publish, so I was able to adapt their code for my site.
There may have been ways for me to make these changes without needing to fork it, but it would’ve taken more time to build the new site. So, I decided to make the necessary customizations to what I have now. I can always add to it at a later date and see if there is another way to make these changes.
Posting Workflow Changes
Beyond having an entirely new underlying mechanism, there will be a lot of changes on my end for things that WordPress was able to handle for me. These items are no longer automated.
The first of these is that new posts will not be automatically posted to Twitter, Mastodon, nor Apple News. Now, instead I will have to handle these myself. For Twitter and Mastadon I think this is probably a better solution because the automatic posting never really added any featured image to the posts. However, for Apple News it will require me to remember to add new posts to Apple News myself. I may automate these again in the future, particularly to Apple News.
The second change is statistics generation. WordPress had a plugin called Jetpack, which is provided by WordPress that would keep track of statistics for you. Now, I will have to create another method of tracking page views. The solution I came up with was to parse the web logs. I do not need that many different statistics, I really just want page count with the ability to see which items are the most popular. The key to this is to generate the statistics and then I can create an interface later so I can actually view the statistics. This is a planned feature, but it will not be on the site itself.
Generating and Publishing the new site
Here is my new workflow for generating and publishing content.
- Create a new set of folders and file in Xcode.
- Generate the site locally, this is done using a command-line utility or using Xcode.
- Run the site locally so I can preview it and make sure everything works as expected.
- Commit all of the changes to the repository for my website.
- Pull those changes into the site. At that point, the updated site is live.
- Post to Twitter, Mastodon, and Apple News.
The actual generation process of approximately 1850 posts, and numerous pages, without pulling in ads, takes approximately 90 seconds on my Mac Studio. With pulling in ads it takes approximately 25 minutes, at least the way I was initially generating the pages.
Right before deploying the site, I decided to a slightly different approach. If there is a specific ad specified for an item, I pull that specific ad. Otherwise, I pull a random item from a set of random ads that I pulled when the site was first generated. This way, upon each generation of the site, items may have a different ad and regenerating the site will be significantly faster. The entire site takes about 3 minutes total to regenerate, much faster than the 25 minutes previously.
I could automate the deploying of the site, because Publish does come with the means of doing this. However, for now I will be manually deploying the site for a while and see how everything goes.
Converting from WordPress
One of the items that I spent the most time on has been converting from WordPress to Markdown. I found a site that had a way of converting from the exported WordPress XML to markdown. I took that script and modified it to fit the needs that I had for my site. It took quite a few iterations and modifications to the script to be able to get all of the information in the right format, but eventually I got it just right.
One thing that I had done before moving away from WordPress, and which continues on the rebuild, is that I added a new "Latest Posts" section at the top of the home page. This shows all of the latest posts from particular categories. The reason I created this was because I amde another change. I removed the "Device Availability" posts from the main index page. It is not a value judgement about them, but they are more ephemeral posts and I would prefer to highlight these at the top of the page. I will still post about these on the various social networks.
Ads
My website has been showing ads for a long time. These have all been first-party ads that are affiliation links to various items that I want to highlight. Previously, a new ad would appear each time a page was loaded. Now, the ads are generated when the website is built. This means that the ads will remain the same until the site is regenerated and updated.
Removing Items
As with anybody website transition things get removed, updated, and changed. There were a few things that I have removed from the site. These have been certain posts, some features, and search.
Removing Older Posts
When I started converting the WordPress posts to be markdown files, which is how Publish handles content, I decided to remove a number of posts. Some of these were old items, like "Daily Run Down" items. It is not that I am ashamed of posting them, I am not, but the fact that these are more ephemeral items, so I opted to remove them. There were some other posts, like posts of YouTube videos that are no longer available, so I opted to remove these as well.
Removed Features
With the transition to a static site, there are some features that have been removed. The most notable of these is actually search. Nobody really used search on my previous site, so I decided it wasn’t that much of an issue to not have it at launch. I may add it back in the future, if I find a need for it, but nobody was really using it before.
One feature that WordPress had was "author pages". These were pages that would show you everything that a particular user posted. Since I am the only one who posts to the site, this was not really a feature that is no longer needed, so I did not re-create them.
Search
One of the benefits of WordPress, and most CMSes, is the inclusion of search. This allows people to search for items on the site. On the other hand, static sites are not always the easiest to create search mechanism for. I went looking at how much usage search got on my site, and it is not much. Instead most of my traffic either comes from search engines, like Google, Bing, and Duck Duck Go, or directly from my twitter posts. Because of the low usage of search (outside of search bots), I opted to not worry about search for the time being.
Future To Dos and Features
I do not have any specific plans for future features on the site, but it will likely happen at some point. There are a few remaining "to dos" that did not need to get done before making the new site go live. One of these to do items is to go back through all of the posts and fix any display issue with things like with Twitter embeds, YouTube videos, and any thing that I may have previously used a plugin for which as since been disabled.
Closing Thoughts
Overall, I think this will be a good change for the site, because I run it and I am the only one posting, so I do not need to The whole process has been an interesting one and it has allowed me to get used to using things like Swift Package Manager, more than I was already using it, and it allows me to improve my skills with Swift and Swift Package Manager.
While I do not recommend that most use Publish, because it does require a bit of knowledge not only about Swift and Swift Package Manager, but also it is a different way of producing a website that requires a bit more work, not only in setup, but maintenance. Publish is not designed to be used by most users, but for a certain subset of people it might be their right fit. If you do want a challenge, or want to explore Publish, it may be worth looking into.
For most people I would still recommend something like WordPress, SquareSpace, or another hosted website provider that provides you can easily maintain, can be easily extended with plugins, has a large user base, or includes support, and does not require you to maintain your own server, unless you like maintaining your own server.
I will be adding new features to the site over time, but I need to get accustomed to the new workflow that I have, before adding too many new features. I may eventually re-write another site using Publish, because the pages on that site do not get updated that often, but the way they are generated now works well. If you have any questions about how I implemented certain things, feel free to get a hold me via any of the social links at the bottom of the page.
