Whitehouse.gov Chooses WordPress, Again
pagely.com
pagely.com
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.
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.
And now your page displays a white page. Error in the log is an exception with no stacktrace/location. This was my experience in production a few times.
It's a fun system if it works, but without a testing pipeline and a staging environment it's a lottery with a possible mystery breakage on every update/change.
That describes every platform, programming language, layer of the stack, etc. that I've ever worked with.
Wordpress and a lot of php community does actually like the "drop in some code and it usually works" approach. This encourages continuing on that path.
On the other side, the failure can be handled in many ways. "This module could not be loaded and will be ignored." is one. Ensuring some preparation / validation is needed before upload is another.
Let's not go to extremes like "you're expected to have a staging environment for your personal blog because the framework cannot possibly help you".
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.
[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.
> The part that becomes significantly easier is updating that content or adding new ones. You don't need devops to rebuild and redeploy.
From my perspective as an SRE, that's actually a bad thing. I've seen content creators take down big parts of the site because they changed or deleted an asset. Most of the time that could have been caught by automated tests as part of a build pipeline, if one had been in place.
There is certainly a trade-off though. Wordpress and Drupal are great for quick turnaround content creation and editing. If you want your changes to be live as soon as you make them , Wordpress is better at that than a static site generator. On the other hand if you want rock-solid stability, and want any changes to go through a gamut of automated tests, Wordpress is not a good fit. It is possible, but it definitely isn't easy.
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
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.
Worth mentioning you can also run WP headless and build your front end in w/e js framework du jour you prefer.
~~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.
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.
> 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...
[1] https://www.siteground.co.uk/tutorials/wordpress/real-cron-j...
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
My thinking was a wordpress-specific provider might be cheaper so I went out looking for one with disappointing results. `
Yup this is exactly how I do that.
I also have a cron that checks "git status" and emails me if anything changes.
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:
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.
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.
You wanna run 2 blogs on Ghost - run 2 instances, same for _everything but Wordpress_.
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?
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.
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.
Even can do a CI/CD system.
Just a shame there’s no liability for negligently causing users to get infected.
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.
Stuff like NFS made sense for on prem but it’s a terrible solution for building services on AWS (for example).
Security wise, any popular CMS will be a security nightmare. It’s not even a PHP thing. In an ideal world you’d stick your CMS behind a WAF and put some additional policies around your admin APIs (if at all possible). Wordpress, for all of its warts, actually made those parts easy to do.
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.
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.
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...
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?
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.
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.
It is amazing how tech people are so far off from understanding real, everyday non-tech people and their needs.
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.
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.
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.
- 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.
This is simply not true - modern PHP is very fast.
> 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.
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.
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.
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.
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.
> 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 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.
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.
A refreshing change from them making everyone else's life hell then? :)
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.
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)
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.
Used be that we had writers, editors, type setters, printers and book-binders, and I think the output was more professional.
I think there’s still a case for the non-technical users just writing the words, and keeping away from the presentation and delivery.
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.
- 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.
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.
More and more non-tech people are happy to be introduced to github. It's just an 'article' dir where you upload your markdown file, then click on 3 green buttons to create a PR.
They're happy to discover the integrated discussion system, issues, kanban, etc.
Of course, tailor it to your audience. Some people cannot read English and will be frightened by the interface.
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.
Drupal 7 lost some modules, and Drupal 8+ lost a lot more.
It seems easy enough at first, like you can just use whatever contributed modules you need, but that only works on simple sites (like the same ones Wordpress is great for). To use Drupal well, you have to actually know the APIs and write your own custom modules, otherwise the site becomes a buggy resource hog.
I like Drupal, I have multiple 8/9 sites I still run and I've used it since 6, but there's some pretty good reasons not to use it.
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 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.
Entire large businesses (WPEngine, for example) have been built upon the overhead costs from blog operators having to compensate for it being a bad app.
My close friend is one of the sysadmins for the WP instance mentioned in TFA. Pull back the curtain and it's pretty ugly and resource-intensive to run WP at scale; I've done it myself.
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.
After looking at the FTP, I've found out that the hoster locked down the page due to wordpress plugins which did not have been updated and turned into malware providers or something like that.
The whole thing is a monster. It has almost 30 plugins for the most stupid thing (like scrolling text). So the first thing I did was updating it. Unfortunately it looked messed up afterwards. So I rolled back the backup and started updating it one by one. I was left with one plugin which I could not remove or it would break down parts of the design. So I'm again left with an possible problem for the future.
The joke is: the page is mostly static. There is one single news section which has not been used for more than a year...I hate this thing...I wish I could give it to somebody to rebuild in plain HTML or something but the boss doesn't want it...
If you are trying to deploy WordPress today with DevOps best practices (version control/12 factor app/etc): set it up with Bedrock (https://roots.io/bedrock/), manage dependencies with Composer, and use environment variables for the runtime configuration. Then use Phinx (https://phinx.org/) to do database migrations. A custom db migration script will be needed to change database settings based on the environment you're deploying to.
Containerization is pretty annoying, because apparently php-fpm will not serve non-PHP content (without creating security concerns). So you need a web server to serve all the static content that comes with Wordpress/Plugins/etc, and php-fpm to serve the PHP. This means you have to either 1) duplicate the static content between two different containers, 2) duplicate the static content into some other storage medium (S3?) and serve it using some web server, or 3) create a frankenstein's monster container of both php-fpm and a web server, and pick your poison on how to make that suck as little as possible.
I have opted for #3 as operationally it's the simplest. You build one container with all the dependencies, static content, and sql migrations, and deployments therefore become just a single container with a single port (http/https) and passing in the env vars. I'll probably upload it somewhere if somebody wants it. It's a docker-compose configuration, plus the Frankentainer, and some scripts, and it all fits into a Bedrock install. I haven't hooked migrations up to it yet, but once that's done, it will actually not suck very much to maintain a WordPress install.
x-build-back-better: https://usds.gov/I'd like to see the project's requirements.
The contrast and typo sliding menu was present on the bidenharris and or joebidden.com websites.
This is a super clean and simple feature website. They could offer supports very widely, and the cost won't be high! (I'm a web developer)
> effort
this simple theme can code in ONE day.
https://docs.microsoft.com/en-us/lifecycle/faq/internet-expl...
"Internet Explorer 11 is the last major version of Internet Explorer. Internet Explorer 11 will continue receiving security updates and technical support for the lifecycle of the version of Windows on which it is installed."
IE is already a security hazard for users. IE doesn't support any of the content security policies implemented in other modern browsers, which makes its a target for every possible XSS scheme and what not.
https://caniuse.com/?search=csp
If your users use IE you are putting them at greater risk than any other browser users and the former should be actively discouraged to do so.
Maybe if you stop forcing your users into your authoritarian ideals, people might start to change their perception of you.
So if u have a static wordpress website, just add a CDN in front (not using a plugin like many do, but by editing your DNS)
Even without plugins, WP performance will start to degrade due to how it handles post "meta" data. As the wp_postmeta table grows larger in size, it will generate longer running queries as it tries to query against non-indexed key + values. At a certain point, your only option is to start modifying WP core code and the DB tables for your specific needs...which at that point, the poor software architecture becomes an enormous problem. Granted most small blogs will never see these kinds of issues since they will never reach these inflection points, but they needlessly exist none the less.
The post meta table can scale fine to hundreds of thousands of post objects without needing special infra or handling. The WordPress core has a caching layer for metadata, and either way it's not like "SELECT * FROM wp_postmeta WHERE meta_key = 'foo' AND post_id = 1234" is going to be a performance bottleneck regardless of the size of the meta table.
I feel improving the security architecture of plugin integration could go a long way. Although using lesser plugins, only from trusted developers, keeping them updated, using other security plugins(Firewall, 2FA etc.) and regular backups can help keep WP instance safe to some extent; There's absolutely no excuse or explanation for random database errors with WP and that was the final nail in the coffin for me.
I started building my own CMS using Go for complex websites and for simple websites static web pages using Hugo with markdown does the job.
Not sure what pages you are looking at.
Accessible design is good design. Everything we build should be as inclusive, legible and readable as possible. If we have to sacrifice elegance - so be it. We’re building for needs, not audiences. We’re designing for the whole country, not just the ones who are used to using the web. The people who most need our services are often the people who find them hardest to use. Let’s think about those people from the start.
https://www.gov.uk/guidance/government-design-principles#thi...
In my personal experience however, using gov.uk has being a mostly pleasant experience and don't much care for opinionated "elegant" design.
I wish very much that there were 10% as many attractive themes available for static sites. Yes, you can port them, but it's a pain. And yes, you can design them, but it takes more time and most programmers don't have the design chops to pull it off.
and ease of starting with an almost-free "unlimited" shared hosting.
These are the only 2 good things about WordPress.
> I wish very much that there were 10% as many attractive themes available for static sites. Yes, you can port them, but it's a pain.
That's what I always did whenever I needed a website design.
By this do you mean plain HTML/CSS themes that you can edit yourself, or themes that are integrated and can be edited within static website providers?
But the real issue at stake here is more subtle than the question of the experiences of end-users vs developers, or of ecosystems vs. complexity, or is insecure vs secure.
The real issue is writing “static content-heavy site” as if static and content-heavy must go together. There is an assumption that a content-heavy site will be static. This is not true.
I’m baffled that almost all content-heavy sites relegate dynamic content to “Related content” and “Recommended content” to sidebars and post-content sections. Facebook and social media, one could argue, have become successful in large part because their content is dynamic in the same way ad-tech is dynamic — presenting the content contextual to a particular user’s interest and behavior. Tik Tok does this the best.
The enduring legacy of Wordpress (regardless of whether you use Wordpress or some alternative) is that the content-is-static mindset has become an unquestioned axiom. The very idea of a WYSIWYG is that content is and always will be static.
Although Tik-Tok has demonstrated the power of dynamic delivery of content, the content itself still remains static. How could it not be, most people still locked into the static-content mindset might ask.
But there’s no reason that individual chunks of content can’t be dynamic too. After all, we do have different sized thumbnails for previews of content on different screen sizes. So why not different versions of headlines? Or different versions of an entire article (not simply teaser vs. body).
The reason is that, as always, our imaginations are limited by our tools. Our content tools embed an impoverished imagination.
The content-world is waiting for a startup to give us a CMS that embeds an imagination where content is dynamic, both in delivery and in substance. Moreover, with tools like GPT3, the generation of adjusted content is now practical. While an editor could write 100 versions of an article, based on combinations of style, tone, and length, GPT3 could generate drafts that would reduce an editor’s work to ... editing.
The CMS is ripe for fundamental innovation. Here’s hoping someone is working on it!
I wish the new Whitehouse.gov website gave a more descriptive 404 indicating the change or better yet, perform a 301 redirect so the original Whitehouse.gov link[5] works.
[1] https://trumpwhitehouse.archives.gov/wp-content/uploads/2018...
[2] https://www.last10k.com/sec-filings/unh/0000731766-18-000005...
[3] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7357013/#idm140...
[4] https://trumpwhitehouse.archives.gov/
[5] https://www.whitehouse.gov/wp-content/uploads/2018/03/The-Pr...
1. Viewers
2. Writers/Editors
3. Maintainers
Technology tools are just means to an end.
I am sure there are people from https://www.usds.gov reading this. And I hope they would cherish the great opportunity of a green field to build a secure, robust public service system that are enjoyable to use for all types of users.
Wish them the Best.
At all? Even if you contact support because you accidentally deleted a lot of stuff?
The development experience means I love it too. I never did find a simple Wordpress workflow for managing staging and live sites in git. With Wagtail/Django keeping the configuration in code, a git workflow works.
Edit: Apologies if you were actually asking about a solution to allow non-technical people to create a site, rather than manage it.
For simple static content there really is no need for a database or anything at all, people just want the convenience of writing content dynamically and the database is a necessary evil in wordpress to make that happen.
If you need to handle a certain amount of user submissions (that can't be handled by forms/etc) you use JAM stack - javascript + API behind it.
What so many developers get wrong is that a lot of average users are used to writing in WYSIWYG environments like Microsoft Word. And despite Markdown being easy, once again, you lose the visual publishing experience in a lot of these static options. Markdown is easy for developers, but average users will struggle (especially with complex markup like tables or even images).
It's sad that the only options given to people nowadays are either JAMstack hype nonsense or the WordPress poop monolith.
Wordpress makes it very easy for users to manage website content for the end users. But for developers, simplicity depends upon personal preference.
I like the the whole project to follow a same set coding standards irrespective of whether it's a procedural paradigm or OOP or any other. But, if you look into the wordpress core, you will several sets of standards which makes it harder to follow through whenever you try to understand the core. For simpler plugins, one might not need to dive into the core but I have had a fare share of projects and plugin development where I had to go through the core. And, it still takes me some time to understand whenever I have to do so. Maybe, I might be using Wordpress for wrong reasons and wrong project (because that particular task can be easily achieved using other technologies or even if I start coding from scratch without wordpress), but clients are always right and I have to use the technologies they prefer.
I had to google that because for a split second I thought the US had a minister of Propaganda. It's a job title at Pagely.
Can't they just use the Gov't CMS
again? whenever they had to run an update?
100% of the criticism will be by devs with little or no experience with WordPress.
It's almost an in-joke to hate on WordPress at this point.
At that point it's not full WP per se.
While wordpress gives you a GUI editor, and you are good to go