I hope we again see the value of using systems like Wordpress for it’s simplicity in getting a blog/website setup and easily modify content.
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.
Simplicity? Perhaps in its use, but not the code. The code and hosting requirements are, frankly, Frankenstein's monster levels of frightening.
~~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.
>Simplicity? Perhaps in its use, but not the code.
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.
> Nobody but other devs cares about the simplicity of the code if the code works.
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.
> They care when you start quoting a week for a simple addition that should take an hour
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.
This conversation is feeding my suspicion that a lot of the problems people have with Wordpress come from not knowing how to work with Wordpress.
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.
I've worked in environments using the exact approach you described, and it definitely seems like the prevalent workflow using these CMSs.
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.
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 in static languages, if the syntax error is in something that will be reflected/eval'ed, etc (which in many languages includes regexes -usually not validated at compile time-).
If people avoid installing plugins and custom themes, and absolutely do not change the theme so that automatic updates have to be turned off, and they also install automatic updates, then its pretty fine.
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.
The NFS requirement for multiple Wordpress hosts are an instant deal breaker for me when discussing CMS on the cloud.
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.
Those independent servers haven’t gone away just because there are new toys in the box. They are still fast, cheap and ubiquitous.
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.
Sorry, by “independent servers” I meant self hosting / on prem. And while that hasn’t gone away entirely it has diminished massively as companies deprecate on prem hardware as hardware ages and replaces those resources with cloud services.
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.
> Security wise, any popular CMS will be a security nightmare.
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.
You’re overlooking a key thing there though. You’re assuming every hack is a targeted one. And that simply isn’t the case.
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.
It’s extremely rare for automated attacks to scale against popular CMSs before the patch for that vulnerability is available. In the vast majority of cases the script kiddies find out about the vulnerability when the patch is released. Then some bad guy has to write the script to target it, and distribute that and/or scale it. All a site owner has to do to win, is patch faster than that.
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.
> 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.
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!
> It’s extremely rare for automated attacks to scale against popular CMSs before the patch for that vulnerability is available. In the vast majority of cases the script kiddies find out about the vulnerability when the patch is released. Then some bad guy has to write the script to target it, and distribute that and/or scale it. All a site owner has to do to win, is patch faster than that.
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.
That very much depends on a case by case scenario.
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.
In theory that’s true but in practice there needs to be a common file system for WP to function properly otherwise you end up with a lot of kludges that break the admin panel or that adds other caveats to WPs normal behaviour.
Depends on a persons use case because but not all WP installs are blogs / news sites.
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.
That’s only half the battle. The working directory is designed to be writable so you either end up with PHP files copied onto the host with some complex syncing that breaks the admin panel, or you accept that the hosts share a common file system.
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.
Wordpress is also the only CMS that offers multisite hosting - single codebase, single webserver, one docker container - for running multiple sites with different configuration.
You wanna run 2 blogs on Ghost - run 2 instances, same for _everything but Wordpress_.
Well, Drupal has multisite capability, too. I don't think using multisite is actually that good an idea. Having two separate websites be dependent on the same codebase is very prone to cause serious life cycle problems. I'd advice against using multisite on WP or Drupal.
We have been doing this successfully for many years, no problems. Some multi site installs have up to 300 sites running on them.
You have to know when to use the available technology.
Spot on. I am currently working on a project that has over 25,000 multisites running in WordPress Multisite. The amazing thing besides the sheer number is WordPress has not been a problem, throw it on AWS and the scaling issues are solved. People who proclaim that WordPress can't scale have never built anything scalable with it.
Well it’s a security shitshow and a fav for hackers looking for an easy exploit vector: just compromise it once and voila! All website consumers are at risk.
Just a shame there’s no liability for negligently causing users to get infected.
WordPress is not without its design flaws, some of which make sense from the point of view of helping non-techies run their own sites (such as making updates easy.) But as someone who has built 100s of sites with WordPress I feel the need to defend it on a few points here:
> 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);
Again this is a decision I imagine was made to support shared hosting environments. They've made it easy for 99% of users, which is why it's so popular. We the remaining 1% who prefer to use real cron can edit the config.
> 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...
> I prefer to version sites with git and install updates locally, then git pull down on to the live server.
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?
That is all usually still triggered even when using git. Git doesn't manage the database, so when the files make it to production and the plugins are activated, they see a database they haven't been installed in and then correctly run their hooks. Same for migrations. Migrations are managed with database entries, so if your production database doesn't have those entries, it will still run the migrations.
You can check out WP CLI to automate some of this as well.
As far as I know there aren't any real hooks available for running code on plugin install, only activation. But I think OP is referring to core WordPress code and not plugins.
> 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.
Yup this is exactly how I do that.
I also have a cron that checks "git status" and emails me if anything changes.
> 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.
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?
Disable automatic updates on production. You don't want automatic updates on a production site anyway, they could bring your site down without you knowing. Instead, install updates and plugins locally, test locally, then push to live. That's really true for any code versioned software.
The most common approach is to store everything but the wp-content folder in git, including plugins. A way to save space there is by using composer so your Repo only needs to include custom plugins that your team wrote.
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.
The problem is the only thing I really care about is the stuff in wp-content! I've inherited a few sites with custom themes and it's the changes in plugins that I'm most interested in so I can track issues. Almost anything else that comes from latest.zip I am not concerned with.
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.
I keep things really simple to be honest, normally I exclude wp-content/uploads and wp-config.php in .gitignore. And set the perms so WP can't write to the filesystem on production, except for the uploads directory. We install and test updates on a dev environment first then commit everything and pull it in on production.
If you don't let production write to the filesystem, doesn't that get rid of one of the main advantages of WP, that users can configure the site by adding plug-ins and such? Or on the 100s of sites, you are responsible for all the plug-ins?
> If you don't let production write to the filesystem, doesn't that get rid of one of the main advantages of WP, that users can configure the site by adding plug-ins and such? Or on the 100s of sites, you are responsible for all the plug-ins?
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.
If your using a versioned codebase you likely don't want that anyway. Otherwise you'll have untested code on production, and you'll have to commit it to the project repository from production.
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.
Pretty much any shared hosting can support Wordpress. Kinsta was a suggestion where you pay for someone to manage and install things for you which is a lot more than hosting.
Happy to host your relative's site on WP.com, here's a 50% off coupon for HN peeps that will work the next 48 hours: HNEWSJANMATT . Please tweet me if you want any extra help from our team on the migration. I hope your relative is very happy.
> 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.
> 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.
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.
Caching is hard. Drupal used to, may still use the dB for caches. So you get pool issues. You have to also throttle features, like site Search or other intensive scripts. So in the main the internal caching is a step up from none.
> 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.
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).
> Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk
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.
Server rewrites. Usually they work adding rules to Apache .htaccess.
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.
So I don't normally setup WP sites, but I have as a favour. A caching plugin just generates the HTML files and you configure NGinX / Apache to the appropriate directory. Historically I think most did it via .htaccess w/ Apache for shared hosts, but I've only configured it w/ NGinX. E.g. https://www.nginx.com/blog/9-tips-for-improving-wordpress-pe...
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.
A lot of them do it via special htaccess rules. Check the cache first for an html file, otherwise, fall back to PHP. If not, there may be a little php code running but generally much less than a “normal” request.
>I'd be very curious how a WP plugin is managing this.
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 touch on a really good point here about the default cron setting (yes, it still uses the lazy cron on page load by default.) From a developer point of view this is questionable at best, but from a business point of view I reckon decisions like these are the core of why WordPress is popular.
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
>But this tradeoff in the favour of user experience had made it easy for millions of people to set up their own website
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.
There is a big conflict here between what is practical for users and what is best practice for developers.
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.
I realize that it's really written for end users instead of developers, but that means scares me every time I see something as high profile as the White House using it. For the exact reason as you say here: "it's easy to shoot yourself in the foot and get your site hacked".
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.
Unless the new Wordpress is written in node, comparing the new “JavaScript” stack with the old “LAMP” stack makes no sense to me. Those technologies do not serve the same purpose.
> Unless the new Wordpress is written in node, comparing the new “JavaScript” stack with the old “LAMP” stack makes no sense to me. Those technologies do not serve the same purpose.
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).
We run WordPress multi-site on WP.com to power several hundred million user accounts. So whenever you visit a domain hosted by us, you're hitting 99% core WordPress, plus some custom plugins and code we run to make it multi-datacenter and super-secure.
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.
Yes, but there are also a lot of people who don’t. I still use an RSS reader and basically every six months, a blog that I followed 5 years back and went dark will get taken over by spammers because no one was paying attention to it anymore.
I've had to run Wordpress against my will a number of times and while it's true that it a hacky mess it's also pretty well documented and as long as you use it as intended the end result is quite usable. It's PHP so pretty well tested deployments, metrics out of the box, individual interpreters for customers work well, it can be chrooted. Basic stuff like this has been built in with PHP for a decade.
> 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.
So much this. It's been a bit over five years since I had to run it, but this is what I remember.
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 have to let it modify its install. Security-fucking-nightmare.
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.
It is if your users expect to be able to add plugins themselves, or you want it to do automatic version upgrades.
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.
> It is if your users expect to be able to add plugins themselves, or you want it to do automatic version upgrades.
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.
With all due respect, you have demonstrated a shocking lack of knowledge about Wordpress. It’s been a long time since I’ve read so many falsehoods spoken with such certainty. That’s not a good thing.
> because of unoptimized DB queries, and because of PHP
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.
> We use it to handle millions of concurrent users and it does it without breaking a sweat.
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.
WP only needs to modify itself if it updates itself. You can manage updates yourself with a git or even a CI workflow if you want to. These work the same way for WP as they do for a static blog codebase.
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.
There's plugins and WP developers galore. Actually, for $89.99 per month you can have a team that watches and fixes your site as and when things go bad. All of the above does not appeal to the masses. Hide my WP takes away the security risk in minutes of adding the plugin.
It is amazing how tech people are so far off from understanding real, everyday non-tech people and their needs.
50RPS must be tuned or cached in some way, as the memory load for 50 requests to the full app should overwhelm the 1GB server and ~50-100ms is typical and the $5 instance has one core.
The difficulties you mentioned seem naive at best. Throwing a cache in front of a high traffic site is common sense these days and not really stack-specific; keeping up with security updates is hard with any stack (npm package upgrades can be quite the nightmare); installing... have fun docker composing your app with a mysql image, I guess?
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.
While, as others already pointed, most of your examples are debatable, I think parent was mostly talking about the simplicity about EDITING content, ie the benefits for the end user.
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.
After a decade of dealing with a fleet of wordpress sites (most of our smaller clients has a wordpress site), our team has settled on a workflow when dealing with wordpress sites for our clients:
- 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.
Just a quick note regarding Beaver Builder: when the Full Site Editor arrive on WordPress this year, we will be able to use native functionality to build the entire website, without relying on a third-party page builder to do this.
They said (1) that there's no fixed date for the launch, as this is an ongoing effort.
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.
There is some truth in here. However, CMS come and go and Wordpress is here to stay. Rules, rights, extensibility. It ain't perfect, however overall rating is still best in my opinion.
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.
I love Wordpress but don't use it for 90% of the things I do. I grew up with Wordpress and I love that the code is simple for someone new to PHP. Wordpress for me, with no programming background at the time, was so much easier than Zend for example, which was very popular at the time.
I have worked for several years with WordPress. Everything you say is true if the devs are incompetent. Then yes, the variety of ways one can shoot themselves in the foot and completely dead with the system is astounding. I have seen horrible wp installations galore myself.
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.
The threads of replies debating the technical "simplicity" of Wordpress are missing this part:
> 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
From an operations perspective, gatsby and next.js are much simpler though. You are just deploying static content behind a webserver or even something like s3. Horizontal scaling is almost trivial. With wordpress though, you have to worry about a database as well, scaling is more complicated, you need to run php on your webservers (which has security implications), updates that include schema updates frequently require downtime, etc.
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.
> The “operations” perspective is the least important perspective on any marketing site/blog.
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.
> Site stability and reliability trump how convenient it is for marketing content creators
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?
> 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.
There are static site builders for Wordpress so you can use WP only as an admin tool and deploy a package to s3 or whatever. Build times are relatively trivial unless you have 10s of 1000s of pages.
I think we are talking about different things. I'm not talking about static assets that you use in your site. I mean the entire site is static, and thus doesn't require any database or any server-side page generation. Which means not only that it is easier to scale since you don't even have any state in the database, but each node can also handle more traffic, because it is doing less. (And if you something like s3 or github pages, or netlify, you don't even need to worry about individual servers).
> 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.
This is why I generally recommend a solution like Publii (also Open Source) for simple sites that don't need extreme flexibility. It's “client friendly“ as WordPress, but generates static content in nature.
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
All websites require a source for their data (i.e. a database), but many websites don't really need to be directly connected to a SQL database for nearly every page request or similar and can just use really simple files in S3 or something.
Many, many informational web sites do not require a database, including many non-trivial sites I've done for clients. Hugo is particularly adept for non-trivial static sites (via it's ability to use built-time API json data, etc).
Is that because WordPress is simple, though? There are similar CMSes you can use with e.g. Gatsby. They’re just a glorified build systems, after all — there’s nothing inherently complex about the content management experience. And on the flip side, it’s possible to load up WordPress with enough plugins that it becomes a nightmare to use.
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.
Yes because Wordpress includes frontend rendering (of both the actual pages and the backend admin) by default. This means you get working HTML powered by dynamic content out of the box, and it keeps working as content changes without needing constant builds for static sites.
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.
Wordpress also has a really rich ecosystem of mature and widely used plugins that are quite easy to install.
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...
Governments should moderately prefer self-hosted solutions to cloud services, especially when a president just got banned from all social media platforms.
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
I excluded plugins because additive functionality and ecosystem are independent of the core product, but yes Wordpress (and server-side apps) can be extended to do much more than a plugin in a static build process.
Evaluating WordPress without its plugin ecosystem is like evaluating Linux or github or node.js without its developer ecosystem. Of course the bare platform will be worth a lot less without the social networking effect and the diverse applications it supports.
- 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.
Eh, the efficiencies you describe happen regardless of whether the dev team is full-time or outsourced, and I think there are ways of doing git flows with WP.
I am not familiar with them, but a quick Google seems to suggest they won’t work with WPEngine, Wordpress.com, etc. In any event, they’re bolt on solutions, but the core of Wordpress is still a mess of configuration split between files on disk and the database. There is nothing so valuable about Wordpress that you couldn’t just get a more reliable solution from scratch than by bolting more stuff onto WP. I’ve heard people say “oh, our users are already trained on WP, so it’s a good CMS” but I don’t buy that at all. I’ve had users praise my homegrown CMSes before. There’s not much difficulty in pairing a WYSIWYG text editor and some form fields with modern web stacks these days.
> “oh, our users are already trained on WP, so it’s a good CMS” but I don’t buy that at all. I’ve had users praise my homegrown CMSes before. There’s not much difficulty in pairing a WYSIWYG text editor and some form fields with modern web stacks these days.
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.
Gatsby isn't a CMS in the WP or Drupal sense of the word. Gatsby to me is more of an "integration first" minded architecture. That is, Gatsby is a way to unite multiple services, CMS's and content sources. But other than using .MD files Gatsby doesn't really have the ability to manage content in a true CMS sense. It's not like you log into some Gatsby admin panel and add content.
It’s true that Wordpress is very good at letting you modify content easily. That is, as you say, a major reason to use it.
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.
This is why we built Gutenberg, which is the new editor in WP that allows you to do rich layouts without using Divi or Bakery. Gutenberg is what the new White House site uses! You can do really advanced things with it.
I built out a site using headless WP with Next.js as the frontend. With server side rendering of React, we still took advantage of caching the HTML in a CDN like you would with vanilla WP but it was much easier to build our own theme as desired with React.
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 didn't use it initially because the site was built before they launched that feature, but it definitely reduced some of the boilerplate that we had to write ourselves to wire up Next to WP.
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.
Is there a CMS that has a Wordpress-like admin panel and content editing tools that builds and deploys the needed updates to a static site when you save an article, etc.?
Yes, there are lots now! There are some good ones, but some are definitely way pricier than I think they should be. With Next.js, you can even use Wordpress as a cms to back a static blog (https://github.com/vercel/next.js/tree/canary/examples/cms-w...)
But Dev's are the people who had issues with WP. WP has been given this awful image but when you can buy a fully functional LMS system for $69 with 6 months support, you just can't beat the value.
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.
I have been thinking about what solution is for this. Do you think users would be happy with a WordPress backed headless app?
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!
Nothing is stopping you from setting up a site in Hugo or something similar. I don't really understand why dynamic rendering or a huge amount of JS is required other than continue down the road of bloat.
A pretty standard stack I've done recently is Netlify, Gatsby (I'd lean next at this point) with Prismic, Hubspot and GTM. It's barely more investment to setup than WordPress but lets you build something visually sophisticated really easily and you get user friendly CMS, CRM and all the analytics and user engagement stuff. And running headless means there's almost zero attack surface.
Which CMS were you using though? Netlify CMS? Last I looked at it, there was a lot to be desired (not to belittle their effort, but not even close to WP in terms of functionality).
Worth mentioning you can also run WP headless and build your front end in w/e js framework du jour you prefer.
The very point of OP is that this micro-service approach is bound to provide a poorer user experience for non-technical users - the vast majority will reason about and operate a monolithic CMS with much more ease.
Poorer author experience maybe. The end user experience will likely be better. And the business results of using a proper CRM and audience engagement product will be far superior.
Have you ever tried to customize or add functionality to Wordpress? Because if it’s anything like Drupal or other PHP based tech of a certain era, it’s hell
Yes, a few months ago, it was ridiculously easy. It literally took me 20 minutes to customize how the side bar was working and embed some new dynamic content. I even inherited off a parent theme so any updates to the theme wouldn't over-ride my changes.
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.
That's one problem with Wordpress' default renders; it sends developers down those relatively narrow paths of customizing existing output. It's easy if requirements are flexible enough to allow that, but not the right CMS for truly customized content architecture and presentation.
Customized presentation is possible by starting with a blank template. Most do not do that, so if they want to customize, they spend time modifying and working around the default views. This has an effect of constraining the look. The difficulty emulating controller-like behavior means that adding multiple pieces of content to a view takes extra work.
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.
add_shortcode is incredible. It's probably my favorite part of wordpress, and writing a plugin is so easy, just a single file zipped up or scp'd. Especially with custom post types or adding a new table.
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.
> 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.
There's a whole possible scale of responses and of encouraged workflow though.
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".
It's not the main problem, but it also could do better. A system encouraging drop in additions could have a way of validating them and blocking plugins which fail.
drupal is much better, IMO, and assuming you actually know how the framework is designed. Wordpress has the 'loop' you hook into and everything happens in it. Drupal has more of a pub/sub model with hooks which seemed much easier to build standalone plugins. At the end of the day I'd say the most important part is understanding how they are built and where you are supposed to spend your time as a dev to make your users happy.
Add feature to WP should be easier than Drupal. In WP, you only write pure PHP. (Lack of APIs for common elements) But in Drupal, mostly you have to interact with Drupal APIs.
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.