How To Ditch Wordpress
Feb. 7th, 2026 09:08 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
nemorathwaldI'm very excited to have completely replaced the Penguicon website with a duplicate that's faster and easier for the staff to edit, using the approach I describe here. I hope you're rooting for us to attract enough attendees for there to be a Penguicon 2027. Please spread the word.
Here's the related paper I submitted to the Call For Papers of B-Sides Detroit, a security conference in May where I spoke last year about my makerspace. The talk will be titled "Ditching Wordpress In Volunteer Organizations With Git-based CMS For Static Sites".
Wordpress exposes a terrible security surface, so this is relevant to a security conference. A static site generator (SSG) has close to zero attack surface, and can use a headless CMS (content management system) and a variety of integrations that follow the philosophy of "small pieces, loosely joined". Let me give you many more reasons that support your case.
Wordpress makes hard things easy and easy things hard. It's designed to be all things to all people: bloggers, newsrooms, e-commerce shops, portfolio sites, churches, SaaS marketing pages, and the kitchen sink, all in one interface. The non-technical users wanted to edit a page! That's all! But they're lost in a tangle of posts, blocks, media libraries, plugins, themes, roles, settings, updates, warnings, so they feel like they're standing next to a nuclear reactor. They didn't ask to "administrate a publishing platform"! But they're wading through a UI for a bunch of responsibilities they don't have. They don't want to feel like they might break something. I've learned from experience that ideally, they want an "Edit this page" button to an editing form page with the correct file preselected for them. (What they don't know is that it's making a version control merge request behind the scenes. More about this later.)
Let's also look at it from the perspective of two different levels of org leadership. On the one hand, someone with a limited scope of their role in the organization should be able to just casually and instantly edit the page of the site over which the org has delegated full authority to them. Small groups die if they have a lot of decision-approval paralysis. On the other level, though, a limited group of people should be able to edit pages about the results of votes on group-wide policies: codes of conduct, safety rules, membership requirements, disciplinary processes, privacy policies, bylaws. I'll describe an approach that makes it easier to set up this distinction.
Let's also look at it from the perspective of the one or two willing-and-able web developers in the org. We have our hands tied by Wordpress. We're the only people willing to tolerate the interface, so as all the non-technical users abandon it, we end up assigned by them to use the end-user interface intended for them, while its UI fights us every step of the way, instead of where we should be working: in Visual Studio Code and git. As the org constantly churns which staff are involved, some of them installed expensive plugins that are deprecated and no longer work, or are incompatible with other plugins, only the third-party devs who create the plugins understand how they work, plugins are compiled and compressed so you can't debug them, something silently broke, and who even installed all this stuff?
At least, did you get a good website? No. Browsing a Wordpress site is slow and expensive, because each page has to be compiled to HTML every time someone browses to it.
Enter static site generators (SSGs). They compile the site to HTML one time when an editor changes it, and then just deliver a static document, instantly. Unlike Wordpress, which is an opaque stateful system, you can open and edit your SSG source files (Markdown for pages and YAML for lists of entries), in any text editor, instead of having to futz with a database. What a small volunteer org wants, is a structured information system, not a general publishing platform. Without a database schema imposed by WordPress, the organization's web developer can define exactly what content exists: events, announcements, pages, policies, bios. Don't need it? Ditch it! "Small pieces loosely joined."
SSG content is portable independent of the software stack that created it. That's what it means for a content management system ("CMS") to be "headless". It can go into all kinds of front ends. With Wordpress, you're wondering which plugin changed this field, which editor saved this block, which migration altered this table. With SSG, the site is just a compiled version of a repo you can reason about, which doesn't differ much from one environment to the next, and everything's just version control! Guess what you can do with files in folders? Diff them! Copy them! Upload them through a file-picker!
Wordpress has unavoidable categories of risk just by exposing a live admin interface all rolled up into one. With an SSG, the public interacts only with inert files. Your staff edits files in a controlled editing layer. Sometimes also Google Forms and Google Sheets. Your web developer is working in Github/Gitlab, Netlify, and VS Code. (Maaaaaybe Airtable and Supabase if you're fancy.)
Goodbye database corruption, DB version mismatches, DB credential leakage, DB backup integrity, DB restore procedures, DB migrations. Goodby PHP interpreter, database server, and plugin execution path. You never needed any of it for your brochure site!
But wait, what about a contact form and other forms? What about comments on our posts? And how does the non-techical staff of the org edit it? Never fear, I'm going to show you!
I'll demo several successful examples in which orgs allowed me to do the following.
Let's touch on psychology. Using Wordpress is the volunteer organization's equivalent of "you never get fired for buying IBM". We often install Wordpress because we want to be part of groups that are democratic and bottom-up instead of top-down. Of course we do! But having a voice and expressing your co-leadership in a group takes time and energy. Exercising your influence as an equal contributor, equitably directing your group, consumes your availability (or bandwidth, or spoons, or whatever it may be). Therefore having run out of bandwidth, availability, spoons, is exercising less influence. Each act of exerting influence consumes it. The 90-9-1 rule of participation inequality (90% lurk, 9% contribute occasionally, and 1% do almost everything) is like a law of gravity, not something someone imposed on us by enforcing an arbitrary heirarchy. Don't choose Wordpress to pretend everyone in your group wants to make an account on it and treat the website like a Discord server.
The bottom line is that groups always depend on one or two technical people to have a usable website. So don't tie our hands. Make it easy for us so we can make it easy for you. Ditch Wordpress.
Here's the related paper I submitted to the Call For Papers of B-Sides Detroit, a security conference in May where I spoke last year about my makerspace. The talk will be titled "Ditching Wordpress In Volunteer Organizations With Git-based CMS For Static Sites".
Wordpress exposes a terrible security surface, so this is relevant to a security conference. A static site generator (SSG) has close to zero attack surface, and can use a headless CMS (content management system) and a variety of integrations that follow the philosophy of "small pieces, loosely joined". Let me give you many more reasons that support your case.
Wordpress makes hard things easy and easy things hard. It's designed to be all things to all people: bloggers, newsrooms, e-commerce shops, portfolio sites, churches, SaaS marketing pages, and the kitchen sink, all in one interface. The non-technical users wanted to edit a page! That's all! But they're lost in a tangle of posts, blocks, media libraries, plugins, themes, roles, settings, updates, warnings, so they feel like they're standing next to a nuclear reactor. They didn't ask to "administrate a publishing platform"! But they're wading through a UI for a bunch of responsibilities they don't have. They don't want to feel like they might break something. I've learned from experience that ideally, they want an "Edit this page" button to an editing form page with the correct file preselected for them. (What they don't know is that it's making a version control merge request behind the scenes. More about this later.)
Let's also look at it from the perspective of two different levels of org leadership. On the one hand, someone with a limited scope of their role in the organization should be able to just casually and instantly edit the page of the site over which the org has delegated full authority to them. Small groups die if they have a lot of decision-approval paralysis. On the other level, though, a limited group of people should be able to edit pages about the results of votes on group-wide policies: codes of conduct, safety rules, membership requirements, disciplinary processes, privacy policies, bylaws. I'll describe an approach that makes it easier to set up this distinction.
Let's also look at it from the perspective of the one or two willing-and-able web developers in the org. We have our hands tied by Wordpress. We're the only people willing to tolerate the interface, so as all the non-technical users abandon it, we end up assigned by them to use the end-user interface intended for them, while its UI fights us every step of the way, instead of where we should be working: in Visual Studio Code and git. As the org constantly churns which staff are involved, some of them installed expensive plugins that are deprecated and no longer work, or are incompatible with other plugins, only the third-party devs who create the plugins understand how they work, plugins are compiled and compressed so you can't debug them, something silently broke, and who even installed all this stuff?
At least, did you get a good website? No. Browsing a Wordpress site is slow and expensive, because each page has to be compiled to HTML every time someone browses to it.
Enter static site generators (SSGs). They compile the site to HTML one time when an editor changes it, and then just deliver a static document, instantly. Unlike Wordpress, which is an opaque stateful system, you can open and edit your SSG source files (Markdown for pages and YAML for lists of entries), in any text editor, instead of having to futz with a database. What a small volunteer org wants, is a structured information system, not a general publishing platform. Without a database schema imposed by WordPress, the organization's web developer can define exactly what content exists: events, announcements, pages, policies, bios. Don't need it? Ditch it! "Small pieces loosely joined."
SSG content is portable independent of the software stack that created it. That's what it means for a content management system ("CMS") to be "headless". It can go into all kinds of front ends. With Wordpress, you're wondering which plugin changed this field, which editor saved this block, which migration altered this table. With SSG, the site is just a compiled version of a repo you can reason about, which doesn't differ much from one environment to the next, and everything's just version control! Guess what you can do with files in folders? Diff them! Copy them! Upload them through a file-picker!
Wordpress has unavoidable categories of risk just by exposing a live admin interface all rolled up into one. With an SSG, the public interacts only with inert files. Your staff edits files in a controlled editing layer. Sometimes also Google Forms and Google Sheets. Your web developer is working in Github/Gitlab, Netlify, and VS Code. (Maaaaaybe Airtable and Supabase if you're fancy.)
Goodbye database corruption, DB version mismatches, DB credential leakage, DB backup integrity, DB restore procedures, DB migrations. Goodby PHP interpreter, database server, and plugin execution path. You never needed any of it for your brochure site!
But wait, what about a contact form and other forms? What about comments on our posts? And how does the non-techical staff of the org edit it? Never fear, I'm going to show you!
I'll demo several successful examples in which orgs allowed me to do the following.
- Create a SSG version of the site, hosted for free on Github or Gitlab. The first one I made was https://magicmeeplegames.com in 2019. Be honest, your website is just some HTML documents, not a Web 2.0 app!
- Put a contact form and other forms on the site with Netlify, which will email you when someone fills it out, and has built-in spam detection. Often you don't even need that; you can embed a Google Form which will collect responses in a Google Sheet. Netlify also stores some environment variables to act as a pass-through for other services I'll talk about later.
- What about if you *do* want blogging? Be honest. Nobody is going to leave comments on blog posts except for scams and spam, so why bother? Have a Discord server. But if you must, I can demo how to make that work with this approach, which I did with my blog at https://matt-arnold.com. I migrated two decades of blog posts from Livejournal and Dreamwidth into Markdown and YAML.
- Connect Forestry.io, TinaCMS, or CloudCannon, so end-users in your organization get a convenient headless interface to edit the Markdown and YAML entries. I did this when I made https://columbus2020nasfic.org/ to host an online-only convention during the COVID pandemic lockdowns. Editors don't need to make an account. They only see the stuff they care about in their role. What it's doing is a git push behind the scenes (some of them have felt intimidated by being told that, but they don't need to know it at all). Those are paid services, but I'll demo one that I threw together myself that works just fine for free, which I did for https://2026.penguicon.org. A hacker defeats your auth? So what? All it's doing is submitting a pull request, which you reject so it doesn't make it on the live site. I get maybe two or three of these a year from all my websites combined.
- What if you need true non-static pages driven by APIs to user-generated content? No worries, the SSG+Netlify+Git-CMS approach has not painted you into a corner! I'll demo an attendee dashboard on one of my static sites (on https://fluidityforum.org), driven by Airtable. I'll describe the authentication and authorization tradeoffs. We can log in to the UI on Airtable and edit our tables just like spreadsheets. We added some columns to some tables, and they instantly displayed on our site's attendee-facing dashboard as form UI elements automatically. This is where you start paying some money, though.
- If time permits, I'll discuss adding webhooks with Supabase by showing off my board game site, https://isoriffic.com. SSG+Netlify+Git-CMS is incredibly flexible. "Small pieces loosely joined."
Let's touch on psychology. Using Wordpress is the volunteer organization's equivalent of "you never get fired for buying IBM". We often install Wordpress because we want to be part of groups that are democratic and bottom-up instead of top-down. Of course we do! But having a voice and expressing your co-leadership in a group takes time and energy. Exercising your influence as an equal contributor, equitably directing your group, consumes your availability (or bandwidth, or spoons, or whatever it may be). Therefore having run out of bandwidth, availability, spoons, is exercising less influence. Each act of exerting influence consumes it. The 90-9-1 rule of participation inequality (90% lurk, 9% contribute occasionally, and 1% do almost everything) is like a law of gravity, not something someone imposed on us by enforcing an arbitrary heirarchy. Don't choose Wordpress to pretend everyone in your group wants to make an account on it and treat the website like a Discord server.
The bottom line is that groups always depend on one or two technical people to have a usable website. So don't tie our hands. Make it easy for us so we can make it easy for you. Ditch Wordpress.
