In case it’s not obvious at this point, I like little websites. The current Internet has moved us all into massive corporate platforms with a profit motive, which means these motives have utterly shaped culture and communication for the last decade.
Personal websites allow us to escape these consciousness-guzzling content algorithms, generating little spaces that are truly our own. You can do whatever you want, post whatever you wish, and have it look like however you please.
But websites are not easy to build: HTML on its own is far too limited for complex formatting, and it provides no interactivity other than displaying graphics and pressing on links: no responsive design, no dark mode, just formatted text. If you had the deathwish of actually wanting to build an entire modern site from scratch (HTML, CSS, JS, PHP, etc), it would probably drive you mad, not to mention all the additional maintenance all the rest of a webserver needs.
For people like me, there is a solution however, content management software (CMS) like WordPress, an open-source project that started as a simple blog manager that ended up running a considerable fraction of our modern websites, including this one. I’ve been working with it for around a decade at this point, and I have many things to say about it, some glowing, others damning with faint praise: this is my WordPress experience.
The Web 1.0 and the Blog Catastrophe
Back in the early days of the Internet, before big platforms like Facebook dominated the landscape, there was a sprawl of little personal sites: a little log of projects and thoughts on the nascent web: a weblog!
These sites were often little personal outlets of creativity, often hosted for cheap or even for free in places like GeoCities. These sites were often quite basic, highly static, and obscenely kitsch by modern standards, but it showed everyone that everyone could have a voice on the internet.
This was not to last however: the era of social networks was here: people wanted more interactivity, likes and comments were the new currency, and web design became something that was out of reach for the average Joe: it became the realm of specialists, you just had to know too much in order to get any sort of functionality that approached what social networks had to offer.
For pretty much everyone except the most dedicated of Internet dweller, this meant the death of independent personal websites: you either had a profile on a big platform, or you had the money and incentive for commissioning a big website, which pretty much meant you were a company.
But there were (and are) still reasons to have websites with a small footprint: small organizations, interest groups, or even just having a space to share cool stuff out of reach of platforms. What could the average person do with a small budget that could make a small website that just worked?
Baby’s first sysadmin
Around the year 2012, I was an unsuspecting 7th grader getting into my school’s student council: many things were learned, and many ideas were had, some good, some terrible, and some even worth a story in this blog, but that’s for another time.
My first job was working on our student website, a smattering of public announcements, event photos, and other little novelties; nothing too important, but a cute little place for our students to come together, and as with many things people do in school, standards weren’t great: nothing was properly documented, many things were just layers of hacks and questionable security implementations.
Behind all of it was WordPress: we were just teenagers trying to get some pictures online to show our friends, we didn’t need anything too complicated, and so a CMS was a reasonable choice, but it was still rough around the edges: there was a lot of tinkering involved in the backend, lots of time was spent in trawling through database tables and .htaccess files, as well as directly modifying themes and style sheets.
Student council terms were only a year long, and this page had been slowly growing from its original functionality to a Hydra built to the specs of around seven different teams. It was messy, it wasn’t documented, and it just barely worked.
WordPress was actually a great choice: this page was essentially a blog, so the pages/posts navigation system was great, and it allowed many in our team to make content for the page without going mad. Functionality was limited, but it didn’t matter, it was just a place for the student council to show off what they did and a place to get announcements and the like. What little functionality was actually needed was a patchwork of plugins and a little bit of custom code, which of course was horrendously documented and broke pretty much every time we had to rollout something new.
Plugins are, in my opinion, one of the weakest parts of the WordPress ecosystem: they are massively powerful and allows you to greatly extend a website’s functionality, but they are also extremely prone to bad design, poor implementations, and terrible security. You can just pile on plugins on a site and have them interact in weird and undocumented ways, or just have a rogue plugin just break everything on a whim.
One particularly heinous implementation (the site has been offline for years now, so I can talk about this freely: please don’t do this) involved some custom bit of code and a tab on the sidebar that told you who in the student body had birthdays coming up. The page read from a MySQL database table with everyone’s full name and date of birth in plain text, where pretty much everyone was underage. Worst of all, for some reason you could actually see the query if you inspected the site, which meant if the database got compromised, everyone from 7th grade to senior year had now a public full name and date of birth. Yeah, it was bad.
That site didn’t last long after I was in charge: our hosting contract lapsed and the student council didn’t renew it by the time I left that job, it had become too big and too unwieldy to maintain and our social media presence was growing fast, so it seemed to make sense at the time. Being a student body of around 700, word of mouth and social media was enough to get information around, so the burden of holding up that site wasn’t really justified.
An interesting observation administrating this site was one of simplicity: if you want something to last, it must be as simple as possible: every level of complexity increases maintenance exponentially. If you want something to last, especially if you won’t be there to hold it up forever, you should keep things as simple as possible. I also recognized the genius behind Tom Scott’s “don’t shoot for the moon and miss.”: if you’re building something, make something you can actually do, otherwise you’ll end up with crap.
This would not be my last time handling WordPress sites, but next time, the stakes would be higher, and the hacks would be deeper.
Sprawling sites and scope creep
After I left school in 2017, I started working for a religious organization, helping out with their web presence. They heard from my experience running the student council website and called me up to put their WordPress sites more or less in order. My job initially consisted mainly of housekeeping tasks: cleaning up databases and DNS zones, documenting stuff, and the occasional implementation of small features.
This organization had racked up a lot of technical debt over the years. a lot of things were out of style, others were barely functional, and some were absolutely heinous implementations of frankly moronic proportions. Many things were broken and pretty much everything was undocumented, which meant trying to understand what some underpaid web developer had done a decade in the past just by looking at code without any comments.
This began a long process of cleanup: removing unused plugins, patching, documenting, updates, and overall just staring at this site and trying to make it less of a mess without losing functionality. It is possible, but it takes a lot of work to correct once the standards have already been lost.
At around this time, WordPress unveiled the Block Editor: a graphical interface to create pages and posts with advanced styling and layout. This wasn’t new, Elementor made an extremely powerful graphical website editor years before, and it’s still the superior option for complex layouts in my opinion. Having a way to graphically edit both posts and pages, as well as the theme editor that came a bit later made it extremely easy to create great looking websites without ever having to look at any code.
Once the existing websites had been put under control, we created new websites that greatly extended our presence online, and allowed many projects in this organization to get much needed exposure. This was great, but it created a new problem when it came to planning these websites: scope creep.
All of my criticism so far regarding WordPress is somewhat unfair: in the end WordPress is just a tool, something you use to materialize your own vision of how your website should look like. If your concept for a good website is flawed, that’s more of a reflection on your own tastes and criteria, right?
Well, yes, but also no: tools do a lot to shape how we create stuff, mostly because they end up being the thing you create with, which means you have to work with its strengths and work around its limitations. For a painter, a brush informs how the work will be created, for a carpenter, the saw will probably constrain what can be made and what can’t. To me, that’s a good thing: having those constraints usually means you strive to make a better thing overall.
There are two noteworthy stories from my time at this organization: the first one happened when I was doing the cleanup of the main site, there was this page that was supposed to show you the interface for an integrated library system (ILS), a way to check the catalog of the internal library we had at the main office. This was on a separate server locally hosted on the main office, which at the time had dynamic IP address allocation, which meant every couple of weeks the address changed. This is not really a problem, the IP address was a public one and dynamic DNS has been a thing for decades now: but that’s not what this god-forsaken programmer had decided to do.
What he considered an acceptable solution was to iframe the entire ILS webpage into a blank page on the website and just have someone change the iframe code every couple of weeks when they noticed it had stopped working. Needless to say, when it got to my hands this cursed abomination had stopped working entirely. I switched to DDNS and some light fire-walling, but I feel like that thing haunts me in my sleep.
The second one is pretty much my own monster: the people at the press department wanted to sort all of their entries by year using tags, which is fine, except they wanted some sort of automated solution. I went straight for the database, whipping up a trigger that would assign the current year as a category each time a new post came in. It actually worked great, except when a new year came by and there was no tag to assign, and the entire New Post page broke immediately. A yearly task to create it quickly solved the issue and it hasn’t been a problem since.
As that job started to fade, a new idea popped into my head: I knew my way around WordPress, could I make my own websites?
A burst of creativity and purpose
It all started with two related events: the first one was getting my new server that could actually run a decent webserver (don’t get any ideas, this site is proxied through Cloudflare and there are many layers of security between the Internet and my server), and my buying this domain back in 2022. I had a blank canvas at my feet, ready for whatever I wanted.
First came this blog, which is a mixed showcase of projects, experiences, and opinions, a website with guitar chords for church songs, and a couple of other things, managed using Hestia Control Panel. This was my first time both self hosting and having full control of the backend, as I usually relied on commercial hosting up to this point. There’s a few nifty advantages, a few extra challenges, but it’s an interesting experience to be fully in control after years of steadily losing ground to centralized platforms. I can see why the average person does it, but for my (relatively simple) application, It’s perfect.
Once the webserver was up, I was back to good old WordPress. For most of my time I was actually just maintaining the backends, this was my first time actually having creative input on a website. Despite my many years of experience working on websites, I still found the plug-and-play experience to be much easier. The new theme editor is also a massively powerful tool to customize your website without going insane looking at CSS sheets, and along with the block design tool it makes a truly graphical experience.
I’ve also kept it light with the plugins: in the case of this website, it’s only Jetpack, which despite its shamelessly pay-to-win scheme (a disgustingly common trend among WordPress plugins), the free version does provide for some nice optimizations and enhancements, along with a much appreciated stats page and a nice anti-spam plugin, something I figured out I needed the hard way. Pricing is also fairly reasonable compared to other similar solutions, which means it’s a good choice for a bigger website that needs beefier implementations.
And so far, I’ve loved it! It’s obviously more work than just having a social media profile, but having my very own little corner of the Internet is extremely liberating to me: not having to worry about the algorithm or by the design constraints imposed by a big platform just makes talking about the things that I like so much easier. It probably gets a smaller audience than it would on social media, but the numbers are not that bad and I still post the links to social media, which more or less solves that issue.
There is however a big problem with self-hosting and maintaining websites that I gestured at before: security.
A security nightmare
WordPress’ backend is made in PHP, which isn’t really a security oriented language, and as many long-running projects there is quite a bit of jankyness to be found in its code. There are also some old features that have been hammered time and time again which have allowed unauthorized parties to gain access to websites and their content.
XMLRPC is one of them, and it’s absolutely baffling: if done right, an exploit to the xmlrpc.php file on a standard WordPress install can be used to inject custom plugins and compromise the integrity of your website. How do I know this? Because it happened to us on this NGO, on two sites simultaneously. Users got a popup that asked people to run some code on PowerShell with admin privileges. It was just Ethereum miners in our case, but a couple of clients got infected and it was a mess to clean up a bunch of legitimate looking plugins and it took a couple of hours to get all the websites.
The fix is fortunately simple: XMLRPC is a protocol for doing APIs from back in the day, but it rarely gets any use today, if at all. Modifying your .htaccess files to return a 403 status code to the compromised file is enough to stop you from getting hacked using code injection.
Also, if you’re running a server on your own infrastructure, I highly recommend you use network tunnels and a proxy service to isolate yourself from the Internet. It will be a lot easier to address any security concerns, and caching will help improve your server’s response time allowing for a better experience for clients.
Should you use WordPress?
Maybe! I said it with confidence though, so I’m not a coward.
WordPress is extremely powerful and an amazing tool if you’re doing things the right way: document everything you do, keep an eye on security issues, and try to maintain a level of complexity that you can actually manage. Don’t be allured by the one plugin that will solve everything, try to actually solve the issues you have and working your problems instead of just throwing plugins until something works.
If you want to make a simple website like this one, maybe for a small business or just for playing around, it’s a great way to keep everything under control. If the stakes are higher, maybe get someone who actually knows something about web design and maintenance.
Or, you know, maybe you could just become the expert yourself!