Goodbye Wordpress

2026-10-13T00:00:00+00:00

For the last 7 years, museum-digital’s blog ran on Wordpress. Times change, and so do requirements. To better meet our current needs, it is now a static site generated using Zola.

This blog has existed since 2009. For the first 10 years, it ran on Serendipity. Since 2019, it was then based on Wordpress. Now, it is generated using Zola, just like the general project homepage and resources.museum-digital.org.

What has changed, and why would one switch - as they say - a running system?

Reasons

The original blogging setup ran on the default theme of Serendipity. Images were small, the design looked alright in 2009 but never changed after, and the backend looked outdated by 2015 at the latest.

Our switch to Wordpress was meant to tackle those exact issues. The switch offered a nice opportunity to write a custom theme that followed our (loosely defined, as it is) style much more than the old theme. Things like post images and multilingual posting now worked and Wordpress’ backend looked modern and certainly more familiar.

On the other hand, both CMSes are huge, old PHP code bases. museum-digital’s main tools are the same. We know what a mess they can be. But museum-digital’s tools are opinionated and with a limited install base - when new, useful features arrive in new PHP versions, we integrate them immediately. Wordpress on the other hand - somewhat understandably considering its huge install base - has often opted to stay backwards compatible and easy to work with rather than implementing new language features that make PHP code safer, faster and more deterministic while breaking old code bases and being slightly more tedious to write.

Add to that, that Wordpress is so popular and successful that bots have been looking for potentially hackable Wordpress login pages since long before AI. And then add AI: Bot campaigns and scrapers are more aggressive than ever while security issues and bugs are found quicker and exploits for them can be written more and more automatically.

Hosting a Wordpress site always came with some reasons to worry. Now it’s increasingly a responsibility one would like to shed. Wordpress presents an especially stark case for that, but the same goes for many types of websites that are still generated dynamically.

Enter Static Sites

In the 90s, probably most websites were static: People wrote HTML by hand, uploaded some pictures, and the website was done. If anybody accessed the website, the server would simply forward files as they were present on the hard drive with no modification.

Until some years ago, it was quite easy to find old pages from that time (especially on employee-level webspace of universities). It was delightful every time. Most of the pages looked terrible - many were entirely unstyled - but they were stable beyond any doubt. It was, after all, just some unchanging files on a server.

The 2000s then brought us the prevalence of dynamically generated pages. Blogging became popular, commenting, too, and people wanted to be able to enter new posts or comments into simple forms rather than having to tediously write (semi-)structured files and then upload them.

Graphical user interfaces made editing simpler and more seamless than before. Good. On the other hand, the website now needed to run code to turn users inputs into an actually accessible web page (bad for performance, longevity, and resource use) and to offer whatever way of input functionalities were available. Bad for performance, longevity, resource use, and security.

Static sites have since made a small comeback. For more general purposes - such as blogging or documentation - there are now capable open source static site generators that cover functionalities like search (specifically search often prevented fully static sites from being viable for a long time).

Meanwhile, hosting has become less comfortable and security issues are a greater concern. With static sites, those are non-issues.

Summary: If one has a website that changes rarely and is unlikely to grow to beyond a million sub-pages, then static sites are really worth considering. Dynamically generated websites have their place when interactivity is needed.

Architecture

Not all static sites are generated equally. museum-digital’s CSVXML import preparation service is a static site: On the server, there are no moving parts. Instead, different data sources from around museum-digital are queried to prepare scripts and data files that are then processed in the browser. It’s a small static site generator specifically written for the needs of the CSVXML service that would not work in any other setting.

For purposes such as blogging, a more general solution is necessary. Open source static site generators like Hugo, Jekyll, or Zola principally all follow a similar basic logic: One first writes or selects a theme that fits with the site’s purpose and navigation structure.

Then, content is managed using markdown files. Each markdown file represents a page (e.g. a blog post) and comes with minimal metadata in the file name and at the start of the file. It then simply needs to be positioned right in the folder structure and the generator needs to be run once for the whole site to be updated - including features like search indexing, generating tag or category pages, a sitemap and feeds.

This basic approach is beautiful from a technical perspective:

as all sources for website are simple text files, editing can be done with any text editor
backing up simple files is much less effort than backing up and maintaining full-fledged database systems
version control is basically build into the workflow using e.g. git
metadata for sub-pages or posts is sufficient to generate taxonomies etc.
and again, in the end one only needs to host static files, removing most worries one might have on the security side

On the other hand, there is no unified web interface for adding new posts anymore and reviewing, moderation etc. are moved to external tools and services like GitHub.

The Concrete Case of museum-digital’s Blog

Now, what does all that mean for the present site? Over the weekend, we migrated the blog to Zola. As the open source, MIT-licensed Linkita theme quite closely matches our aesthetics, we could simply use that with some tweaks.

The majority of the site structure remains as it was before, but the new blog does come with some benefits besides loading faster and being simple to host.

First, support for multi-linguality is generally better. The site navigation is translatable (with only Hungarian translations missing as of now) and the availability of translations of a given blog entry being much more visible.

On the other hand, author metadata now works seamlessly. Guest posts were a mess with Wordpress and can now be represented correctly with minimal effort.

The one and only major drawback is that the publishing workflow is now spread out over multiple services and tools, which may feel unfamiliar to less technically inclined potential contributors. But true to museum-digital’s general modus operandi we’ll try to find pragmatic solutions for that. Where technology is challenging, creative organizational solutions can help (and vice-versa). Which is to say: If you have something you’d like to post but feel intimidated by the publishing workflow, just send a mail. In the worst case, even converting word files to markdown is pretty simple these days.

info

AI Use

Post image generated using Anima Base v1.

info

License

This content is licensed under a Creative Commons Attribution 4.0 International license.

museum-digital:blog - Blogging

Goodbye Wordpress

Reasons

Enter Static Sites

Architecture

The Concrete Case of museum-digital’s Blog