Nobody but other devs cares about the simplicity of the code if the code works.
>The code and hosting requirements are, frankly, Frankenstein's monster levels of frightening.
Huh? Wordpress/PHP hosting requirements are the easiest to meet in the industry. Not to mention the most widely available...
>~~You have to~~ WP expect you to install it such that it can modify its install folders - all of them. Security-fucking-nightmare.
Yeah, so? It's self-updatable. Use a dedicated user/group.
>It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP.
Absolutely not "because of PHP". If anything PHP is faster than both Ruby and Python, two other common choices.
>You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.*
That's the case with most CMS, PHP or not.
>Arbitrary plugin installation, in a non-sandboxed environment (see prior point about an application-writable install).
It only happens if you chose to do it. Plugins don't magically install by themselves.
So it's not much different than any environment where you can download a jar, a python package, a ruby gem, etc and have them add functionality into the CMS.
>Need more be said?
More, no. Better, yes.
They care when you start quoting a week for a simple addition that should take an hour, because every time you have to wade into a mess, in which one wrong semicolon in functions.php brings down the entire website.
Of course you test and you test, but you're surrounded by landmines at all times.
Exactly, this is the key point. If it’s a website that literally will never change then fine (edit: what I mean here is if you are confident WP can meet your needs without resorting to hacks, and can meet your future needs - in my experience, it’s when more functionality gets added on by random developers that things get messy, true of development in general though!).
I guess using headless WP might help? The clients I’ve worked with who’ve had WP sites in the past have made a point of saying they definitely don’t want WP again (due to security nightmares, usability etc) so honestly haven’t investigated it too deeply recently.
Don’t immediately deploy code into prod until you’ve tested it?
The professional approach is a local copy for development, a staging copy on hosting for QA, and then production. Code goes up in deployments; DB and files come down in regular synchronization. If there are multiple devs you might also have an integration copy on hosting.
This is not specific to WP; I’ve seen the same workflow work for other DB-backed CMSs like Drupal.
Still doesn't help that most WP sites I've ever seen inevitably were those huge card castles just waiting to crumble at the next plugin update. Cause of course, the remarketing plugin the client needs/wants installed just introduced some weird edge-case bug when used in combination with the latest version of the forms plugin you use. Or they ask (demand) administrative privileges "cause they're paying" and proceed to start messing with the configuration themselves and destroy everything. All the local development copies in the world won't make it less temperamental and brittle.
Its success - IMHO - doesn't have much to do with its technological merits but familiarity. Most "content" people know how to use WP, so companies like to have WP for their content management.
Or maybe I'm just bitter of my time working in the kind of environments that tend to focus on WP. Although last news I got were they were starting to use it more as headless CMSes.
Honestly though, there's a lot of talk about changes here without much talk of the most obvious class of changes that Wordpress is designed to support: adding content to your website or blog.
For all its faults it does make that very easy, and it's designed with the intent that you will do so by working directly on the live site (you can obviously preview and review content before making it live).
Changing layout and templates is trickier, likewise creating a new page layout, and that's where a staging or development site comes in handy.
The main one, where people update content.
Then there's a backup that gets auto restored every morning (with appropiate sed etc to change URLS), which is suitable for developing and testing any code changes
The third is one which is manually restored from the backup, and suitable for longer term experiments, how best to organise pages, etc.
Even can do a CI/CD system.
As someone who works professionally at a hosting company, no one does this. The history of Wordpress security has followed window XP with users who downloads random files from the internet and click cancel every time something want to update. Every hosting company that I know has to implement firewall rules to address WordPress security, just like the old days of windows.
The default configuration is also not fine. At minimum you need to disable rpc calls to the login, as the password attacks trigger a lot work that eats resources and processes. RPC is on per default in order to make the WordPress mobile app work.
Wordpress made sense when the web was a collection of independent servers. However in today’s cloud-orientated hosting landscape there are a thousand better ways to provide said content. Both at the beginner level and at the enterprise.
I’m no fan of PHP or Wordpress by any stretch. But I agree with the pragmatic choice in this case. It will probably only need one dev to maintain the site. But even that would be overkill. You just never want a bus factor of 1. Especially for such a high profile site. But I’m digressing...
But cloud vs VPS aside, I do wonder is they are self hosting due to security reasons. Imagine a bad actor hacking into the WP installation! It does have a bad security record.
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.
All that means is that you’ve misconfigured your IDS. You’re supposed to filter out stuff that’s not a threat, not remove the entire IDS instance entirely!
You shouldn’t throw the baby out with the bath water https://en.m.wikipedia.org/wiki/Don't_throw_the_baby_out_wit...
Again you’re over estimating the average IT team’s ability to keep on top of WP patches. And again I have to reiterate my point about the advantages of a good WAF (web application firewall).
I’m not making a theoretical argument here. I’ve seen and have had to fix numerous sites from companies with competent developers and sys admins but who were simply unlucky enough not to notice that one RCE vulnerability in time.
> I’m sure you saw a lot of CMS installations that got hacked. I’m also sure that most them were because of either poor patch discipline, or misconfiguration, or both.
Neither actually. Just busy teams in medium sized business having a plethora of projects and too little time to manage everything with the same degree of love that your larger companies or start ups do when they have a dedicated team working in a single product.
Remember the appeal of WP for many is that it is “plug and play” so it often gets installed in organisations as a way of reducing the burden on existing developers and/or sysadmins. A strategy that makes complete sense on paper but can back fire spectacularly.
Let’s also remember that WP also appeals to the hobbyists too. You can’t accuse them of being incompetent sysadmins because they never set out to be technical. Instead they were sold on how easy WP is to install and manage.
Again this is why I keep discussing WAFs. Using them is non-obvious but it does reduce the burden on whatever individual or team manage WP.
> But even then a popular CMS may have an advantage: it’s a lot easier to find professional help for a popular CMS than for a niche or custom one.
Oh i agree. Choosing an established CMS isn’t a bad decision as there are plenty of benefits in doing so.
> Honestly, running any software at all is going be a nightmare for a lot of people. Hence the success of products like Squarespace and Wix; now they don’t have to.
This I agree with too.
I’ve seen WP used for everything from personal blogs, international news sites, shopping sites, and even fantasy sports games. The diversity of WP is definitely a strength. But it does mean that there’s not going to be a 1 size fits all alternative.
There's no "NFS requirement for multiple Wordpress hosts" tho.
Unless you have a very dynamic site (posts hourly, multi-daily), would making it static-y be a solution?
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.
You wanna run 2 blogs on Ghost - run 2 instances, same for _everything but Wordpress_.
Just a shame there’s no liability for negligently causing users to get infected.
> You have to let it modify its install. Security-fucking-nightmare.
You don't have to do this, you can set up sane permissions and use the wp cli[0] tool to install updates manually. I prefer to version sites with git and install updates locally, then git pull down on to the live server.
> It will use incoming requests to trigger "cron" jobs (which can include self-upgrades), via a non-loopback HTTP request.
A good practice is to set up your own cron job[1] on the server and disable the internal cron in your wp-config.php, like this:
define('DISABLE_WP_CRON', true);
> It falls apart under any kind of load, both because of unoptimized DB queries, and because of PHP. You have to put a cache in front of it to be able to handle getting on HN, let alone Reddit.
Just install a page caching plugin of your choice[2]
> You really have to dedicate an admin to it if you want to keep it secure and performant. I still get angry remembering my experience installing, securing, and setting up caching in front of it.
Or use a managed WordPress hosting service like Kinsta[3] if you don't want the hassle. They'll handle all this sysadmin faff for you...
[1] https://www.siteground.co.uk/tutorials/wordpress/real-cron-j...
I’m working on my first WP project and am trying this approach. A question I have is how do you handle plugins that have hooks that only run once when installed? Those hooks don’t run if you pull in via git. Also if they make changes to the dB (migrations), how is that managed if the plug-in was installed on a different server?
You can check out WP CLI to automate some of this as well.
Yup this is exactly how I do that.
I also have a cron that checks "git status" and emails me if anything changes.
Curious as to how you manage WP with git, particularly around when new files are added by core/plugin updates, which I've always found a bit of a hassle to deal with?
It can be a hassle on shared hosts, but most managed hosts have a git workflow that their agency partners utilize so it’s not too bad if you’re doing anything on a professional level.
I just haven't found a good workflow I guess. I'm gradually trying to strip all the plugins which are not required (there are so many) so I can just focus on the core ones that are hard requirements but even one or two decent -sized plugins is a huge responsibility to manage if you're trying to pretend you're tracking all the changes to any level of detail.
The short answer is yes, you're right - losing being able to write to disk means a lot of functionality is lost. But it does improve security in some contexts so the trade-off might be worth it to some people.
I wrote a small plugin that lets me flick between read-only and read/write filesystem permissions with the press of a button - so when I need to administer it, I just allow writing, and the rest of the time I leave it locked off.
Doesn't work in all circumstances (e.g., if there are plugins that need to write to the disk), but for sites which predominantly have static content it means I don't need to worry as much about things writing to disk in the event something is compromised.
Normally you want all code changes to happen locally, and get tested locally, before they ever make it to production. Which means your client will need to get you to install the plugin.
It depends on the project and client though. There are levels of engagement that are a lighter touch, and in those cases you just accept the mess and risk associated with users managing plugins.
My thinking was a wordpress-specific provider might be cheaper so I went out looking for one with disappointing results. `
I updated my original comment here.
> A good practice is to set up your own cron job on the server and disable the internal cron in your wp-config.php
Defaults matter. And when I was working on it, this wasn't well documented anywhere. If it is now, great. It shouldn't be the default.
> Just install a page caching plugin of your choice[1]
A bad idea, IMO. It's still going through the PHP server and all of the routing/plugin/DB code within WP. Much better to use Varnish (and its ilk) and avoid overloading the PHP service.
> Or use a managed WordPress hosting service
Back when I worked for an remote DBA company, we were tapped many times to help optimize DB access by Wordpress. It reminded me that it's remarkably easy to start a WP hosting company, and remarkably hard to do it right.
This is incorrect. WP supercache generates static html that takes precedence over falling back to the php engine. This is the way it worked nearly a decade ago too.
I wish people wouldn’t spend so much effort bad-mouthing technology they don’t even understand. I don’t even like Wordpress but reading this is super annoying.
I'm not a big WP fan, but this statement is false in most cases. Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk (or CDN) without hitting PHP. Pagely (the post we're discussing) even handle that for you w/ their own CDN. I would imagine they also support request based caching and purging, warming, etc.
Most purely content sites (non-app) can run really well with a very simple TTL based cache (instead of long lived w/ complex flushing). You can very easily use something like Fastly for cloud based varnish w/ an appropriate TTL.
I also feel the need to point out that gatsby type sites and just pre-rendering / caching as well, at least in part (possible using json from a CMS for dynamic data).
I'd be very curious how a WP plugin is managing this.
Third party hosting building in caching, normal in-line caches (like Varnish), nginx/apache caching, sure - I get those, and they behave how you say. But a WP plugin? I'm curious how that would bypass PHP & WP entirely.
On the other hand, this trick was mostly useful years ago when shared hosting plans were really underpowered.
As of today, with improvements of both PHP 7.x and general server performance, even a cache system that uses PHP very early (before any DB connection) to load a pre-rendered html cache file goes a long way in terms of number of pages being served.
Actually, if this become your bottleneck, the .htaccess trick won't help a lot, and you would still look in tools like memcached, redis or reverse proxies to improve things.
I think a lot of third-party hosts provide this out of the box, maybe even using their own CDN. WP is so popular that it's be difficult not to find a service that handled it all for you so long as you have room in the budget.
If you don't know how the cache plugins do this, it's pretty obvious you are not very knowledgable about WordPress site operations. Please stop spouting falsehoods here.
You don't have to know what cron is to install a WordPress site. You don't have to know anything about git or setting up varnish. You just bung the files on your PHP server, put in your database credentials and away you go.
There is a big conflict here between what is practical for users and what is best practice for developers. WordPress has always put user experience first, to the point where it's easy to shoot yourself in the foot and get your site hacked by installing a bunch of badly made plugins. But this tradeoff in the favour of user experience had made it easy for millions of people to set up their own website, and is the reason WordPress is the most popular CMS in the world
Indeed. And so many commentators here on HN (myself included) bemoan FAANG centralization and wish for decentralization and federation and the like... well, this tradeoff is relevant in that matter.
What about the conflict between what is practical for users and what is best practice for users?
Security isn't just a developer's concern. Having to clean up a hacked WordPress site because of crappy defaults isn't very practical for users, either.
WP is absolutely NOT secure by design; it's a hot mess that has helped normalize ignoring security in our web applications. That we encourage its use, that we haven't replaced it with something better, is a damned travesty.
The fact that WordPress.com doens't get hacked all the time means that there are definitely people who know how to do it.
Regular reminder that wordpress.com is a different software product to wordpress.org :)
wordpress.com runs their (relatively) newer JavaScript-based stack; wordpress.org (which is what we're talking about here, unless I misread the article referenced here completely) is the LAMP stack version.
It's written in JavaScript; it runs on node.js - at least the front-end part of it (https://github.com/Automattic/wp-calypso). I don't know what is running on the backend but I don't think it's LAMP?
The point I was making though is that "WordPress" can mean two different things - wordpress.org (the self-hosted LAMP version) or wordpress.com, which is a SaaS offering (so the language is more or less irrelevant unless you're really interested in running your own admin frontend, I guess).
Calypso is our JS dashboard that lets you manage all your sites in one place, plus get cool WP.com features like stats and notifications. It's just a REST API client, just like the iOS and Android apps.
> WP expect you to install it such that it can modify its install folder
Only if you want to have your users install plugins and modify the software with the web control panel. That may be the whole reason why you chose Wordpress, of course. Otherwise it runs well in a read only environment, apart from the attachments folder, and it is also documented.
> It will use incoming requests to trigger "cron" jobs
This is optional, for people who ran it on shared web hosts and didn't have access to crontab. It's all documented in the install instructions.
> It falls apart under any kind of load,
Well, yes. That's unfortunately true for all popular CMS software. It's a similar situation as with Gtk and Qt which are all flaming garbage under the hood. As an X11 user I accept that but I don't have to like it.
It's not noticeable for end users because as you realized in is intended to run with caching. That's the one big thing that should be better documented in the installation instructions. I had to evaluate half a dozen caching schemes just to choose one that seems to work well and is popular enough. There really should be one straightforward way to do it.
If you run multiple webservers, upgrading is extra fun, because when you upgrade, it assumes it can update the mysql schema (which is pretty much totally insane; a www-user writable php script shouldn't be able to create/remove/alter tables). The best way I found was to make a copy of the database, install the new version of Wordpress pointing at the new DB, thoroughly test, and then deploy new version pointing to new DB; then kill the old DB.
And woe is you if your webservers are geographically distant, because there's no way to send reads to a nearby DB mirror; and there's no way to run in read-only, because pingbacks still write to the DB even when they're disabled.
One of the best weeks of my last job was when I was able to finally convince my boss to replace Wordpress for our static company blog with a series of Makefiles and simple PHP to smoosh in all the translations.
You really don't. I've deployed it to Heroku, where the filesystem resets every 24h. It's a part of their famed five minute install for not-very-technical users on shared hosting, but it's by no means a requirement.
We disabled it (except for the attachments folders), and boy did it throw up all over the logs.
Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.
I'm fairly certain for the White House's sort of use case this is not an issue.
> Using a filesystem reset is a nice way around WP's requirements. I'd personally hesitate to rely on it for a popular site, since it still leaves a site vulnerable to code injection for those 24 hours.
We did not permit it to have write access to its own filesystem, at all. It worked fine. Uploads went straight to S3 via a plugin.
One can only hope.
> We did not permit it to have write access to its own filesystem, at all. It worked fine.
Cool beans - you installed it sanely. But contrary to how WP expects to be installed. I've corrected the original statement.
No, this is incorrect. WP is compatible with no write access and recognizes it in the default setup workflow.
Don’t blame PHP. We use it to handle millions of concurrent users and it does it without breaking a sweat. It scales horizontally better than basically anything, Modern versions of PHP are remarkably fast, up to 3x faster than Python in recent benchmarks.
The real problem is Wordpress, it’s written like 20 years ago PHP to avoid breaking any plugins. The API is largely writing to global variables.
On top of that, the quality of the given plugins is usually dubious at best, and a lot of people just slather more and more of them on, and they often interfere with each other.
Have you tried doing the same with other technologies?
> It scales horizontally better than basically anything
How does it horizontally scale better than projects written in Golang/C#/Ruby/Python/whatever?
> up to 3x faster than Python in recent benchmarks.
Computational speed rarely matters. If it does, you would usually fallback to C/C++/Rust library doing the heavy lifting, when using 'slow' languages, or just move the workload to async processes.
Web applications spend most of the time doing I/O operations, where async programming makes a lot of sense. Async with PHP is still in its infancy, compared to Python, which has native support for it.
Or, you can keep folders locked down until it’s time to update, then unlock and let it update itself, then re-lock the permissions. This can be done manually or with a job scheduler.
WP needs a caching strategy for performance but so do static blog generators. The static copy is the cache, and rebuilding it is the cache purge.
Edit to add: Wordpress is so popular there are dedicated hosting companies, which makes all this stuff super easy. I managed WP myself for years; now I just have an account at WP Engine and they handle all this stuff for me.
It is amazing how tech people are so far off from understanding real, everyday non-tech people and their needs.
My $5/mo VPS running WordPress can handle about 50rps for an article page...
Here are the numbers from when I was testing how much comment threads impacts load time:
IMHO, this isn't that fair of a characterization of WordPress in the first place, considering that the alternatives that the GP mentioned don't come close to doing half of what WordPress can do. I could similarly sing praises about how static site generators are so much easier to maintain as a developer than next.js + whatever you cobbled up to handle data persistence, CMS auth, admin UI, SEO, domain specific logic (drafting, theming, social media integration, etc), but again, it's very much an apples vs oranges comparison.
WordPress has become so ubiquitous in web publishing that often it is a client requirement when asking for a new website to a web agency.
Using WordPress is a skill that people put in their CVs, in the same lines where they talk about their MS Office proficiency.
- a custom docker image suitable for use in docker/kubernetes environment. Vanilla wodpress docker image is not suitable for most of our needs, so we build our own images which includes everything we need an nothing more.
- security issues are rare if you follow basic security practice: strong password for administrative users, not installing plugin/themes from sketchy sources (pirated plugins/themes), and keep the number of installed plugins minimal.
- Sometimes a site was hacked by automated bots exploiting zero days in some popular plugins, but we have a clamav instance scanning the wordpress fleet's nfs volume regularly that flags them in timely manner. Containerization is a huge win here because it allows us to quickly redeploy the site with fresh install and prevent the bots from jumping between hosts (none of the bots we're dealing with are sophisticated enough to escape the container).
- Content was a major headache. Each site can use different themes with varying level of quality. We solved this by using Beaver Builder for all new sites with a custom, super minimal theme. This allow our content people to build the site layout visually while minimizing code bloats. This setup is also very cache friendly, unlike some of the themes I encountered in the past.
- Caching is very easy as everything is containerized. Just add a new memcache/redis container into the pod, which is just a few lines of yml or a checkbox in our internal tool. Same with daily backup and granting sftp access to external parties.
- When a client outgrows wordpress, we'll transition them away into a custom solution.
But considering that the initial version of the Site Editor is already part of the official Gutenberg plugin (2) – and they usually include features from the current version of the plugin in the main app – it is expected to be released with version 5.7 of WordPress, next March.
I pretty much enjoy headless CMS, but at the moment in my opinion nothing beats the ease and use of Wordpress overall, devs and authors.
This is simply not true - modern PHP is very fast.
However that is not fault of the tool itself. There is nothing preventing a competent dev or small team to set up staging and qa environments, a ci pipeline if they are so inclined, write proper tests, be discriminating in the plugins they install and the quality of code they write. And the start threshold for the system is incredibly low, the fact that so much boilerplate functionality is _already there_ saves a lot on development costs and allows you to focus on functionality that really matters.
TL;DR if your wp installation is bad, it's not wordpress, it's you.
~~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.