Again, I changed my blogging method. I returned to WordPress again, except it’s the self-hosted option.
From static page generator to CMS
At first, my blog was just a set of Markdown files hosted on GitHub pages with Jekyll; it wasn’t much, but I was so passionate about blogging back then that I wrote much more often than now. Later, I switched to Hexo, hosted on my server, because it offers more flexibility than GitHub pages. Slowly along the way, I changed to using CMS like WordPress on hosted websites, as I heard it was one of the most popular blogging platforms in the world. I also tried out Joomla, a much more robust CMS that can do more than blogging. Now, I’m back to WordPress, and (if nothing else happens) I shall settle with it.
The choice between static page generators and full-fledge CMS has pros and cons.
Page generator
The most obvious benefit of a page generator is that the actual content is stored as plaintext/markup files somewhere in the file system. These files can be easily backed up, version tracked or edited on any platform with a text editor, whether you’re online or offline. It’s a common practice to use git or syncing tools like rsync to manage the files.
A typical page generator also does not consume much resources. They generate content based on each input file and can often reuse the previous results or caches. Most importantly, after the generation, the website is static; during serving, there is no extra load on the server for any code execution. So it’s usually a once-in-a-while thing, where you prepare the documents, upload to the server (or generate locally and upload the result to the server), and are done — minimum resource usage until you need to update the content. This is perfect for systems with lower performance, such as budget VPS.
However, these two are also its most significant shortcomings. Relying on file input means that editing has to be done on local files, not on web interfaces; if git is used to manage files across multiple platforms (such as I did), there will be a lot of meaningless commits and pushes because I need to save the file to pick up from a different machine. It also means no live preview unless you run the generator locally on a supported machine. When editing from a mobile phone, you must guess the layout and visual effects before pushing it.
A static site also means limited functionality—no backend storage, local commenting system, log-in, and server-side code. This is usually not a big problem for blogs, as they need to convey information to their readers; a commenting system can also be achieved with external services. However, the problem usually arises when you try to add some small but useful utility tools to it: visitor count, spam protection, user-based content display, etc.
Content management system
Content management systems usually refer to web platforms that take user input and handle background tasks such as rendering with templates, searching, permission management, etc., and help build a functional website. They are complicated website systems that exist to build other websites out of them.
This offers some valuable functions. For example, a post can be permission-protected, local logins and comments can enhance the reading experience, and the server can actively perform tasks upon request. Most CMS also offer a web editing interface, usually a WYSIWYG editor, where you can see the effect with live preview. This allows easy editing from any device, including mobile phones, to be easily achieved. Moreover, writing tools like Grammarly can easily integrate with a webpage but usually have problems running on text editors like VS Code on Linux.
However, CMS does require quite some resources to run, and since all content is stored in the database, it can be hard to recover in the event of system failure. This also causes vendor lock-in because you usually can’t migrate from one CMS to another with a click of a button. At the same time, you can change your static site generator by simply copying the source files over.
After trying many options, I prefer CMS over static site generators, mainly because of its extra functions and the auto-saved web editing interface. I can easily accommodate the extra resource requirements using my server or NAS. This WordPress site is hosted on my NAS instead of the server.
Between Joomla and WordPress
Before settling with WordPress, I also tried Joomla. And honestly, I was pretty impressed by its functions. Not only can it define different categories as directory structures and apply different settings based on them (to create a tab-like effect), but you can also configure it to be more than just a blog, for example, an online merchandise showcasing system.
Pros of Joomla
Joomla is, in fact, more powerful than WordPress. It has unique features like:
Custom categories
Everything inside Joomla is a post, but it may be placed under custom categories. Each category (or sub-category) can have its own attributes, styles, layout, or custom-loaded scripts. This means that your site can contain a blog, a gallery, a merchandise showcase, and something else and have completely different layouts and functions.
Overrides
It’s easier to load extra functions onto Joomla because it offers override functionality. You can create a file that overrides the default (usually PHP, but it can be anything) file within Joomla’s built-in file system and change its function. For example, if you override the way code highlighting is performed or even more fundamental functions like how authentication is performed, they will survive the change after an update.
Community plugins
Joomla has more plugins than WordPress. Of course, you can argue that this is because Joomla has fewer advanced and dedicated functions than WordPress (which would be true), but I’d like to believe it’s because creating plugins for Joomla is easier than for WordPress. All the custom functions are already there; the plugin just has to utilize them to work. This allows the developer to focus on the plugin’s functions.
Why I settled with WordPress
After stumbling around with Joomla, I realized that although it’s much more powerful, I do not need most features. The features I need are not out-of-the-box, and the time I need to spend configuring and managing the CMS is almost as long as I would write the actual posts. Specifically, WordPress has:
Convenient security features
Free plugins can quickly achieve the OIDC login, 2FA setup, and other security and monitoring—no more rewriting part of the webpage or manual interfacing with the local login systems. This integrates well with my existing monitoring system and provides fast response time should something happen.
Mobile client and OTG writing
With the JetPack plugin, the WordPress site can be managed and viewed on mobile, with mobile-friendly views. It also provides easy-to-use features for writing posts and pages on mobile devices and a minimal dashboard display. It even caches the post when there’s no network and allows you to upload it once you’re back online. This is very helpful in the UK, where train rides are long and cramped, with no cellphone signal.
Leave a Reply