Comment by coldtea | Hacker News Reader

Comment by coldtea | Hacker News Reader

Parent Full thread

>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.

>Need more be said?

More, no. Better, yes.

> 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.

> in which one wrong semicolon in functions.php brings down the entire website.

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

How do you test wordpress without deploying it? \s

We do it with a secondary copy of our website.

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.

Indeed, I have 3 copies of my wordpress site.

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.

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.

Have a dev site, which is easy with modern tools.

Even can do a CI/CD system.

Programs in any language can crash due to a single character syntax error.

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-).

What's funny is that this error would have been impossible to make within WP's built-in file editor. It lint checks before letting you save any edits.

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.

> 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.

This I agree with too.

> 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!

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

NFS for sharing uploads folder? shift the media to a CDN when it’s uploaded and serve it from there. There are multiple plugins that do this.

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.

What are a few of the better ways you would suggest at the moment? (Honest question from a WP dev?)

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.

>The NFS requirement for multiple Wordpress hosts are an instant deal breaker for me when discussing CMS on the cloud.

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

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.

I wouldn't suggest it personally, and don't think it's common.

> The NFS requirement for multiple Wordpress hosts are an instant deal breaker for me when discussing CMS on the cloud.

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

* https://wp2static.com

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

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.

There are plenty of ways of doing it without NFS.

CMS in general, yes. WP specifically, no.

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_.

Typo3 can do that too.

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.

Awesome example, thank you for sharing!

Textpattern does that easily enough. You can even run your admin stuff on a different domain if you so desire.

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.

Reply on news.ycombinator.com