Lately most of the modern marketing websites I see is built using gatsby and next.js. Having been talking to different content/marketing teams, they hate it so much because of the complexity it brings. Editing content? Sign in to this headless CRM app, want a form? Go sign in to another app. It might be a fun project for devs but the actual users if these systems will almost always have a hard time using it.

~~You have to~~ WP expect you to install it such that it can modify its install folders - all of them. Security-fucking-nightmare.

It will use incoming requests to trigger "cron" jobs (which can include self-upgrades), via a non-loopback HTTP request.

It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP. You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.

Arbitrary plugin installation, in a non-sandboxed environment (see prior point about an application-writable install). Need more be said?

You really have to dedicate an admin to it if you want to keep it secure and performant. I still get angry remembering my experience installing, securing, and setting up caching in front of it.

Nobody but other devs cares about the simplicity of the code if the code works.

>The code and hosting requirements are, frankly, Frankenstein's monster levels of frightening.

Huh? Wordpress/PHP hosting requirements are the easiest to meet in the industry. Not to mention the most widely available...

>~~You have to~~ WP expect you to install it such that it can modify its install folders - all of them. Security-fucking-nightmare.

Yeah, so? It's self-updatable. Use a dedicated user/group.

>It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP.

Absolutely not "because of PHP". If anything PHP is faster than both Ruby and Python, two other common choices.

>You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.*

That's the case with most CMS, PHP or not.

>Arbitrary plugin installation, in a non-sandboxed environment (see prior point about an application-writable install).

It only happens if you chose to do it. Plugins don't magically install by themselves.

So it's not much different than any environment where you can download a jar, a python package, a ruby gem, etc and have them add functionality into the CMS.

>Need more be said?

More, no. Better, yes.

They care when you start quoting a week for a simple addition that should take an hour, because every time you have to wade into a mess, in which one wrong semicolon in functions.php brings down the entire website.

Of course you test and you test, but you're surrounded by landmines at all times.

Exactly, this is the key point. If it’s a website that literally will never change then fine (edit: what I mean here is if you are confident WP can meet your needs without resorting to hacks, and can meet your future needs - in my experience, it’s when more functionality gets added on by random developers that things get messy, true of development in general though!).

I guess using headless WP might help? The clients I’ve worked with who’ve had WP sites in the past have made a point of saying they definitely don’t want WP again (due to security nightmares, usability etc) so honestly haven’t investigated it too deeply recently.

Don’t immediately deploy code into prod until you’ve tested it?

The professional approach is a local copy for development, a staging copy on hosting for QA, and then production. Code goes up in deployments; DB and files come down in regular synchronization. If there are multiple devs you might also have an integration copy on hosting.

This is not specific to WP; I’ve seen the same workflow work for other DB-backed CMSs like Drupal.

Still doesn't help that most WP sites I've ever seen inevitably were those huge card castles just waiting to crumble at the next plugin update. Cause of course, the remarketing plugin the client needs/wants installed just introduced some weird edge-case bug when used in combination with the latest version of the forms plugin you use. Or they ask (demand) administrative privileges "cause they're paying" and proceed to start messing with the configuration themselves and destroy everything. All the local development copies in the world won't make it less temperamental and brittle.

Its success - IMHO - doesn't have much to do with its technological merits but familiarity. Most "content" people know how to use WP, so companies like to have WP for their content management.

Or maybe I'm just bitter of my time working in the kind of environments that tend to focus on WP. Although last news I got were they were starting to use it more as headless CMSes.

Honestly though, there's a lot of talk about changes here without much talk of the most obvious class of changes that Wordpress is designed to support: adding content to your website or blog.

For all its faults it does make that very easy, and it's designed with the intent that you will do so by working directly on the live site (you can obviously preview and review content before making it live).

Changing layout and templates is trickier, likewise creating a new page layout, and that's where a staging or development site comes in handy.

The main one, where people update content.

Then there's a backup that gets auto restored every morning (with appropiate sed etc to change URLS), which is suitable for developing and testing any code changes

The third is one which is manually restored from the backup, and suitable for longer term experiments, how best to organise pages, etc.

Even can do a CI/CD system.

As someone who works professionally at a hosting company, no one does this. The history of Wordpress security has followed window XP with users who downloads random files from the internet and click cancel every time something want to update. Every hosting company that I know has to implement firewall rules to address WordPress security, just like the old days of windows.

The default configuration is also not fine. At minimum you need to disable rpc calls to the login, as the password attacks trigger a lot work that eats resources and processes. RPC is on per default in order to make the WordPress mobile app work.

Wordpress made sense when the web was a collection of independent servers. However in today’s cloud-orientated hosting landscape there are a thousand better ways to provide said content. Both at the beginner level and at the enterprise.

I’m no fan of PHP or Wordpress by any stretch. But I agree with the pragmatic choice in this case. It will probably only need one dev to maintain the site. But even that would be overkill. You just never want a bus factor of 1. Especially for such a high profile site. But I’m digressing...

But cloud vs VPS aside, I do wonder is they are self hosting due to security reasons. Imagine a bad actor hacking into the WP installation! It does have a bad security record.

I disagree, and I think it comes from a different understanding of what web security is.

Popular CMS software benefits from millions of people hammering on installations. If the community constructs a sane process for handling vulnerability reports (and WP has), then the average user of that software benefits from a robust continuous testing regime that they could never afford themselves. Testing and patching is an extremely important component of web application security in the long run, and also very expensive to do well. Most custom CMS projects do not bother to do it at all, and yet fool themselves into thinking they are secure because they wrote their own code.

No one can write secure software on the first try. The most well-funded and well-regarded software companies in the world spend tremendous effort on coding practices and testing, and still ship vulnerabilities.

Continuous testing and patching is always required. If your website is the only one running your CMS software, your first hint of a vulnerability may be when it gets exploited in production.

Whenever a new vulnerability is discovered for WP (or any popular suite, be it a shop like Magento or message board like phpBB) you then get hordes of bots that trawl the internet looking for sites that run out of date versions of said software just for the purpose of hacking it. Even search engines become tools for bots to hunt out these insecure platforms.

I’m not someone who advocates security through obscurity however the vast majority of WP et al hacks are not targeted and thus a home grown CMS technically wouldn’t fall foul in the same way.

HOWEVER please don’t twist my words into saying that home grown CMSs are “more” secure. I’m making no such claim what-so-ever (and nor did I in my previous post when you want off on a soliloquy about how I apparently suggested that — I did no such thing!). My statement is and was only that any popular CMS will be a security nightmare. That point is very much true.

This is why I also brought up the point about WAF and additional policies on your admin path. The former buys you a little more time with updates (assuming you’re with a reputable WAF that supports the CMS platform you’re hiding against) because they can identify suspicious requests (ie ones that look like they’re triggering a known vulnerability) and simply block those requests from your site (technically the WAF is a reverse proxy with some firewalling, request heuristics, etc).

As for the point about admin policies: if you can IP whitelist who gets access to /admin then that saves you a lot of pain early on. But that’s obviously not always practical. However there are plenty of other ways to harden access.

Disclaimer: in a former life I used to repair and harden hacked CMSs, shops like Magento, etc.

We always aimed to evaluate security patches same-day. The shortest lag we saw was “Drupalgeddon”—about 12 hours. In some cases we would see a lag of up to a month between the release of a patch and the signatures of automated attempts to exploit the underlying vulnerability. We eventually got rid of our IDS because all it did was log failed attempts to exploit vulnerabilities we had already patched, and fruitless door-knocking like password brute force attempts.

I’m sure you saw a lot of CMS installations that got hacked. I’m also sure that most them were because of either poor patch discipline, or misconfiguration, or both.

I guess it’s true that if someone is going to be bad at running a website, a popular CMS might be a bad experience for them. But even then a popular CMS may have an advantage: it’s a lot easier to find professional help for a popular CMS than for a niche or custom one.

Honestly, running any software at all is going be a nightmare for a lot of people. Hence the success of products like Squarespace and Wix; now they don’t have to.

All that means is that you’ve misconfigured your IDS. You’re supposed to filter out stuff that’s not a threat, not remove the entire IDS instance entirely!

You shouldn’t throw the baby out with the bath water https://en.m.wikipedia.org/wiki/Don't_throw_the_baby_out_wit...

Again you’re over estimating the average IT team’s ability to keep on top of WP patches. And again I have to reiterate my point about the advantages of a good WAF (web application firewall).

I’m not making a theoretical argument here. I’ve seen and have had to fix numerous sites from companies with competent developers and sys admins but who were simply unlucky enough not to notice that one RCE vulnerability in time.

> I’m sure you saw a lot of CMS installations that got hacked. I’m also sure that most them were because of either poor patch discipline, or misconfiguration, or both.

Neither actually. Just busy teams in medium sized business having a plethora of projects and too little time to manage everything with the same degree of love that your larger companies or start ups do when they have a dedicated team working in a single product.

Remember the appeal of WP for many is that it is “plug and play” so it often gets installed in organisations as a way of reducing the burden on existing developers and/or sysadmins. A strategy that makes complete sense on paper but can back fire spectacularly.

Let’s also remember that WP also appeals to the hobbyists too. You can’t accuse them of being incompetent sysadmins because they never set out to be technical. Instead they were sold on how easy WP is to install and manage.

Again this is why I keep discussing WAFs. Using them is non-obvious but it does reduce the burden on whatever individual or team manage WP.

> But even then a popular CMS may have an advantage: it’s a lot easier to find professional help for a popular CMS than for a niche or custom one.

Oh i agree. Choosing an established CMS isn’t a bad decision as there are plenty of benefits in doing so.

> Honestly, running any software at all is going be a nightmare for a lot of people. Hence the success of products like Squarespace and Wix; now they don’t have to.

This I agree with too.

I’ve seen WP used for everything from personal blogs, international news sites, shopping sites, and even fantasy sports games. The diversity of WP is definitely a strength. But it does mean that there’s not going to be a 1 size fits all alternative.

There's no "NFS requirement for multiple Wordpress hosts" tho.

Unless you have a very dynamic site (posts hourly, multi-daily), would making it static-y be a solution?

* https://wp2static.com

Do a post via web GUI, it gets written out to disk, and then you rsync (or auto-git or whatever) to distribute it.

However if you can and are going down the static site route then I’d wager there are easier platforms to start with.

I built a static site generator that takes markdown files and “compiles” them to HTML using pandoc. The whole thing is just 1 shell script. But that use case also wouldn’t suite most other people.

So it really depends on what the team need and what the site does.

Often the “loads of ways” on WP require changing its normal behaviour and thus breaks ones ability to use the admin console. Or use some other kludge that might suit some subset of people some of the time. But ultimately it keeps coming back to kludges or other workarounds that introduce as many caveats as they solve.

Just a shame there’s no liability for negligently causing users to get infected.

> You have to let it modify its install. Security-fucking-nightmare.

You don't have to do this, you can set up sane permissions and use the wp cli[0] tool to install updates manually. I prefer to version sites with git and install updates locally, then git pull down on to the live server.

> It will use incoming requests to trigger "cron" jobs (which can include self-upgrades), via a non-loopback HTTP request.

A good practice is to set up your own cron job[1] on the server and disable the internal cron in your wp-config.php, like this:

  define('DISABLE_WP_CRON', true);

> It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP. You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.

Just install a page caching plugin of your choice[2]

> You really have to dedicate an admin to it if you want to keep it secure and performant. I still get angry remembering my experience installing, securing, and setting up caching in front of it.

Or use a managed WordPress hosting service like Kinsta[3] if you don't want the hassle. They'll handle all this sysadmin faff for you...

[0] https://wp-cli.org/

[1] https://www.siteground.co.uk/tutorials/wordpress/real-cron-j...

[2] https://en-gb.wordpress.org/plugins/w3-total-cache/

[3] https://kinsta.com/

I’m working on my first WP project and am trying this approach. A question I have is how do you handle plugins that have hooks that only run once when installed? Those hooks don’t run if you pull in via git. Also if they make changes to the dB (migrations), how is that managed if the plug-in was installed on a different server?

You can check out WP CLI to automate some of this as well.

Yup this is exactly how I do that.

I also have a cron that checks "git status" and emails me if anything changes.

Curious as to how you manage WP with git, particularly around when new files are added by core/plugin updates, which I've always found a bit of a hassle to deal with?

It can be a hassle on shared hosts, but most managed hosts have a git workflow that their agency partners utilize so it’s not too bad if you’re doing anything on a professional level.

I just haven't found a good workflow I guess. I'm gradually trying to strip all the plugins which are not required (there are so many) so I can just focus on the core ones that are hard requirements but even one or two decent -sized plugins is a huge responsibility to manage if you're trying to pretend you're tracking all the changes to any level of detail.

The short answer is yes, you're right - losing being able to write to disk means a lot of functionality is lost. But it does improve security in some contexts so the trade-off might be worth it to some people.

I wrote a small plugin that lets me flick between read-only and read/write filesystem permissions with the press of a button - so when I need to administer it, I just allow writing, and the rest of the time I leave it locked off.

Doesn't work in all circumstances (e.g., if there are plugins that need to write to the disk), but for sites which predominantly have static content it means I don't need to worry as much about things writing to disk in the event something is compromised.

Normally you want all code changes to happen locally, and get tested locally, before they ever make it to production. Which means your client will need to get you to install the plugin.

It depends on the project and client though. There are levels of engagement that are a lighter touch, and in those cases you just accept the mess and risk associated with users managing plugins.

My thinking was a wordpress-specific provider might be cheaper so I went out looking for one with disappointing results. `

I updated my original comment here.

> A good practice is to set up your own cron job on the server and disable the internal cron in your wp-config.php

Defaults matter. And when I was working on it, this wasn't well documented anywhere. If it is now, great. It shouldn't be the default.

> Just install a page caching plugin of your choice[1]

A bad idea, IMO. It's still going through the PHP server and all of the routing/plugin/DB code within WP. Much better to use Varnish (and its ilk) and avoid overloading the PHP service.

> Or use a managed WordPress hosting service

Back when I worked for an remote DBA company, we were tapped many times to help optimize DB access by Wordpress. It reminded me that it's remarkably easy to start a WP hosting company, and remarkably hard to do it right.

This is incorrect. WP supercache generates static html that takes precedence over falling back to the php engine. This is the way it worked nearly a decade ago too.

I wish people wouldn’t spend so much effort bad-mouthing technology they don’t even understand. I don’t even like Wordpress but reading this is super annoying.

I'm not a big WP fan, but this statement is false in most cases. Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk (or CDN) without hitting PHP. Pagely (the post we're discussing) even handle that for you w/ their own CDN. I would imagine they also support request based caching and purging, warming, etc.

Most purely content sites (non-app) can run really well with a very simple TTL based cache (instead of long lived w/ complex flushing). You can very easily use something like Fastly for cloud based varnish w/ an appropriate TTL.

I also feel the need to point out that gatsby type sites and just pre-rendering / caching as well, at least in part (possible using json from a CMS for dynamic data).

I'd be very curious how a WP plugin is managing this.

Third party hosting building in caching, normal in-line caches (like Varnish), nginx/apache caching, sure - I get those, and they behave how you say. But a WP plugin? I'm curious how that would bypass PHP & WP entirely.

On the other hand, this trick was mostly useful years ago when shared hosting plans were really underpowered.

As of today, with improvements of both PHP 7.x and general server performance, even a cache system that uses PHP very early (before any DB connection) to load a pre-rendered html cache file goes a long way in terms of number of pages being served.

Actually, if this become your bottleneck, the .htaccess trick won't help a lot, and you would still look in tools like memcached, redis or reverse proxies to improve things.

I think a lot of third-party hosts provide this out of the box, maybe even using their own CDN. WP is so popular that it's be difficult not to find a service that handled it all for you so long as you have room in the budget.

If you don't know how the cache plugins do this, it's pretty obvious you are not very knowledgable about WordPress site operations. Please stop spouting falsehoods here.

You don't have to know what cron is to install a WordPress site. You don't have to know anything about git or setting up varnish. You just bung the files on your PHP server, put in your database credentials and away you go.

There is a big conflict here between what is practical for users and what is best practice for developers. WordPress has always put user experience first, to the point where it's easy to shoot yourself in the foot and get your site hacked by installing a bunch of badly made plugins. But this tradeoff in the favour of user experience had made it easy for millions of people to set up their own website, and is the reason WordPress is the most popular CMS in the world

Indeed. And so many commentators here on HN (myself included) bemoan FAANG centralization and wish for decentralization and federation and the like... well, this tradeoff is relevant in that matter.

What about the conflict between what is practical for users and what is best practice for users?

Security isn't just a developer's concern. Having to clean up a hacked WordPress site because of crappy defaults isn't very practical for users, either.

WP is absolutely NOT secure by design; it's a hot mess that has helped normalize ignoring security in our web applications. That we encourage its use, that we haven't replaced it with something better, is a damned travesty.

The fact that WordPress.com doens't get hacked all the time means that there are definitely people who know how to do it.

Regular reminder that wordpress.com is a different software product to wordpress.org :)

wordpress.com runs their (relatively) newer JavaScript-based stack; wordpress.org (which is what we're talking about here, unless I misread the article referenced here completely) is the LAMP stack version.

It's written in JavaScript; it runs on node.js - at least the front-end part of it (https://github.com/Automattic/wp-calypso). I don't know what is running on the backend but I don't think it's LAMP?

The point I was making though is that "WordPress" can mean two different things - wordpress.org (the self-hosted LAMP version) or wordpress.com, which is a SaaS offering (so the language is more or less irrelevant unless you're really interested in running your own admin frontend, I guess).

Calypso is our JS dashboard that lets you manage all your sites in one place, plus get cool WP.com features like stats and notifications. It's just a REST API client, just like the iOS and Android apps.

> WP expect you to install it such that it can modify its install folder

Only if you want to have your users install plugins and modify the software with the web control panel. That may be the whole reason why you chose Wordpress, of course. Otherwise it runs well in a read only environment, apart from the attachments folder, and it is also documented.

> It will use incoming requests to trigger "cron" jobs

This is optional, for people who ran it on shared web hosts and didn't have access to crontab. It's all documented in the install instructions.

> It falls apart under any kind of load,

Well, yes. That's unfortunately true for all popular CMS software. It's a similar situation as with Gtk and Qt which are all flaming garbage under the hood. As an X11 user I accept that but I don't have to like it.

It's not noticeable for end users because as you realized in is intended to run with caching. That's the one big thing that should be better documented in the installation instructions. I had to evaluate half a dozen caching schemes just to choose one that seems to work well and is popular enough. There really should be one straightforward way to do it.

If you run multiple webservers, upgrading is extra fun, because when you upgrade, it assumes it can update the mysql schema (which is pretty much totally insane; a www-user writable php script shouldn't be able to create/remove/alter tables). The best way I found was to make a copy of the database, install the new version of Wordpress pointing at the new DB, thoroughly test, and then deploy new version pointing to new DB; then kill the old DB.

And woe is you if your webservers are geographically distant, because there's no way to send reads to a nearby DB mirror; and there's no way to run in read-only, because pingbacks still write to the DB even when they're disabled.

One of the best weeks of my last job was when I was able to finally convince my boss to replace Wordpress for our static company blog with a series of Makefiles and simple PHP to smoosh in all the translations.

You really don't. I've deployed it to Heroku, where the filesystem resets every 24h. It's a part of their famed five minute install for not-very-technical users on shared hosting, but it's by no means a requirement.

We disabled it (except for the attachments folders), and boy did it throw up all over the logs.

Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.

I'm fairly certain for the White House's sort of use case this is not an issue.

> Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.

We did not permit it to have write access to its own filesystem, at all. It worked fine. Uploads went straight to S3 via a plugin.

One can only hope.

> We did not permit it to have write access to its own filesystem, at all. It worked fine.

Cool beans - you installed it sanely. But contrary to how WP expects to be installed. I've corrected the original statement.

No, this is incorrect. WP is compatible with no write access and recognizes it in the default setup workflow.

Don’t blame PHP. We use it to handle millions of concurrent users and it does it without breaking a sweat. It scales horizontally better than basically anything, Modern versions of PHP are remarkably fast, up to 3x faster than Python in recent benchmarks.

The real problem is Wordpress, it’s written like 20 years ago PHP to avoid breaking any plugins. The API is largely writing to global variables.

On top of that, the quality of the given plugins is usually dubious at best, and a lot of people just slather more and more of them on, and they often interfere with each other.

Have you tried doing the same with other technologies?

> It scales horizontally better than basically anything

How does it horizontally scale better than projects written in Golang/C#/Ruby/Python/whatever?

> up to 3x faster than Python in recent benchmarks.

Computational speed rarely matters. If it does, you would usually fallback to C/C++/Rust library doing the heavy lifting, when using 'slow' languages, or just move the workload to async processes.

Web applications spend most of the time doing I/O operations, where async programming makes a lot of sense. Async with PHP is still in its infancy, compared to Python, which has native support for it.

Or, you can keep folders locked down until it’s time to update, then unlock and let it update itself, then re-lock the permissions. This can be done manually or with a job scheduler.

WP needs a caching strategy for performance but so do static blog generators. The static copy is the cache, and rebuilding it is the cache purge.

Edit to add: Wordpress is so popular there are dedicated hosting companies, which makes all this stuff super easy. I managed WP myself for years; now I just have an account at WP Engine and they handle all this stuff for me.

It is amazing how tech people are so far off from understanding real, everyday non-tech people and their needs.

My $5/mo VPS running WordPress can handle about 50rps for an article page...

Here are the numbers from when I was testing how much comment threads impacts load time:

http://imgur.com/gallery/IQk2kun

IMHO, this isn't that fair of a characterization of WordPress in the first place, considering that the alternatives that the GP mentioned don't come close to doing half of what WordPress can do. I could similarly sing praises about how static site generators are so much easier to maintain as a developer than next.js + whatever you cobbled up to handle data persistence, CMS auth, admin UI, SEO, domain specific logic (drafting, theming, social media integration, etc), but again, it's very much an apples vs oranges comparison.

WordPress has become so ubiquitous in web publishing that often it is a client requirement when asking for a new website to a web agency.

Using WordPress is a skill that people put in their CVs, in the same lines where they talk about their MS Office proficiency.

- a custom docker image suitable for use in docker/kubernetes environment. Vanilla wodpress docker image is not suitable for most of our needs, so we build our own images which includes everything we need an nothing more.

- security issues are rare if you follow basic security practice: strong password for administrative users, not installing plugin/themes from sketchy sources (pirated plugins/themes), and keep the number of installed plugins minimal.

- Sometimes a site was hacked by automated bots exploiting zero days in some popular plugins, but we have a clamav instance scanning the wordpress fleet's nfs volume regularly that flags them in timely manner. Containerization is a huge win here because it allows us to quickly redeploy the site with fresh install and prevent the bots from jumping between hosts (none of the bots we're dealing with are sophisticated enough to escape the container).

- Content was a major headache. Each site can use different themes with varying level of quality. We solved this by using Beaver Builder for all new sites with a custom, super minimal theme. This allow our content people to build the site layout visually while minimizing code bloats. This setup is also very cache friendly, unlike some of the themes I encountered in the past.

- Caching is very easy as everything is containerized. Just add a new memcache/redis container into the pod, which is just a few lines of yml or a checkbox in our internal tool. Same with daily backup and granting sftp access to external parties.

- When a client outgrows wordpress, we'll transition them away into a custom solution.

But considering that the initial version of the Site Editor is already part of the official Gutenberg plugin (2) – and they usually include features from the current version of the plugin in the main app – it is expected to be released with version 5.7 of WordPress, next March.

(1) – https://make.wordpress.org/core/5-7/

(2) – https://wordpress.org/plugins/gutenberg/

I pretty much enjoy headless CMS, but at the moment in my opinion nothing beats the ease and use of Wordpress overall, devs and authors.

This is simply not true - modern PHP is very fast.

However that is not fault of the tool itself. There is nothing preventing a competent dev or small team to set up staging and qa environments, a ci pipeline if they are so inclined, write proper tests, be discriminating in the plugins they install and the quality of code they write. And the start threshold for the system is incredibly low, the fact that so much boilerplate functionality is _already there_ saves a lot on development costs and allows you to focus on functionality that really matters.

TL;DR if your wp installation is bad, it's not wordpress, it's you.

> easily modify content

If you have non-technical users editing a site, this one aspect takes precedence over everything else, and it's there that Wordpress continues to generally obliterate whatever workflow may qualify as "simple" to the average HN reader. If you've never used Wordpress' Gutenberg editor (or others based on the same model such as Medium or Squarespace), you should try it. The ability to not only change formatting but page structure and layout in a guided, template-driven way is simply not comparable to editing a Markdown file.

I'm pretty ambivalent on Wordpress' technical merits and its plugin ecosystem is a terrible attractive nuisance for the uninitiated, but if you want to give content authors a robust tool for publishing, there's not much else like it.

I as an experiment decided to use GitHub pages for my personal website and used some random simple looking theme that appeared on its face easy to manage. It wasn’t. The whole process is annoying, making changes to the site is annoying, adding content isn’t straightforward and if this is how all Jekyll sites are I don’t understand why anyone bothers with this sort of set up

The “operations” perspective is the least important perspective on any marketing site/blog.

Design flexibility in production, marketing features and multi-author content production are the only thing that matters.

Gatsby is built by developers, for developers. And it’s hilariously out of touch with the needs of anybody else.

We’re almost 10 years into the static site ecosystem and there’s still no easy way to do even 1/10th of what Wordpress can do without building everything from scratch and duct taping it together with a rigid headless CMS in the middle.

It definitely isn't for the marketing sites and blogs I maintain. Site stability and reliability trump how convenient it is for marketing content creators to release changes. Better to have a site that doesn't have the latest change than a site that is completely down, or worse a site hacked because of a vulnerability in the CMS. Is that true for every site? Absolutely not! Although it seems like it would be for whitehouse.gov.

You’re optimizing for the wrong thing then. Content creation, driving traffic to the site, and converting that traffic is the harder, more important task.

Your role is the easiest, most trivial one.

On the spectrum of engineering problems, I’d place self driving cars and sentient AI somewhere on the right side labeled difficult.

On the left side of the scale, at the far edge labeled easiest, I’d place “keeping a wordpress site online.”

40% of the internet is powered by Wordpress, so I think a few hundred million people have figured it out.

On the other hand, 99% of all websites get little to no traffic. Maybe this is the difficult part you should be optimizing for instead?

Well, the sites I'm talking about get enough traffic that if they are down for a few minutes people notice, and a single wordpress server isn't enough to handle the traffic ;). If you have little to no traffic that's less of an issue.

[Edit] downvotes are fine but let's open up discussion.

Further edit, WP has great static content manager plugins. It's not direct to S3 but a single server can handle a lot of traffic in that mode.

The part that becomes significantly easier is updating that content or adding new ones. You don't need devops to rebuild and redeploy.

No, you aren’t. Wordpress has plugins to generate static html for all of the posts so visitors can be served without database hits.

are you suggesting to run it remotely? on even a small site the performance impact would be noticeable. also, you'd then be securing two systems instead of one

I think we see people choose WordPress because it’s familiar, popular, battle-tested and has a big community with a lot of plugins. It’s a good choice for a lot of people. But that doesn’t mean people picking other options are just taken in by the hype.

I see the benefits of modern component-driven frontend systems but I think the better opportunity would be to integrate this cleanly into existing server-side engines rather than try to recreate the backend entirely or disassemble it down to such low-level build steps.

The podcast ones for instance, they'll allow you to schedule the publishing of a new episode, then upload the episode to all the major platforms, format the images, titles and descriptions automatically for the different platforms, cross post to the social media accounts announcing the new episode, allow you to put in show notes for the blog, and embed a way to listen to the show on the site, all built in, for free, using an interface that is clean and well documented.

Of course I could do that myself but come on now, that simplifies my life so much.

I'm ok with my government saving money and not hiring six figure tech workers to custom roll effectively a press release website. Honestly, they could redirect it to a medium blog and save on the hosting fees as well. The real infrastructure is going to be at the departments, NASA, Smithsonian, CDC etc...

All of the concerns are handled by robust existing infrastructure. That's the point. That ultimately the website backend doesn't matter, our intuitive logic and apprehensions about this stuff simply doesn't apply

Let's take an extreme example, pretend they use GoDaddy as their registrar and someone falls for a phishing email hijacking the domain. The Whitehouse not only could probably seize it back with a single phone call but also get the right people on the phone to stop the DNS record propagation at the root servers as well.

It's kinda like how the police keep their cars running when they're parked and nowhere around. They don't have to worry the same way you and I do about someone smashing the window and driving off, the infrastructural support for their vehicle is vastly different.

Or how the president doesn't have to worry about when to leave for somewhere to beat traffic because the police literally clears the road the president is currently traveling on of all vehicles like Moses parting the sea. It's a completely different kind of logic

...which is a bit like Russian Roulette.

- Big upfront design

- Leverage existing plugins to minimize new development

- Use managed hosting

- Hand off to non-technical or semi-technical people and spin down development to just occasional contract work

If you actually have a FTE developer, it doesn’t fit as well at all. Among other problems, it does not work with a git centric development flow, which any modern dev will insist on.

Yes, it does. Just use Trellis and Bedrock.

I don't think even the admin UI is well organised or consistent though. Most users just know how to create and edit posts. Once you start installing a few required plugins too, the UI becomes even more a mess of controls that users are scared to touch.

However. That assumes you are only needing to edit text with basic formatting (bold, underline, etc...) As soon as you get into anything more complex you pretty much have to understand HTML and CSS.

I just ran into this with three different Wordpress installs. Two use Divi and the third uses WP Bakery. Those are really nice plugins and in 100% of the cases, the person using the site told me they don’t understand what’s going on and kept making a mess of something.

I’m guessing that for The Whitehouse site they will mostly be doing minimal content editing. Then again, they have the resources to have a person who understands HTML and CSS manage the site when things get tricky.

I’m not saying Wordpress is bad but it very quickly can become not as easy to use as most people make it out to be.

While configuring certain parts of Wordpress was tricky at times, especially because deploying it is at odds with the stateless nature of modern containerized infra. Particularly plug-in installation with WP cli requirng a DB connection which makes it tough to fully configure your installation at container build time. I still think it struck a balance between developer experience and a good experience for the content team.

We had already setup a preview page that was wired up to the Wordpress Admin's Preview button that used the endpoint provided by WP to preview content in our UI.

Just a few off the top of my head:

- https://graphcms.com - https://prismic.io - https://www.sanity.io - https://www.datocms.com/ - https://www.cosmicjs.com/

More at the top of this Next.js docs page:

https://nextjs.org/docs/basic-features/data-fetching#simple-...

I've spent quite a bit of time playing with Nextjs, so if you have more specific questions feel free to let me know.

Want to ensure people don't laugh at your WP site - use Hide My WP. You block most common intrusion attacks such as PHP injections, you see where the attempts are being made and the site works. Need to convert the whole thing to a PWA? There's a plugin for that which will do in in minutes and cost $30.

It's like the beer/wine connoisseurs who insist that the 'common' option is just not good enough for them. But $9 wine or $100 - most end users don't know the difference.

The other issue is that visual content editing in WordPress is pretty tricky. Site owners want cool modern design, but editable in the WordPress admin, and meeting them in the middle has proven difficult using Gutenberg. They often find the new UI brittle and difficult to work with, even for core WP blocks. The developer experience is also pretty cumbersome.

If anyone has found an idiomatic approach that works, I'd love to hear it!

There's a new (official) UI system in the works that aims to solve usability issues in WordPress components.

https://g2-components.com/

A refreshing change from them making everyone else's life hell then? :)

Worth mentioning you can also run WP headless and build your front end in w/e js framework du jour you prefer.

I've never even written much PHP in the past. I even added it into the the theme editor so the client could change the text/etc. themselves.

Not sure what you did, but you clearly did it wrong if you think it's hard. It just worked.

Can you give an example of something like that which is not possible with WordPress?

As for the content architecture, Wordpress cpt are limited in their ability to relate to others and to define flexible custom fields (even with ACF.) It’s possible to hack together something like what a more flexible CMS or application framework can do, but it’s fragile and takes a lot of boilerplate, which, similar to template customization, steers the developer towards a similar architecture to other sites.

For these reasons, increased development and maintenance cost make it unlikely that an attempt to develop something truly customized on Wordpress will be successful. That said, many only know Wordpress development so may still get further with it than with a closer fit to their project.

That describes every platform, programming language, layer of the stack, etc. that I've ever worked with.

https://www.whitehouse.gov/accessibility/

https://obamawhitehouse.archives.gov/accessibility

https://georgewbush-whitehouse.archives.gov/accessibility.ht...

https://trumpwhitehouse.archives.gov/accessibility

With that last one not being surprising at all.

Given the icon they chose, it seems like “dark mode” would be a more appropriate name.

Ideally, appropriate accessibility features would just be expected. I'm not intimately familiar with web accessibility, but webaccessibility.com (a random site I found) ranked the landing page for the last three administrations in the mid-to-high 80s.

There's a reason WP has withstood the test of time. (WordPress developers being a dime a dozen also help make the case)

And its also really easy for it to be left without updates or security patches, with an insecure admin account password, and with a set of plugins that open up more security problems.

It might be a bit harder to get up and running with a static site generator but the fact that it's essentially unhackable (through the site itself; the host server has the same issues as any website) is a massive advantage.

The plugin issue is not specific to WordPress.

The fact that other platforms and applications are insecure isn't relevant; we're comparing static sites to WordPress.

However, to answer the point, static sites are significantly more secure than every single dynamic platform that supports a plugin architecture because plugins can be, and often are, written without security in mind.

Unless you really need a dynamic website you should be deploying static assets to the enduser. Practically every business website would be better off being delivered as a static site, even if the admin still use WordPress to edit the content.

> It might be a bit harder to get up and running with a static site generator but the fact that it's essentially unhackable

You could also use WordPress to generate a static site, just add a caching level on top.

JAMstack sites are annoying to build, so much minutiae and configuration, abstractions on top of abstractions, and you never own the codebase as it's frameworks and libraries all the way down. You spend half your time trying to figure out if X could work with Y, rather than just making X do Y's job by writing some actual code for a change.

Frameworks and libraries aren't really necessary for JAMstack. JAMstack really just means relying on external services for dynamic content. You don't have to use Gatsby or Hugo or whatever. A JAMstack site can be a single HTML page with a script tag (and all mine usually are).

I built my own static site generator and I feel so much more ownership over the code. You should try it. Not only is it my code all the way down, but it only runs on my machine. All the generated assets will remain functional and security bug free as long as browsers understand HTML, CSS and JS, even if I never update the code again.

what is the implication of such a trademark? can unaffiliated companies not use the term now? this is a little surprising.

Or all of the above. And that might be a good enough reason, but to imply it's the best technical option warrants some skepticism.

Not to mention things little security issues.

I don't have an agenda against WordPress and very often when people ask me what they should use for simple projects I say "just use WordPress."

My rule of thumb is that will probably be alright for a simple, small project, but will have to grow up to something else to scale reasonably.

WordPress essentially generates static pages and is trivially set-up to run behind a CDN like Cloudflare.

You can easily have WordPress sites in the Alexa top 50k that run on a $5 VPS - behind Cloudflare.

> My rule of thumb is that will probably be alright for a simple, small project,

Right. Simple, small projects. Like whitehouse.gov.

As long as you use Wordpress for what it was designed for, it really doesn't matter what scale you have.

Check out Cloudflare's Automatic Platform Optimization tool from last year [0]. It uses Workers to cache static and dynamic content from WordPress on the edge. Just $5/month.

IMHO, that would "scale reasonably" for many use cases.

[0] https://blog.cloudflare.com/automatic-platform-optimizations...

It's an expensive compromise that you shouldn't need unless you're in Alexa top 100 territory.

Not a snarky or leading question, I honestly don’t know. I use Hugo for my own internal design things, because I want partials and such, but I have no idea where the ecosystem is at for the “we need a poli-sci intern to copyedit this” use case.

- continuously serialize WP to static files

- Make it easier to work with Wordpress as a CRM (No Code or at the very least don't force developers to touch PHP)

JAM stack would near instantly cease to make any business sense (though developers would still love using it of course).

A lot of the issues with Wordpress are sort of long-tail -- combinations of plugins exposing leaks in the abstractions, etc.

BTW, if anyone is working on solving this, I'd love to know about it.

Any cache plugin for WordPress does this already, but if you mean something that does this in order to host elsewhere (like in Netlify), WP2Static is a solution.

Do some cache plugins actively walk your site and generate the pages? How do they handle when user login plugins are present? I'd expect a naive/basic caching plugin to add to the cache when a page was visited, not necessarily ahead of time.

https://www.usds.gov/faq

I chose it because they just need to publish basic info, much like most govt places, and all the non-tech people find it easy to add content.

It's been up and running for 8 years using the same webhost. Easy to keep up to date, and easy to use, and it solves their business problem.

Nothing wrong with WP when you just want to post simple information.

It’s the typical “developer’s developer” solution. Fun for the dev to set up and write an article about how they built it on Dev.to, but with zero thought put towards the marketing functionality or flexible content production that any end user will need.

Developers don’t understand that their role in the process of creating a marketing site is the least important one. The marketing functionality (advanced SEO, newsletter sign up, form collection, landing page generation, dynamic header banners etc) and multi-author content production is all that matters. Otherwise nobody will ever be visiting the site.

Content is king. Not “developer pleasure is King.” Hence why Wordpress runs most of the internet.

Strongly disagree. Drupal is a great CMS and there's a reason the government uses it so extensively.

I'd still choose it over WordPress any day. But the days when I'd recommend either of them (or indeed anything in PHP) are long gone. Your best bet now is probably a static site generator such as Hugo. If you insist on staying in database-driven CMS land, at least go with Django or Rails.

Static site generators are great for truly static content but that's extremely rare anywhere where content is frequently edited.

I have used Hugo in the past to generate websites from external content sources, such as trello, gitlab, GitHub, RSS feeds, Dropbox, headless CMSes, etc. Some of them provided webhooks to trigger the build, others required polling and periodic rebuild, yet others can commit to a git repo and trigger a CI pipeline. Most of the time, hugo was more of a composable solution to a given flow than a constraint i had to build around thanks to its capabilities to use "data content" and not only markdown files. Using json as the metadata "front matter" for documents often proved very handy when using API sources.

Hugo is very fast, so build time wasn’t a big concern. There was no incremental build however, so for a very large corpus it could be an issue. The most problematic issue is that Hugo doesn’t ever delete anything from a previous build, but overwrites on top, so that could be problematic if you involuntarily publish something and then want it off. The same kind of issues you get into with caching or object storage. My "solution" was the classic parallel builds, symlink and cleanup dance.

Would recommend.

Static sites are a tradeoff, and you’re often dealing with other messes especially with non-technical users.

It's also a security nightmare and runs dynamic code on every page load by default, so a fresh wordpress install in its default state will fall over when on HN on Reddit or Slashdot, unless you install third party caching plugins to avoid that.

It's a bad app.