A few free safety and performance tips when dealing with wordpress:
- Whitelist IPs for access to your wp_admin and wp_login.
- If you have the skills to automate WordPress updates yourself, remove all write access (except for the uploads folder) from the user WordPress is running as (i.e. www-data). It's all just unzip and untar over the structure of the directory anyways.
- If you remove write access, you might as well block the "cron" as well.
- Limit the WordPress DB user to the usual crud operations; don't let it create or alter tables.
- If you feel like getting really into it, whitelist explicit URLs. Maintaining it isn't really too hard, and it reduces your attack surface significantly.
- Set up even a simple nginx cache in front of WordPress - even a 1-5 minute cache will let your site run on crappy hardware and handle HN or Reddit with a minimum of sweat.
is how I've mounted /tmp (and several others) for going on two decades. I've never been a fan of installers creating a single partition by default and I wish they didn't do it.
Years ago, like you, I saw an out-of-date web app get hit by an exploit but was "saved" because of some of those mount options.
I'm a big fan of SELinux on public-facing servers too (especially web servers, for the same reason), but that's an argument for another day.
I'd also recommend looking into Bedrock, as it neatly sets you up for updating via Composer, which is quite nice once you get used to it. Good thing to fire off on a post-deploy hook. Then you can completely disable any internal updates and completely control the version of core and plugins.
The folder structure also adds some minor security through obscurity.
Another safety tip: don't install any plugins unless you're very, very sure that they're safe. Most security problems with WordPress originate in badly written plugins, not in the core product.
If you're not going to install plugins, doesn't it neuter one of the big draws to using WordPress in the first place? Ideally there would be better separation between the plugin and core stuff, but oh well.
As for the cache Cloudflare's free tier as allowed me to handle pretty large traffic loads in the past, much more then my $5 droplet should be able to handle. This was for a blog platform I wrote in Flask though(and optimized for cloud flare) so it might not be comparable.
My only concern there is that `wp-supercache` is a plugin, so you're still having to spin up php and work through the WordPress core just to get to the point where you can serve the files out of that cache.
It's likely better than no cache, but an external cache will be much more efficient under load.
Mostly that it's a wordpress plugin that a non-administrator can install. Like on a cheap shared hosting setup, where they have no way to alter the apache setup.
The fundamental lesson WordPress taught me is that the product wins over technology. Even back in 2004 it was clear that the internal code wasn't that great. So what? It installed delightfully quickly, and let me create posts with valid markup and good typography right out the box.
And then the community management and plugin/theme ecosystem. For example, Drupal may have a more programmer-approved API, but (at least when I worked with it back in 2011) it was a hundred times more complex to make a custom content-editing form in Drupal than in WordPress. Again, product over technology.
I was always a little bit weirded out by features for ease-of-use that required you to go against what the documentation described as security best practices.
I agree, though I think the most important distinction was that WordPress had an audience and core ideas in mind, whereas the likes of Drupal tried to be a generic 'everything to everyone' solution. The former was designed to be easy to use for average Joes, the latter seems like it was designed to be fun for developers while being rather awkward for normal users.
"product over technology". Yep. That is what keeps it going. I have been doing a bit of wordpress lately and it just works for users. Sure, developers love to hate it and reasonably so to an extent but try telling that to the folks who are making millions with wordpress (woothemes as an example). There is a reason for that.
Agreed. Drupal has been working on the product end of things since then, for this exact reason. Drupal 8 is a big improvement on that score and is worth looking at again if you've choked on it in the past.
"Haters are going to hate." -- by using that phrase you make it sound like people are criticizing WordPress without cause.
I haven't looked into it recently, but as I remember it, in the last 13 years there have been abundant legitimate reasons to criticize WordPress (many in the categories you listed). Yes, some people will hate on something just because they don't like it (regardless of any merit it may have). But I wouldn't lump in all of the people with legit criticisms of WordPress into the same group as "haters".
I remember my first install. It was glorious, started posting like a madman. At some time - when gaming Google was the thing, say 2008 - had thousands of sites based on WP.
Then I had my first major vuln and spend my week-end fighting fires. Then I had my first encounter with encoding mess ups... an add-on going wild...
I remember thinking back then, and sometimes now I still do, that I would gladly pay a fee for a togglable feature that let me exclude all wordpress sites in my search results
13 years ago Movable Type and Blogger owned the space. MT was for folks who wanted to install software on their own server, Blogger for those who wanted a hosted option.
Blogger was bought by Google a few months before WP appeared.
I <3 Movable Type. Used it for several years and got really sad when it started declining. Only started using Wordpress late in the game and never got to understand their template system. MT and Blogger was less complicated.
oh, wordpress, the burner, breaker of balls, mother of confusion, queen of the seven installs, protector of the bots. blood of my blood, i bow to you and swear my allegiance until the internet shall break.
I only recently tinkered with wordpress/buddypress plugins for a hobby site. I can see why it became so popular. It's dead easy to start tinkering because it forces you to learn very little. Just find the place where you want to hook your code, and dump tons of godawful code in there. That means that people use 1000 different styles in their plugins, but its the big price to pay. In comparison, try tinkering with oxwall without digging deep into their object-oriented code.
To me, what's great about WordPress is how they've fostered and managed their community and maintained backwards compatibility to an impressive extent. The code itself on the other hand... oy vey.
Wordpress is, imo, the reason PHP has historically gotten a bad rap. Needle/haystack/type/performance PHP jibes aside etc etc, WP has been the single point of contact for situations where my company has had to remediate a hack/data breach/script kiddie scrawl. I've seen full hosted servers being unplugged with no comebacks, tens of thousands of dollars in rebuild costs, lost clients due to security concerns.. the culprit? pointing over there
The easy retort is "just keep it patched and up to date", natch. The ongoing costs/technical debt involved in maintaining a Wordpress install sometimes ends up being greater than what it cost to roll the thing out.
I think it's more likely that the low barrier to entry required to build a WP site is what has caused these issues, well, in the past, anyway.
What you are describing could be attributed to any poor quality code, it's not specifically WP core that is to blame, but rather poor quality code built on top of it.
In regards to managing WP sites being costly and taking up time, I manage many WP client sites and find the opposite to be true (I did write the code for all of them, though)
Wordpress's success has to be down to it's ecosystem. There are other CMSs that are better targeted to more specific uses, but the amount of options and choices to a web designer with Wordpress are unreal.
The problem I have with wordpress - and any php project for that matter - is that I'm afraid of the code. I've done some template editing for WP and it already scarred me enough.
But maybe I just prefer writing and working in my own familiar codebases instead of spending a small amount of time in that of others, a curse that a lot of PHP developers have (the "I'll write my own framework / cms" curse)
Consider though that when its template system was "invented" there wasn't much else available and people back then used to mix code and html all the time (both PHP and ASP developers). In their attempt to keep it backwards compatible we still have to suffer through the template system.
At this point I don't think Wordpress is going to change their codebase into something more modern and secure. Is there any other easy to use blogging platform like it? PHP based because PHP is everywhere, based on a modern framework (symfony2, laravel, etc), jinja-like template system, support for databases other than mysql?
WordPress itself is not as insecure as people make it to be. Its code base gets a lot of scrutiny and security issues are fixed promptly. The problem begins when you start installing plugins... which most of them are coded by designers-turned-programmers who needed to add a new function to a client#s WordPress site. Reading their code its obvious that they are build by mix and matching tutorial and example code they googled.
I haven't dug into any of this stuff, but wouldn't a smartly designed plugin system give plugin code fewer permissions to prevent precisely this sort of issue?
- Whitelist IPs for access to your wp_admin and wp_login.
- If you have the skills to automate WordPress updates yourself, remove all write access (except for the uploads folder) from the user WordPress is running as (i.e. www-data). It's all just unzip and untar over the structure of the directory anyways.
- If you remove write access, you might as well block the "cron" as well.
- Limit the WordPress DB user to the usual crud operations; don't let it create or alter tables.
- If you feel like getting really into it, whitelist explicit URLs. Maintaining it isn't really too hard, and it reduces your attack surface significantly.
- Set up even a simple nginx cache in front of WordPress - even a 1-5 minute cache will let your site run on crappy hardware and handle HN or Reddit with a minimum of sweat.