> Wordpress is a mess that keeps on chugging through inertia
This is a weirdly reductionist position.
WordPress is an auto-updating, security-patched, open source CMS with a stable API, an advanced WYSIWYG editor and now layout tool, a reliable REST interface, good hosting support from stable vendors, a highly functional foundation and a profitable owner, etc.
It's really no messier than any other open source CMS (less messy than several), and it has better community and foundation support than almost any open source product I can think of.
It's fine not to like it, but let's not just casually write it off in a blog post about a static site generator that is limited in scope and a single third party behemoth hosting operation; that's disingenuous.
I agree that WordPress shouldn't be written off, but we have to consider its plugin architecture, and the ecosystem and culture whereby plugins and themes get installed and used.
WordPress core is kept up to date by a responsive team. However, while some WordPress users may be content with a vanilla installation, there are many who are not.
A traditional way to add functionality and style to a WordPress installation is to add plugins and themes. These plugins and themes are not sandboxed, and operate with full privileges.
Unfortunately, there are many plugins and themes which do not uphold the standards of core WordPress with regards to security. And the people who determine which plugins get added to a WordPress install are often non-technical users who are not in a position to evaluate the security implications.
The outcome is that while the WordPress core is hardened, typical WordPress installations which use themes and plugins are still a security shitshow.
The only way I can see to solve this architectural/ecosystem problem would be to somehow nerf plugins, or at least themes, analogous to how browsers discontinued support for the old-style fully-privileged browser extensions. For example, themes could be restricted to inert HTML and CSS. But considering how WordPress gets used, this would be so disruptive that I can't ever see it happening.
And therefore, static site generators like Hugo will continue to enjoy a huge comparative advantage over WordPress in terms of security, even if WordPress core has all the positive traits that you lay out.
> However, while some WordPress users may be content with a vanilla installation, there are many who are not.
Very true. But it is clear that WP's broad trajectory is towards GUI-configurable, block layout themes that do satisfy more users. They are doing more on this than any other CMS project.
> A traditional way to add functionality and style to a WordPress installation is to add plugins and themes. These plugins and themes are not sandboxed, and operate with full privileges.
This is true, as is the risk with third party plugins. (Though ultimately end users will just install some other bodgy CMS if they can't get what they want from plugins. The tradeoff with WP is that those plugins receive some scrutiny through vulnerability databases, better educated WP developers etc.)
Sandboxing themes is always going to be a little tricky, but it is plausible (and indeed it's not out of the question to project WP moving in that direction, given the way its internals are being reconsidered around the REST API).
But do you know of any widely-installable, user-friendly CMS that sandboxes its plugins? That is a huge undertaking. It's something I've thought of many times before, but I can't think of a way to make that practical on the sheer range of hosting options that WP makes possible.
Besides all that, WordPress is doing something that scales [1], unlike all of us techies using static site generators that only people like us can use. If we want the open web to succeed, we should be getting behind things like WordPress.
> Besides all that, WordPress is doing something that scales [1], unlike all of us techies using static site generators that only people like us can use. If we want the open web to succeed, we should be getting behind things like WordPress.
This is a great point - I built a website for a club I go to on Hugo and S3, and it is updated by users going to Forestry.io which then posts changes to Github, which then runs a Github Action which compiles it with Hugo and uploads to S3.
I thought users would be able to get their head around it... nope! I'm the only one that can make changes to the website.
It's still been worth it because of how cheap it is to run, and better for the environment than having a server idling to support our static site, but still a pain that I'm stuck being the one person that can update it.
yah, i'd like to know as well, since i was thinking of recommending the static site generator (but not hugo) + github + forestry.io route for a couple orgs.
* The ability to upload an image and resize it (i.e. someone takes a picture with their iPhone, then uploads it directly, and then cannot resize it within Forestry.io to make it sensible for the page).
* Inserting something like a table becomes an exercise in writing HTML or markdown rather than a GUI action.
* We had a requirement to embed some html in which eventbrite provides every time we have a new event (which gives a 'buy ticket' link embedded to the site for our events, but attributes in the html change for every new event we add to the website). You can embed html directly into the forestry.io editor, however it doesn't work when the html is sufficiently complex, so then they need to edit this particular page in GitHub to add the html in. (Note: using pre-built html blocks in forestry.io does not work for this as far as I can see, as the html changes for each new event). I think this happens when a file contains a combination of both markdown and HTML.
* When creating links, you have to find the relative URL path and then type this in, rather than just clicking on another page in a hierarchy as you would in Wordpress. I know this is a tiny thing - but again it makes users find it more difficult to move when they are used to Wordpress.
Despite these things listed, I do think that forestry.io is fantastic and similar CMS programs are the future - It's just that Wordpress has the edge at the moment. I have seen that the team at forestry.io seems to be building a new product at Tina.io and the forestry.io product does not seem to have changed much recently, so maybe this will start to fill some of the shortfalls.
thanks much for the detailed response. these are good issues to be on the look out for as we explore this route for the two small non-profits i'm thinking about. it's always so frustrating to run into significant usability issues after-the-fact for things meant to be used by less tech-savvy folks. the forestry.io combo still looks promising, so i'll dig into it more with those caveats in mind.
One thing that caused confusion for my person trying to use Forestry was that it "takes a long time" for "saving changes"
After each save, they thought something was wrong so would end up breaking/conflicting the process of git commits etc as they tried clicking different things because something was taking too long.
This was a couple of years ago so things may have changed by now.
> I use and am in favor of Wordpress. However, I’m also in favor of making static site generators easier to use for more people.
Amen, and I think this is the thread creator's point — WordPress doesn't have to "lose" for Hugo to "win", and it's pointless to pick a fight with a wildly different solution that solves a different set of use cases.
The thing that bugs me about more or less any article about why static sites are better/easier/simpler is that they all depend on writing off WP as sort of a straw man.
I have been playing with Publii again after being nudged towards it by a HN comment, and I think it might be a useful middle ground:
I think Wordpress does have some criticism-worthy parts, but criticizing a CMS from the context of a static site generator doesn't make sense. That's a much smaller problem space.
For us technical folk, Wordpress is a beast that needs to be slayed. For John, the non-technical, world-travelling coffee shop owner, that wants to maintain a simple blog describing his adventures, it's perfect.
(I say this as someone who used Wordpress and now uses Hugo)
Totally. There is a stigma against Wordpress for $reasons but compared to all the other platforms listed in this article WP is one of the most aligned with the open web.
WordPress has many problems with the way it's usually used that you don't get with static site generators though:
- WordPress can be auto-updating but when you update the core files, theme, and plugins, and want to upgrade PHP, there's lots of incompatibilities that can take your site down and cause other problems so it's not set and forget.
- Most sites also require a combo of plugins because core is missing essentials (e.g. page caching, SEO tags, contact forms, image optimisation), where each can give page speed, security, and maintenance issues.
- Dynamic PHP code is inherently less secure than static HTML files e.g. there's been remote code execution exploits via WordPress contact form and caching plugins in the past which isn't something you have to worry about with static sites.
- Versioning, deploys and updates via Git and CI/CD isn't standard practice with the WordPress community either. Plugins that update themselves and write files to the server is the norm which is another source of stability and security problems.
- Configuration being split across the filesystem and the database gets in the way of predictable staging/production deploys and QA.
- When writing PHP theme templates, there's minimal default escaping when you output fields so you have to be extra careful to not introduce exploits.
Static sites are fundamentally more secure, more performant and easier to test by default. There's bandaids to some of the above but you'll be fighting against WordPress standard practices all the time.
I'm still trying to find a good open source WYSIWYG page builder experience here that can compete with WordPress though. Using WordPress as a CMS and a static site generator to deploy it is an option though.
> Static sites are fundamentally more secure and more performant by default.
I'm afraid to say I consider "performant" to be a term almost without meaning, but especially here where you just mean "faster".
Any true comparison of performance would have to address the functional things that WP can do that a static generated site cannot do without third party services or serverless functions etc.
I mean page speed, like what Google Lighthouse gives you a rating for. Optimising WordPress for this is much more challenging than static pages in my experience.
What functionality are you thinking about here? I find most business websites don't need much beyond static HTML contact forms, nothing that would need serverless functions. A themed search page is a bit more challenging but you can embed Google Search or something like Algolia. Messaging widgets, analytics are usually JavaScript snippets, same with a lot of buy-button
functionality.
How does your contact form work without backend code?
For me the primary benefit of a contact form is obscuring its destination (or piping it into a CRM or ticket system).
Search is important. But other functionality includes things like content embargo/scheduled publication. Or multi-author systems, where not everyone who is writing the content should be doing any damn thing with CLI tools or Git or any such thing), and where there might be editorial approval before it is posted.
Analytics: again, this is something that I personally believe should be achieved in aggregate on the server side, not in JS trackers.
Most simple business brochure sites do not need much, but most simple business users like a control panel they can log in to.
I do not have _any_ customers I'd deploy a static site generator to. It's just not going to happen without an online frontend (or something like Publii, maybe).
I totally agree with you and would like to add another angle. I have a CS degree but have spent my career largely writing SQL. Given time I can figure out most technical things. Therein lies the issue, time!
I got taken by the HN hype over SSGs and moved my site from Drupal (I didn't want to move to Drupal 8) to Hugo. I spent a glorious three weeks porting my site and getting to grips with Hugo hosting my site on Gitlab. As is the case with me I then didn't touch my site for over four months and when I wanted to post a new post I had to learn a few things again. I have a work device and home PC. Posting meant I had to be at home because that's where my pipeline was setup. In the end I just moved to WordPress. I am not a web developer. There are probably smarter ways to setup and post to Hugo but given limited time at my disposal and limited functionality of my site, WordPress just easier for me.
Obviously there's a third party backend somewhere but better than using a WordPress plugin that might have an RCE security exploit or is open to spam at some point. Outsourcing stuff like this can be a good tradeoff.
> But other functionality includes things like content embargo/scheduled publication. Or multi-author systems, where not everyone who is writing the content should be doing any damn thing with CLI tools or Git or any such thing), and where there might be editorial approval before it is posted.
Customers wouldn't use Git directly or a CLI, they would use a headless CMS. I'm not sure which one covers all of the above but there's lots of headless CMS options here:
Aren’t contact forms easily integrated with tools like Netlify functions or AWS Lambdas (which I believe Netlify functions utilize unless they have their own thing now).. ?
But how many developers do you know outside of your own work team who know how to install an AWS Lambda function?
I've been developing a long time and I have Lambda functions in production but the entire process makes me want to bash my head against the wall to the point of unconsciousness.
The idea that we can write off wordpress as bad in one breath and then recommend a "static" site system which is a bunch of HTML pages with a set of specific third party hosting dependencies has always struck me as interesting. JAMstack is a manifesto for dependency on subscription microservice providers.
Sure, it almost makes you wonder when people go through all those hoops, why not just write up a bit of php just for the email/form or whatever minimal dynamic content you need..
Another way to look at it: why would you want to maintain and secure a PHP stack just to receive an email on a simple HTML page? Just use a simple HTML form service for this, upload your page to something like Netlify or GitHub Pages, and outsource the complexity.
I’m not the author of this and have yet to try it (but I’m going to soon), but it really looks cool and I’ve been looking for something like this for awhile.. I like the fact that because he has it hosted on Replit (believe he has CF in front), he can either edit md files within the Replit UI, or from edit mode within his webui. Neat stuff imo.
Unfortunately, there is no real page building functionality in Publii. There is not even the possibility to create pages. So it's not a real WordPress competitor in this regard.
> I'm still trying to find a good open source WYSIWYG page builder experience here that can compete with WordPress though.
I would be interested to see a static CMS that worked more this way -- Publii is interesting for this though.
> Using WordPress as a CMS and a static site generator to deploy it is an option though.
This definitely can be done, and you could use e.g. the Atlas content modeller plugin and GraphQL and then Gatsby/Gridsome. But it is more work in search of a reason to do it.
Wouldn't it be the same for any software? But Wordpress keeps up quite well, considering the amount of efforts that hackers put in finding bugs on it, given that it powers a big chunk of the web
(You did not deserve downvoting on this; it's a reasonable point. Not sure when the last zero-day was exploited in WP itself, but it definitely happens in plugins and themes.)
I usually find out there is an official patch when I get an email from a WP installation telling me it has already been installed.
Core WP copes with zero-day attacks better than most platforms. To the extent that they will even mitigate problems in widely-installed third party plugins and themes if they think it necessary.
Sure, there is a paradox with anything popular like this, that the people who are installing it are the people least likely to be able to deal with security patches. And that is an endless source of tension. But it is also why WP auto-patches, why plugin and theme auto-updates are now possible etc.
This garbage was normal in early-2000s web development but nowadays this problem has been solved - just look at any modern server-side MVC framework (whether PHP or others - PHP isn't to blame in here).
Maybe it's indeed "good" at handling zero-days in terms of raw numbers, but maybe it would be better to just not have as many zero-days in the first place?
wp-login.php is in need of attention, I think, and will get it through REST eventually.
But it's also entangled with the last bastion of one of WP's most underrated/underdiscussed features: pluggable authentication.
If you mean the appearance of the code: it's not to my taste! But it's actually really heavily governed by code standards (including the Yoda conditions stuff).
WP itself will never be an MVC system, but then MVC is really at odds with the hooks-filters-and-actions API approach WP uses, which again you don't have to like but is crucial to its success.
You can make tiny, targeted changes to the way a WP page renders -- with a single hook function -- that would be hard to replicate in MVC without vastly more effort. Magento tries to achieve this, and does it well, but at the cost of needing dependency injection, XML layout files, etc. etc.; it's enormously more complex.
I personally think MVC is the right thing for app development but wholly the wrong thing for the rendering front end of a CMS site, but I acknowledge this is a contentious opinion.
I think the lack of MVC and general "shaghetti-ness" of the code (why is form HTML rendering mixed in with business logic in the aforementioned file?) is a huge part of why WP has a terrible security track record.
> rendering front end of a CMS site
If this was a view layer working entirely in a sandboxed runtime, maybe, but it's not - you're still editing the underlying application and can run arbitrary code.
MVC may be more difficult to grasp, yes - I went through that a decade ago when I moved from shitty PHP scripts similar to the code above (but hey I thought I was being smart by hashing passwords with SHA-512 instead of MD5!) to learning a proper framework like Laravel (and eventually moved off PHP altogether). However, I absolutely believe it's necessary otherwise you kill productivity, increase human errors and make code review much more difficult. If it raises the barrier to entry I'd say that's a good thing as it would prevent at least some terrible & vulnerable plugins from being made.
> If this was a view layer working entirely in a sandboxed runtime, maybe, but it's not - you're still editing the underlying application and can run arbitrary code.
Right, but can you give me an example of a dynamic content management system that fully sandboxes its _plugins_? I can't think of one.
I tend towards telling people that adding a plugin or theme to their site is the same as adding its developer to their project. You have to decide where your risks are. But the flip side of this is that adding third party services to a static site generally involves significant GDPR exposure at this point. There is a choice to be made.
> MVC may be more difficult to grasp, yes
It's not that MVC is more difficult to grasp; I've been building PHP apps like that for 16 years (and before that Rails and Perl). I've never had any difficulty teaching it to other developers.
It's that MVC isn't actually appropriate for the generation of static CMS content at all. It ultimately locks you into a very specific pattern of layouts (with all sorts of ugly solutions to break out of the box).
It may not be a popular opinion but the hooks-and-actions approach to WP is a much, much more appropriate system for the generation of code for a content management system.
It gives you a "nudging the asteroid" approach to plugins, where hooking into one function at the right point in the page life cycle gets you what you want. That is more difficult with MVC -- you inevitably run into much greater design complexity. As I've said elsewhere, Magento has attempted this, and they have to offer several different methods (involving dependency injection, method rewriting etc.) that WordPress does not need, because its page rendering has a simpler functional flow.
> Wordpress is a mess that keeps on chugging through inertia
This is a weirdly reductionist position.
WordPress is an auto-updating, security-patched, open source CMS with a stable API, an advanced WYSIWYG editor and now layout tool, a reliable REST interface, good hosting support from stable vendors, a highly functional foundation and a profitable owner, etc.
It's really no messier than any other open source CMS (less messy than several), and it has better community and foundation support than almost any open source product I can think of.
It's fine not to like it, but let's not just casually write it off in a blog post about a static site generator that is limited in scope and a single third party behemoth hosting operation; that's disingenuous.