In Defence of WordPress(ma.ttias.be)
ma.ttias.be
In Defence of WordPress
https://ma.ttias.be/in-defence-of-wordpress/
16 comments
Are there any examples of someone trying to refactor Wordpress on the Symfony HttpKernel or basically moving Wordpress Core to some type of more modern architecture?
Fear not, PHP when used appropriately can be fantastically useful. Pretty much every argument against it that I've read has centered around trying to do something it wasn't meant to do and not being very good at it. As a web scripting language, it works as advertised :-)
>PHP when used appropriately
'using php appropriately' involves keeping a large number of gotchas and weird behaviors in your head, when you are writing every single line of PHP.
'using php appropriately' involves keeping a large number of gotchas and weird behaviors in your head, when you are writing every single line of PHP.
I've heard that it's not very good at the "web app" paradigm vs. the "cgi script" paradigm that it was created in. Is that really true?
Not in 2015 it's not! Front-controller pattern (single index.php, in the same way you'd have a single Python process that Nginx talks to) that hands off to something like Silex or Symfony or Laravel, and you have a beautiful base for a proper web application API layer -- autoloaded classes, proper dependency injection, and more.
I never liked the pattern of routing every single request through index.php. I prefer to let Apache do the routing for me, having a separate script for each task.
I also had a PITA debugging someone else's code with autoload magic. He didn't follow any pattern for what code was in which directory, and he reused class names so grep didn't work. Now where is that source file again? (In one particular abomination, he took a string from the database and included that source file.)
That's one nice thing about PHP. You can use PHP for a simple straightforward style, or for an abomination like zend.
Vanilla wordpress is good. I'm working on a project that has a custom framework that lives on top of WordPress, and I'm cursing the people who wrote it and my employer for outsourcing the WordPress project to them.
I also had a PITA debugging someone else's code with autoload magic. He didn't follow any pattern for what code was in which directory, and he reused class names so grep didn't work. Now where is that source file again? (In one particular abomination, he took a string from the database and included that source file.)
That's one nice thing about PHP. You can use PHP for a simple straightforward style, or for an abomination like zend.
Vanilla wordpress is good. I'm working on a project that has a custom framework that lives on top of WordPress, and I'm cursing the people who wrote it and my employer for outsourcing the WordPress project to them.
> He didn't follow any pattern for what code was in which directory, and he reused class names so grep didn't work. Now where is that source file again?
http://www.php-fig.org/psr/psr-4/
http://www.php-fig.org/psr/psr-4/
Nope, he didn't follow that, he had a bunch of exceptions coded in his autoload function.
He also had a bunch of functions where a function in one class nothing but call another function in another class. He also had way too many classes.
He also had a bunch of functions where a function in one class nothing but call another function in another class. He also had way too many classes.
Right, but that's the problem.
You can quite easily make an abomination of a class hierarchy in Ruby, or Javascript, or even Python to some extent. If people don't follow best practices, then of course things will not work with other tools that expect your work to do so.
Also, I highly recommend XDebug with the Codebug[0] client -- if you're working with a crappy codebase and run into the issue of "what damned file is this?" it will solve that in a super nice way. It also gives you a full REPL in your working environment, pause execution and play around in the PHP side during your request :)
[0] http://codebugapp.com
You can quite easily make an abomination of a class hierarchy in Ruby, or Javascript, or even Python to some extent. If people don't follow best practices, then of course things will not work with other tools that expect your work to do so.
Also, I highly recommend XDebug with the Codebug[0] client -- if you're working with a crappy codebase and run into the issue of "what damned file is this?" it will solve that in a super nice way. It also gives you a full REPL in your working environment, pause execution and play around in the PHP side during your request :)
[0] http://codebugapp.com
I'll look into Codebug. I haven't found a PHP editor I really like yet. I've been using dev-PHP and emacs. I'm using Netbeans at work and don't like it.
Oh nevermind, Mac only, forget it.
Oh nevermind, Mac only, forget it.
well said. Personally I like the file based routing solution (Multiple scripts for individual tasks) where applicable, there are benefits to multi-function scripts but I like modularity. If i've already written a script to do X, why re-write it every time? Still All these points above and below are good.
The key benefit to the front-controller architecture is that you can keep your code outside of the webroot, such that you can avoid misconfigurations causing security issues, and allowing for user uploads without exec permissions on the files in the uploads directory.
The other reason I like it is it gives me much more control over routing, versus relying on folder and file structures :)
The other reason I like it is it gives me much more control over routing, versus relying on folder and file structures :)
I'm not really sure there is much of a difference between the two beyond routing (which the framework handles just like in all the other popular imperative scripting languages), in fact if anything I'd say PHP is more aligned with the "web app" paradigm since the canonical run-times are all intended to be paired up with an HTTP server, as opposed to most others which were designed as general purpose scripting languages. I don't think it makes much of a difference though.
giro,
I agree, but what are the alternatives? I'm coding my own, personally.
Knowing about WordPress and the typical use case, what do you use instead?
That's the problem. For some clients, there simply isn't a decent alternative.
That said, if I was forced to choose a "user friendly" CMS, I'd go with Drupal 8 (when it's released). The reasoning? It still has the client-facing tooling that non techy users expect, but is built on top of the Symfony core, following all relevant standards.
It's a little while away though, unfortunately. Depending on the site, my answer nowadays is a Silex API for the data they want to work on, and a React + Flux front-end. That's too much work for a $2k site however; WordPress is so entrenched that any replacement needs to be able to answer the plugins question successfully to overtake it.
That said, if I was forced to choose a "user friendly" CMS, I'd go with Drupal 8 (when it's released). The reasoning? It still has the client-facing tooling that non techy users expect, but is built on top of the Symfony core, following all relevant standards.
It's a little while away though, unfortunately. Depending on the site, my answer nowadays is a Silex API for the data they want to work on, and a React + Flux front-end. That's too much work for a $2k site however; WordPress is so entrenched that any replacement needs to be able to answer the plugins question successfully to overtake it.
I'm using the blazing fast http://gohugo.io/ Hugo static site generator (written in GoLang 8-) )
And that plugin can help you with the migration: https://github.com/SchumacherFM/wordpress-to-hugo-exporter
Hugo is more for nerds than the average WordPress blogger.
And that plugin can help you with the migration: https://github.com/SchumacherFM/wordpress-to-hugo-exporter
Hugo is more for nerds than the average WordPress blogger.
Ghost is coming along very nicely. From what I have followed from their development I have seen very thoughtful developers from the start.
edit to add https://github.com/TryGhost/Ghost
edit to add https://github.com/TryGhost/Ghost
Most people would be fine with a static site generator like Jekyll and a third-party commenting system like Facebook or Disqus. As a bonus, it costs pennies to host such a thing on S3.
I'm not necessarily here to defend WordPress, but, I agree, a compiled static site does make sense for the HN user's blog, but you're not typical. What about the neighborhood barbershop that needs a website and likes to self-publish blog articles a couple times a week? What's the best solution for them?
> What's the best solution for them?
I'd love to see a user-friendly GUI backed by Jekyll.
I'd love to see a user-friendly GUI backed by Jekyll.
> Most people
We in technology are not "most people".
We in technology are not "most people".
Anyone who can manage a WordPress install should be able to get Jekyll working, but I'd like to see it get a user-friendly GUI that takes care of the grunt work.
Honest question: for the rest of us who can't write our own blogging platforms but are able to roll out our own hosting for a blog, which one would you recommend?
Not OP, but http://jekyllrb.com/ and ghost are both great.
I've been aware of Jekyll, but I never gave it any serious consideration. Maybe I should go ahead and do that now.
Thanks!
Thanks!
WP Engine (http://WPEngine.com) laregly solves any of these lingering concerns, or makes them irrelevant. It is also relied on by many, many Fortune 500's through to YC Startups. (Disclosure, I'm a confounder but not actively involved in the company these days)
Very familiar with WP Engine! However, my question was more around what other platforms can I set up on the hosted space I already have, rather than paying for someone else to host my WordPress blog.
Thanks though!
Thanks though!
I was wary of the Wordpress auto update changes starting with I think 3.8.
Right out of the gate they updated the $post object in a way that broke existing installations.
That was what got me off wpengine and off wordpress entirely. I was tired of the updates breaking existing functionality in a way that made me have to think about it.
Right out of the gate they updated the $post object in a way that broke existing installations.
That was what got me off wpengine and off wordpress entirely. I was tired of the updates breaking existing functionality in a way that made me have to think about it.
> modern PHP is a fine language.
I am sorry, but bolting on a ton of 'modern' features on a broken language does not make it not-broken. If it does anything, it is to put up an appearance of being modern, while remaining rotten on the inside, and hence all the more dangerous.
Remember, the most broken aspect of the language is also reason for it's very defining feature (No or very little learning required to get started). Hence one cannot hope that PHP will be fixed at some point in the future. Because fixing the language thus will actually involve killing it and designing it from the ground up, at which point you can just use Python 3.
And that is even considering that the PHP community is competent enough to identify the flaws of the language. But I think what happens inevitably is that, people who can really see how broken the language also see the hopelessness of the situation and immediately switch to something else or use it only to pay their bills.
If you think I am not familer with modern PHP, here is a tool I wrote some time back in php, for php programmers to deal with the pain of working with namespaces and also provide intelligent auto completion for editors like vim..
https://bitbucket.org/sras/cliche
I am sorry, but bolting on a ton of 'modern' features on a broken language does not make it not-broken. If it does anything, it is to put up an appearance of being modern, while remaining rotten on the inside, and hence all the more dangerous.
Remember, the most broken aspect of the language is also reason for it's very defining feature (No or very little learning required to get started). Hence one cannot hope that PHP will be fixed at some point in the future. Because fixing the language thus will actually involve killing it and designing it from the ground up, at which point you can just use Python 3.
And that is even considering that the PHP community is competent enough to identify the flaws of the language. But I think what happens inevitably is that, people who can really see how broken the language also see the hopelessness of the situation and immediately switch to something else or use it only to pay their bills.
If you think I am not familer with modern PHP, here is a tool I wrote some time back in php, for php programmers to deal with the pain of working with namespaces and also provide intelligent auto completion for editors like vim..
https://bitbucket.org/sras/cliche
> If it does anything, it is to put up an appearance of being modern, while remaining rotten on the inside, and hence all the more dangerous.
But what's rotten that you have to use in the day-to-day? PHP still has it's quirks, sure, but when I write modern PHP nearly all of those melt away. Also, well done Cliche, that's pretty neat; there are some other implementations of this idea nowadays that do similar things and are very useful.[0]
One of the reasons I love HHVM is that Hack is basically PHP-the-good-parts-with-other-awesome-good-parts-added. Static analysis? No problem. Autocomplete? Built into the default tooling! Having to remember dirty array method parameter ordering? No need -- use Collections and use methods on the primitives!
[0] https://github.com/nikic/PHP-Parser
But what's rotten that you have to use in the day-to-day? PHP still has it's quirks, sure, but when I write modern PHP nearly all of those melt away. Also, well done Cliche, that's pretty neat; there are some other implementations of this idea nowadays that do similar things and are very useful.[0]
One of the reasons I love HHVM is that Hack is basically PHP-the-good-parts-with-other-awesome-good-parts-added. Static analysis? No problem. Autocomplete? Built into the default tooling! Having to remember dirty array method parameter ordering? No need -- use Collections and use methods on the primitives!
[0] https://github.com/nikic/PHP-Parser
I'm with you. Though I'm a .Net developer by trade I spent years in the PHP trenches. C# and .Net provide better solutions in my opinion for the enterprise. But for shops with low funds and projects that needed to be done yesterday, PHP really shines.
It's not the language as much as it is the programmer. I've seen some very secure, well written programs in PHP.
It's not the language as much as it is the programmer. I've seen some very secure, well written programs in PHP.
A lot of people here are talking right past each other.
Is it good that WordPress has automatic security updates? Yes.
Is it bad that WordPress vulnerabilities are still so common? Yes.
Are Drupal, Joomla, or Magento better at this? It sounds like the answer is probably no.
Does that excuse WordPress because it is better than other frameworks with marginal track records? No.
For such a widely used framework, WordPress' security record is dismal. Automatic updates are a great feature, but they don't replace the need for the framework to be a lot more secure.
For someone hosting their personal blog on a $5/month VPS this is probably good enough. For a bank to run WordPress is borderline professional negligence at this point [1]. A lot of the comments seem to be assuming that because the update was rolled out withing a few hours, that their window of exposure was pretty small. The window of exposure to WordPress vulnerabilities isn't from the time the patch is released until you are updated, it is from when an attacker discovers the vulnerability and you are updated.
[1]: http://ma.tt/2015/04/a-bank-website-on-wordpress/.
Is it good that WordPress has automatic security updates? Yes.
Is it bad that WordPress vulnerabilities are still so common? Yes.
Are Drupal, Joomla, or Magento better at this? It sounds like the answer is probably no.
Does that excuse WordPress because it is better than other frameworks with marginal track records? No.
For such a widely used framework, WordPress' security record is dismal. Automatic updates are a great feature, but they don't replace the need for the framework to be a lot more secure.
For someone hosting their personal blog on a $5/month VPS this is probably good enough. For a bank to run WordPress is borderline professional negligence at this point [1]. A lot of the comments seem to be assuming that because the update was rolled out withing a few hours, that their window of exposure was pretty small. The window of exposure to WordPress vulnerabilities isn't from the time the patch is released until you are updated, it is from when an attacker discovers the vulnerability and you are updated.
[1]: http://ma.tt/2015/04/a-bank-website-on-wordpress/.
Someone should do a study on where these security bugs are coming from. Are they in new features? Introduced from refactors of old code? Are they due to the plugin infrastructure? Is it all in old code?
The bugs are coming from everywhere.
In my view, the worst ones are the ones coming from core. They've come from old code (i.e. the comments XSS due to overly large comments) or from including other libraries (i.e. genericons vulnerability).
I think this sort of stuff is bound to happen since WordPress is slowly becoming the kitchen sink trying to keep up with all demands of the users.
The good part is:
* They are increasing their unit tests coverage.
* With auto-updates, the huge amount of sites that use WordPress are not left in the dark. So I consider it a feature even if it comes at a price. When the software is being used at the scale that WordPress is, it is a needed feature.
In my view, the worst ones are the ones coming from core. They've come from old code (i.e. the comments XSS due to overly large comments) or from including other libraries (i.e. genericons vulnerability).
I think this sort of stuff is bound to happen since WordPress is slowly becoming the kitchen sink trying to keep up with all demands of the users.
The good part is:
* They are increasing their unit tests coverage.
* With auto-updates, the huge amount of sites that use WordPress are not left in the dark. So I consider it a feature even if it comes at a price. When the software is being used at the scale that WordPress is, it is a needed feature.
they should, for sure. from what I've seen over the past few years it is really all of the above although plugins are notoriously horrible.
So, your website can auto update itself. Know what that infers? A compromised WordPress instance can also update itself, to be whatever the attacker wants it to be. Hey, look, DB credentials as well, in an executable file (which can be "updated" right alongside the rest of Wordpress).
And how do these updates happen? Via a cron system, built into WordPress. It also has its own storage system (whose functionality can be altered at runtime by plugins), dynamic content management (via PHP (!) stored in the DB), its own networking stack, and more abstractions than you could shake a branch at.
Hell, I can't even figure out how to turn off cron requests (despite explicitly setting DISABLE_WP_CRON in wp_config.php). I block those at the nginx layer, but the noise is aggravating.
So many vectors of attack, so few ways to protect yourself.
And how do these updates happen? Via a cron system, built into WordPress. It also has its own storage system (whose functionality can be altered at runtime by plugins), dynamic content management (via PHP (!) stored in the DB), its own networking stack, and more abstractions than you could shake a branch at.
Hell, I can't even figure out how to turn off cron requests (despite explicitly setting DISABLE_WP_CRON in wp_config.php). I block those at the nginx layer, but the noise is aggravating.
So many vectors of attack, so few ways to protect yourself.
> A compromised WordPress instance can also update itself, to be whatever the attacker wants it to be
By this point, you're already on the other side of the airtight hatchway.
http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...
is a good example of this point.
The goal here is to avoid the compromise in the first place, so the attacker stays on the correct side of the hatchway.
There are plenty of logical reasons to hate wordpress, but I don't see that this is one of them.
By this point, you're already on the other side of the airtight hatchway.
http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/59235...
is a good example of this point.
The goal here is to avoid the compromise in the first place, so the attacker stays on the correct side of the hatchway.
There are plenty of logical reasons to hate wordpress, but I don't see that this is one of them.
> By this point, you're already on the other side of the airtight hatchway
Not really. Having the ability for a web process to write its to files which it then executes actually opens up whole new vulnerabilities. For example: one popular PHP exploit is writing a PHP file, then executing it on the remote system. Can't write a file? Can't execute the exploit.
Reading and executing PHP out of the DB, and also writing user input to that same database? Same problem. Triggering system-altering actions based on an unsigned token? That's a vulnerability.
Letting an application be able to do more on a system than is absolutely necessary to operate is a great way to give control and information over to others.
Not really. Having the ability for a web process to write its to files which it then executes actually opens up whole new vulnerabilities. For example: one popular PHP exploit is writing a PHP file, then executing it on the remote system. Can't write a file? Can't execute the exploit.
Reading and executing PHP out of the DB, and also writing user input to that same database? Same problem. Triggering system-altering actions based on an unsigned token? That's a vulnerability.
Letting an application be able to do more on a system than is absolutely necessary to operate is a great way to give control and information over to others.
> Not really. Having the ability for a web process to write its to files which it then executes actually opens up whole new vulnerabilities. For example: one popular PHP exploit is writing a PHP file, then executing it on the remote system. Can't write a file? Can't execute the exploit.
You're definitely correct, but there can be two different contexts to execute PHP; with differing permissions. If I was to rebuild how WordPress does it's autoupdating, I'd get rid of the god-awful HTTP "cron" crap, and have a proper PHP CLI that can do the updating, that runs on the server and is never exposed outside of it, and then WordPress itself, with the core outside the webroot and the uploads folder with zero executable permissions.
Still not perfect, but it'd be a hell of a lot nicer than how it currently runs.
You're definitely correct, but there can be two different contexts to execute PHP; with differing permissions. If I was to rebuild how WordPress does it's autoupdating, I'd get rid of the god-awful HTTP "cron" crap, and have a proper PHP CLI that can do the updating, that runs on the server and is never exposed outside of it, and then WordPress itself, with the core outside the webroot and the uploads folder with zero executable permissions.
Still not perfect, but it'd be a hell of a lot nicer than how it currently runs.
Replacing the self-updating with an external updater does eliminate the problems with self-updating, but it's not a viable option for wordpress's primary deployment target of terrible shared hosting.
The problem is that WordPress is designed as one big airtight hatchway. Any attack that gets through the first hatch has no further obstacles to persistence.
Compare that to any application with a fully-reproducible build step. If it gets compromised, you can discard the container and replace it with a freshly-built one.
Compare that to any application with a fully-reproducible build step. If it gets compromised, you can discard the container and replace it with a freshly-built one.
OT: The listener infers, the speaker implies.
Nice!
As much as Wordpress gets bad pub, there is certainly the open ways in which security is handled and patches are distributed. Far better in most ways to commercial CMS (and even some open source) where systems seem to run unpatched until a system upgrade or a security incident.
As much as Wordpress gets bad pub, there is certainly the open ways in which security is handled and patches are distributed. Far better in most ways to commercial CMS (and even some open source) where systems seem to run unpatched until a system upgrade or a security incident.
clearly some folks are downvoting because unpopular opinion.
Come on, folks.
Come on, folks.
Seriously! It's not even civil dissent, most of it is mean grandstanding.
Wordpress is ubiquitous. There are more technically challenged users than technically inclined. So here are your options - auto updates, or I'm guessing millions of outdated, incredibly vulnerable sites sitting on shared hosting boxes out there. I like my Webfaction account, I'd prefer the other tenants on my server to be as up to date as possible.
Just such unnecessary snark. The guy wrote a blog post. He's being skewered for it.
Wordpress is ubiquitous. There are more technically challenged users than technically inclined. So here are your options - auto updates, or I'm guessing millions of outdated, incredibly vulnerable sites sitting on shared hosting boxes out there. I like my Webfaction account, I'd prefer the other tenants on my server to be as up to date as possible.
Just such unnecessary snark. The guy wrote a blog post. He's being skewered for it.
Ok, I'll be the devil's advocate here. I hate Wordpress, I really do. But there is a reason it's so successful.
Show me another similar CMS (if that's what you want to call it) that's as easy to install and use, in any language or platform.
Django and DotNetNuke are the only ones I can think of that come close, and neither of them are as easy to install and work with as Wordpress. That's why it's so popular.
Sure most HN visitors are developers working with better stuff and wouldn't be caught dead using WP but if you're a non developer business person looking for a quick solution it can't be beat!
We should all be working on an easy to use, yet more secure alternative.
Show me another similar CMS (if that's what you want to call it) that's as easy to install and use, in any language or platform.
Django and DotNetNuke are the only ones I can think of that come close, and neither of them are as easy to install and work with as Wordpress. That's why it's so popular.
Sure most HN visitors are developers working with better stuff and wouldn't be caught dead using WP but if you're a non developer business person looking for a quick solution it can't be beat!
We should all be working on an easy to use, yet more secure alternative.
People always beat up on software that has security vulnerabilities.
The thing is, the auto update feature is not an affirmative defense for the criticism. There are probably plenty of legitimate defenses out there - developing secure software is quite obviously something that is hard to get right.
But offering auto-updating is only a defense against arguments claiming that updating WordPress is a pain in the ass, not people claiming that the codebase has lots of security flaws.
You also can't use other software being garbage as a defense for why some other piece of software isn't garbage.
You have to evaluate the actual merits of WordPress in regards to the code quality, chance of being exploited, etc. It updating automatically when exploits are made public is not the same thing as not being vulnerable to frequent exploitation, nor are other frameworks failing in some other way exoneration for any failings WordPress might have.
To be clear: I don't care about WordPress, and do not have a stance on whether or not it's great or awful. All I know for sure is that it is certainly quite popular.
But this article is built upon a shaky premise and lots of logical fallacies. If you want to write about how awesome it is that WordPress auto-updates, then write about it. Just don't try to use that as a defense for criticism about other aspects of the codebase.
The thing is, the auto update feature is not an affirmative defense for the criticism. There are probably plenty of legitimate defenses out there - developing secure software is quite obviously something that is hard to get right.
But offering auto-updating is only a defense against arguments claiming that updating WordPress is a pain in the ass, not people claiming that the codebase has lots of security flaws.
You also can't use other software being garbage as a defense for why some other piece of software isn't garbage.
You have to evaluate the actual merits of WordPress in regards to the code quality, chance of being exploited, etc. It updating automatically when exploits are made public is not the same thing as not being vulnerable to frequent exploitation, nor are other frameworks failing in some other way exoneration for any failings WordPress might have.
To be clear: I don't care about WordPress, and do not have a stance on whether or not it's great or awful. All I know for sure is that it is certainly quite popular.
But this article is built upon a shaky premise and lots of logical fallacies. If you want to write about how awesome it is that WordPress auto-updates, then write about it. Just don't try to use that as a defense for criticism about other aspects of the codebase.
I was never a big a fan of WP, but… I agree the ease of updates is an extremely important feature, especially for non-technical users. I'm working on a small conversion project migrating content from a Joomla site to Wordpress. The original site was running on Joomla 1.5 (Support for this version ended in Sept. 2012!). The upgrade path was too cumbersome so the clients just "took the risk". It was compromised several times but "cleaned up as best we could". Needless to say, we're ditching that server.
Still not a fan of WP self-installs, but hosted on WPEgine with smart tech support, automatic daily snapshots with the option for non-technical people to back up or revert the whole thing with a single-click is super simple. For added security and performance we'll be using cloudflare DNS, applied a plugin to hide any evidence of wordpress use and use just a few well-known and maintained plugins. Nothing is perfect, but ease of use, ease of upgrades and ease of maintenance go a loooooong way. It's mighty budget-friendly too.
Still not a fan of WP self-installs, but hosted on WPEgine with smart tech support, automatic daily snapshots with the option for non-technical people to back up or revert the whole thing with a single-click is super simple. For added security and performance we'll be using cloudflare DNS, applied a plugin to hide any evidence of wordpress use and use just a few well-known and maintained plugins. Nothing is perfect, but ease of use, ease of upgrades and ease of maintenance go a loooooong way. It's mighty budget-friendly too.
What plugin are you using to "hide" Wordpress?
It doesn't matter because it won't help much, if at all. The script kiddies are running scripts that check for known files in several popular CMSs, so unless the plugin makes major changes to WP's behaviour, WordPress will still be findable.
Hell, I even had a non-important, BS Rails app get shut down on shared hosting (Webfaction) because someone tried random WP exploits on it (some plugin that accepted a POST and could be exploited via the payload). Rack stored the payload in a temp file and Webfaction saw the tmp file as a new file I didn't upload and suspended the app.
The first time it happened, I just deleted the file and went forward. The second time, I just deleted the app. I know I could write a script to deal with this, but it was just a test, playground type app. All it did was make me say I needed to move my "blog" off WordPress and stop trying to host Rails apps on Webfaction.
PS: The domain the Rails app was on had never hosted a WP site ever before. WP is just so ubiquitous that that they were just trying to hack any site -- even one that had like 3 organic visitors ever.
The first time it happened, I just deleted the file and went forward. The second time, I just deleted the app. I know I could write a script to deal with this, but it was just a test, playground type app. All it did was make me say I needed to move my "blog" off WordPress and stop trying to host Rails apps on Webfaction.
PS: The domain the Rails app was on had never hosted a WP site ever before. WP is just so ubiquitous that that they were just trying to hack any site -- even one that had like 3 organic visitors ever.
I trust WPEngine's IDS to do a good job on these.
Our boilerplate does a pretty good job of hiding that we are using WordPress. The only way you can tell via source is W3 Total Cache writing out a comment to the bottom of the page. Oh and WordPress SEO (Yoast) is a dead giveaway too. We see nowhere near the number of bots that our non boilerplate sites do.
https://github.com/GunnJerkens/wp-boilerplate
https://github.com/GunnJerkens/wp-boilerplate
WordPress's code is badly designed and written in a language that I no longer believe serves the best interests of the Internet in general.
WordPress as a globally managed app is FANTASTIC. Automattic does a superb job of keeping on top of just about everything that comes its way. They do great work over there, and I'm really proud of that whole team.
WordPress as a globally managed app is FANTASTIC. Automattic does a superb job of keeping on top of just about everything that comes its way. They do great work over there, and I'm really proud of that whole team.
>WordPress's code is badly designed and written in a language that I no longer believe serves the best interests of the Internet in general.
It's 2015. This is not your grandparents PHP.
Besides PHP serves the largest website on Earth (Facebook) and a good 20% or more of the rest (via Wordpres, Drupal et al).
It's 2015. This is not your grandparents PHP.
Besides PHP serves the largest website on Earth (Facebook) and a good 20% or more of the rest (via Wordpres, Drupal et al).
> Besides PHP serves the largest website on Earth (Facebook) and a good 20% or more of the rest (via Wordpres, Drupal et al).
Popular != good. None of those points mean anything, PHP is still a badly designed language that lacks consistency and makes language designers feel like puking. It's a collection of hacks more than a language.
Popular != good. None of those points mean anything, PHP is still a badly designed language that lacks consistency and makes language designers feel like puking. It's a collection of hacks more than a language.
A language designer's gastrointestinal state is orthogonal to a programming language's usefulness and usability. PHP is both of the latter in part by virtue of it's ubiquity.
Further, many years development experience has allowed me to appreciate that the benefits of a programming language are often inversely proportional to it's level of design purity. And the greater the longevity of a widely-useful programming language, the more haters it will have.
Further, many years development experience has allowed me to appreciate that the benefits of a programming language are often inversely proportional to it's level of design purity. And the greater the longevity of a widely-useful programming language, the more haters it will have.
>Popular != good.
That maybe so in pop music and matters of taste.
In the context of software, popular as in powering half of the web means stable, reliable and battle-tested.
That it doesn't satisfy some ideological purity doesn't mean much.
All languages have crappy parts, especially the more popular ones. C++ has a pile-on-kitchen-sink design, and yet it powers 90% of the desktop software world. C has horrible safety mechanism, and it rules in systems programming. Javascript, the other web darling, I won't even get into that. Java has all the legacy SDK crap and the needles boilerplate ceremony, and it just got closures like yesterday.
Sorry, but the world isn't built on Haskell and CL, and even less so in Dylan or whatever exotic thing you have in mind.
That maybe so in pop music and matters of taste.
In the context of software, popular as in powering half of the web means stable, reliable and battle-tested.
That it doesn't satisfy some ideological purity doesn't mean much.
All languages have crappy parts, especially the more popular ones. C++ has a pile-on-kitchen-sink design, and yet it powers 90% of the desktop software world. C has horrible safety mechanism, and it rules in systems programming. Javascript, the other web darling, I won't even get into that. Java has all the legacy SDK crap and the needles boilerplate ceremony, and it just got closures like yesterday.
Sorry, but the world isn't built on Haskell and CL, and even less so in Dylan or whatever exotic thing you have in mind.
WordPress and stable/battle tested don't really go together in my experience. Especially since plugin quality varies widely.
Edit: I guess I can concede that vanilla WordPress is mostly stable and very battle tested.
Edit: I guess I can concede that vanilla WordPress is mostly stable and very battle tested.
> In the context of software, popular as in powering half of the web means stable, reliable and battle-tested.
No, it doesn't, it merely means popular.
No, it doesn't, it merely means popular.
Additionally, context is never relevant, popular doesn't mean quality in any context. Something can be both popular and quality, but popularity doesn't make something quality.
I've heard closer to 60%, but I agree wholeheartedly. I've worked in many other languages but when I want something done, to work, and I'm not doing something so large I need to squeeze every last drop of memory - I do it in PHP. It's a wonderful scripting language. I write more CLI scripts in it than web apps at this point.
Let's ask one question: what CMS, CRM, programming language, operating system, etc doesn't come out with major security flaws every once in a while?
All of them, even OpenBSD. Software has bugs, and security flaws. It is not how buggy they are, but how well we patch them from a larger scale and that, WordPress does extremely well.
All of them, even OpenBSD. Software has bugs, and security flaws. It is not how buggy they are, but how well we patch them from a larger scale and that, WordPress does extremely well.
One of the biggest strengths of Wordpress is also a fatal flaw - the flexibility of its plugin system, and how easy it makes finding and installing plugins and themes. Each is its own self-contained web application that runs with the same permissions as the application itself.
Yes, this applies to any open source application, but given how huge Wordpress' plugin landscape is, it's a big problem even if you assume the core application itself is secure (for the sake of argument.) Almost nobody pores over every line of code in every plugin before they install it (much less each update) - at best they just check to see if it has a high rating.
Yes, this applies to any open source application, but given how huge Wordpress' plugin landscape is, it's a big problem even if you assume the core application itself is secure (for the sake of argument.) Almost nobody pores over every line of code in every plugin before they install it (much less each update) - at best they just check to see if it has a high rating.
The article and many commenters miss a critical flaw: wordpress only auto-updates minor releases. 4.1.0 will be updated to 4.1.x, but not 4.2.x or beyond.
I built a WP site about 6 months ago on 4.0.x (current at the time), since then it has required 2 manual updates to get to 4.2.x.
As many others have noted, plugins are a bigger problem. They often break on new major releases and update less frequently. There is a lot good about wordpress, but the update cycle and security problems are a huge maintenance issue.
I built a WP site about 6 months ago on 4.0.x (current at the time), since then it has required 2 manual updates to get to 4.2.x.
As many others have noted, plugins are a bigger problem. They often break on new major releases and update less frequently. There is a lot good about wordpress, but the update cycle and security problems are a huge maintenance issue.
What's up with this nag? https://i.nyr.es/Captura-de-pantalla-2015-05-15-a-las-3.07.3...
Your site is a simple WordPress blog, I'm sure you can perfectly host it for $1/month.
Your site is a simple WordPress blog, I'm sure you can perfectly host it for $1/month.
You are absolutely right, I've removed the notice. It was an experiment, but it did not have the desired outcome. Blockers gonna block.
Seems unnecessarily snarky, unless I should have read some implied smilie emoticon...
Not snarky at all. That popup was an unnecessary annoyance.
I feel like there's something about a mousetrap and a mouse here.
Updating plugins often breaks things. For instance, I updated our AD plugin for a company blog a few days ago and no one could log in. I had to do some research and eventually the plugin was rolled back from backup.
Can't wait to see what auto update breaks.
Not a fan of Wordpress. It's a lot more work than it's worth.
Can't wait to see what auto update breaks.
Not a fan of Wordpress. It's a lot more work than it's worth.
So your point is that it does not matter that WordPress is a huge mess as long as it updates automatically?
No, my point is that not everything that WordPress does is evil.
Its auto-updates protect a very large part of internet-facing websites of getting hacked. And it's not something a lot of other CMS's have integrated.
Its auto-updates protect a very large part of internet-facing websites of getting hacked. And it's not something a lot of other CMS's have integrated.
Self updating requires overwriting its own files (or access to your FTP credentials). Enabling this goes against almost every website/server hardening guidebook out there.
It also requires allowing loopback HTTP requests in response to every incoming request to implement a pseudo cron system.
There's a good reason most other CMSes don't implement automatic updating.
It also requires allowing loopback HTTP requests in response to every incoming request to implement a pseudo cron system.
There's a good reason most other CMSes don't implement automatic updating.
If an attacker has code execution, I've already lost. Whether they have to inject it every time or can write it to the filesystem isn't really the point.
The current system is better than no automatic updates.
One that uses a separate user that has write access would be superior, but many users don't actually have a separate user to cron that job as.
The current system is better than no automatic updates.
One that uses a separate user that has write access would be superior, but many users don't actually have a separate user to cron that job as.
If the webserver can write to the web root, that means an vulnerability that allows arbitrary writing can be escalated to code injection.
In a same environment, the web user wouldn't be able to write to the file system at all, much less the web root.
Sanity being rate doesn't really justify only offering auto updates to the insane.
In a same environment, the web user wouldn't be able to write to the file system at all, much less the web root.
Sanity being rate doesn't really justify only offering auto updates to the insane.
They created something that makes the most common sort of deployment more secure.
This is a net improvement and therefore entirely justified.
This is a net improvement and therefore entirely justified.
> This is a net improvement and therefore entirely justified.
The first does not imply the second. "Our bank is secure because we change out the locks every few days. To facilitate this, all of the locks have their screws on the outside - it was too much work to have someone around to open the doors for the locksmiths all the time."
Interested in hearing how many recent vulnerabilities in WordPress were prevented by not allowing arbitrary writes, whitelisting URLs, and blocking a whole mess of WordPress set headers?
All of them which have occurred in the last year. We've kept up-to-date with our updates, but every security vulnerability which has triggered a major or minor update was prevented not by WordPress updates, but by sensible system security.
The first does not imply the second. "Our bank is secure because we change out the locks every few days. To facilitate this, all of the locks have their screws on the outside - it was too much work to have someone around to open the doors for the locksmiths all the time."
Interested in hearing how many recent vulnerabilities in WordPress were prevented by not allowing arbitrary writes, whitelisting URLs, and blocking a whole mess of WordPress set headers?
All of them which have occurred in the last year. We've kept up-to-date with our updates, but every security vulnerability which has triggered a major or minor update was prevented not by WordPress updates, but by sensible system security.
I don't think anyone is suggesting that you should compromise your security to enable auto-updating. Automatic updates are never better than correct file permissions.
The point here is that a large number of WordPress sites are running with file permissions such that the web server can write to the web root.
By trying to auto update, those sites with poor file permissions get a minor security benefit (shorter time between patch release and patch application) while all of the installations running with safe file permissions are entirely unaffected.
There's no downside to a secure site having the automatic update code. There's a small upside to an insecure site having it.
The point here is that a large number of WordPress sites are running with file permissions such that the web server can write to the web root.
By trying to auto update, those sites with poor file permissions get a minor security benefit (shorter time between patch release and patch application) while all of the installations running with safe file permissions are entirely unaffected.
There's no downside to a secure site having the automatic update code. There's a small upside to an insecure site having it.
Other cms have taken the less-trodden path of not being a bug-ridden security debacle and ignoring security reports until researchers release them [0].
-- Yet another wordpress hack victim.
[0] http://klikki.fi/adv/wordpress2.html
-- Yet another wordpress hack victim.
[0] http://klikki.fi/adv/wordpress2.html
Wordpress being secure would protect those sites from being hacked. All that auto-updates do is creating yet another vulnerability, and fixing problems some time after they are public known.
Want to get into an Wordpress installation? just wait until next week's problem becomes public, and be faster than the auto-updater.
By the way, Drupal has an auto-updater too.
Want to get into an Wordpress installation? just wait until next week's problem becomes public, and be faster than the auto-updater.
By the way, Drupal has an auto-updater too.
So what happened to Wordpress? Their slogan used to be "Code is poetry" and today they are the punchline of every bad code anecdote told.
The only projects that nobody ridicules are the ones that nobody uses.
I think Wordpress gets a lot of unfair blame. I often see the size of its code-base touted as one of the reasons to avoid its use. It seems the general consensus amongst a lot of developers out there is that Wordpress isn't OOP. Seriously when was the last time someone building a Wordpress website had to do anything outside of the wp-content folder? I have been working with it for like 8 years now. I used it before it even had half the CMS features that it has now. Making Wordpress completely OOP isn't going to make it any better than it already is, nor will it make more people visit your website or make you breakfast in the morning.
I don't care if the Wordpress code-base is a mixture of procedural and object-oriented PHP code, I use the hooks/actions system to change things, I never have a need to go into the wp-includes folder unless I am trying to work out how a new feature works that isn't fully documented (which is extremely rare). I also see people calling PHP a bad language because of the way Wordpress was built on-top of it, like some can't make the distinction between the language and the prolific CMS built on-top of it.
When a Wordpress website gets hacked, you know who should also shoulder the blame? The developer that set it up and or the server admin that setup the server. If you're setting up Wordpress on a server that doesn't have the appropriate folder permissions set, the wp-config file moved back one level from root (and thus not publicly accessible), you're using the default "wp_" database table prefix and you use FTP to move files to and from the server because setting up SSH access intimidates you, then it is your fault as well. A properly secured Wordpress installation is very difficult to attack. Sure it doesn't protect you from all attack vectors, but it goes a long way. Making sure your username in Wordpress isn't admin always goes a long way. On all Wordpress sites that I monitor I see numerous brute force scripts being run trying to guess the password for a user named "admin" jokes on them, no such user even exists, so they just instantly IP banned (which is annoying because some seem to cycle through thousands of IP addresses). Running an old version of Wordpress and you get attacked, is it Wordpress' fault or your own?
People love to bash Wordpress, but you want to know the harsh reality? There is no better alternative (trust me, I tried looking once, I legitimately spent weeks trying alternatives and found nothing better). Wordpress is the number #1 CMS because it is the best, regardless of its code-base, nothing else compares. Some people will try telling you to use Drupal, but they generally don't know what they are on about. "Oh, don't use Wordpress it gets hacked all of the time" - no, it doesn't. Your lack of technical competency is the reason you get hacked all of the time. A bad workman blames his tools.
My personal blog gets 3k hits per day, I see numerous attempts to hack my site and in the 5 years I have been running Wordpress on my personal blog alone, I have never been successfully hacked once. Because I don't just set Wordpress up using the default settings, I use strong passwords, I use unique usernames, I lock file and folder permissions, I move credentials out of the root directory.
Wordpress is slightly cursed in that it has a low learning curve, it makes it incredibly easy for just about anyone to setup their own self-hosted Wordpress installation. While exploits are not the users fault, a lot of the most common hacks you see on Wordpress were in part due to the fact the user kept a default setting or set something up incorrectly.
The auto update functionality is great in Wordpress, I don't think this feature alone is a big selling point for the CMS. The auto-update functionality in Wordpress doesn't always work, but it is better than nothing. As the author points out, particular Drupal and Magento are both so complicated (even though they have clean code-bases) that they make it difficult to perform updates or do basic tasks people take for granted in Wordpress.
Compared to the number of times I have been infected with malware and viruses over the years as a Windows user (many times due to my own fault), Wordpress does not even register on the Richter scale of insecurity and annoyance in comparison.
Lets start taking responsibility for our own actions, developers. We can't blame PHP and Wordpress for all security issues. Somewhere along the line you need to make some effort and not assume a CMS or framework has your best interests at heart or has covered every possible angle.
I don't care if the Wordpress code-base is a mixture of procedural and object-oriented PHP code, I use the hooks/actions system to change things, I never have a need to go into the wp-includes folder unless I am trying to work out how a new feature works that isn't fully documented (which is extremely rare). I also see people calling PHP a bad language because of the way Wordpress was built on-top of it, like some can't make the distinction between the language and the prolific CMS built on-top of it.
When a Wordpress website gets hacked, you know who should also shoulder the blame? The developer that set it up and or the server admin that setup the server. If you're setting up Wordpress on a server that doesn't have the appropriate folder permissions set, the wp-config file moved back one level from root (and thus not publicly accessible), you're using the default "wp_" database table prefix and you use FTP to move files to and from the server because setting up SSH access intimidates you, then it is your fault as well. A properly secured Wordpress installation is very difficult to attack. Sure it doesn't protect you from all attack vectors, but it goes a long way. Making sure your username in Wordpress isn't admin always goes a long way. On all Wordpress sites that I monitor I see numerous brute force scripts being run trying to guess the password for a user named "admin" jokes on them, no such user even exists, so they just instantly IP banned (which is annoying because some seem to cycle through thousands of IP addresses). Running an old version of Wordpress and you get attacked, is it Wordpress' fault or your own?
People love to bash Wordpress, but you want to know the harsh reality? There is no better alternative (trust me, I tried looking once, I legitimately spent weeks trying alternatives and found nothing better). Wordpress is the number #1 CMS because it is the best, regardless of its code-base, nothing else compares. Some people will try telling you to use Drupal, but they generally don't know what they are on about. "Oh, don't use Wordpress it gets hacked all of the time" - no, it doesn't. Your lack of technical competency is the reason you get hacked all of the time. A bad workman blames his tools.
My personal blog gets 3k hits per day, I see numerous attempts to hack my site and in the 5 years I have been running Wordpress on my personal blog alone, I have never been successfully hacked once. Because I don't just set Wordpress up using the default settings, I use strong passwords, I use unique usernames, I lock file and folder permissions, I move credentials out of the root directory.
Wordpress is slightly cursed in that it has a low learning curve, it makes it incredibly easy for just about anyone to setup their own self-hosted Wordpress installation. While exploits are not the users fault, a lot of the most common hacks you see on Wordpress were in part due to the fact the user kept a default setting or set something up incorrectly.
The auto update functionality is great in Wordpress, I don't think this feature alone is a big selling point for the CMS. The auto-update functionality in Wordpress doesn't always work, but it is better than nothing. As the author points out, particular Drupal and Magento are both so complicated (even though they have clean code-bases) that they make it difficult to perform updates or do basic tasks people take for granted in Wordpress.
Compared to the number of times I have been infected with malware and viruses over the years as a Windows user (many times due to my own fault), Wordpress does not even register on the Richter scale of insecurity and annoyance in comparison.
Lets start taking responsibility for our own actions, developers. We can't blame PHP and Wordpress for all security issues. Somewhere along the line you need to make some effort and not assume a CMS or framework has your best interests at heart or has covered every possible angle.
Yawn. More excuses for using a big old pile of spaghetti code with no testing or dependency management. Auto-updates? big deal, any decent framework can roll out updates on composer.
Yet here we are;
- Drupal 7: manual updates, or funky drush commands
- Magento: requires running shell scripts (!!) to patch at the CLI
- Joomla: no auto updates
- Typo 3: no auto updates
- ...
Composer helps, but it helps developers. It does not help the average user that has no clue on how to apply those patches.
People download a CMS from the internet, throw it on a cheap host and expect it to work. Updates? What are those?
Composer helps, but it helps developers. It does not help the average user that has no clue on how to apply those patches.
People download a CMS from the internet, throw it on a cheap host and expect it to work. Updates? What are those?
I'm with you on this. WordPress is acknowledging the actual behavior of the people who use it and aiming to be secure inside that reality instead of telling people they are doing it wrong and to learn how to internet. That is absolutely laudable and in practice prevents a lot of real problems and lifts people up instead of puts them down.
And that's the problem they shouldn't be doing that. Hosting a website is not a fun weekend project you get from Target/Walmart as a DIY kit.
People wouldn't be happy if I started building my own car to just drive around where ever I felt like, making it 'easy' and 'safe' to just throw up a website anywhere is an excellent way to get hacked.
People wouldn't be happy if I started building my own car to just drive around where ever I felt like, making it 'easy' and 'safe' to just throw up a website anywhere is an excellent way to get hacked.
>Hosting a website is not a fun weekend project you get from Target/Walmart as a DIY kit.
Why? It's not like most websites are mission critical.
Heck, even if a major business website went down for a couple of days, it wouldn't be that much damage anyway compared to other things that can and regularly do happen to the supply chain or market...
>making it 'easy' and 'safe' to just throw up a website anywhere is an excellent way to get hacked
Yeah, and so? Getting hacked is the end of the world?
Why? It's not like most websites are mission critical.
Heck, even if a major business website went down for a couple of days, it wouldn't be that much damage anyway compared to other things that can and regularly do happen to the supply chain or market...
>making it 'easy' and 'safe' to just throw up a website anywhere is an excellent way to get hacked
Yeah, and so? Getting hacked is the end of the world?
For Mummy-blogger's site about how awesome her kid is? Probably not the end of the world, expect that now her site is sending spam and hosting malware. You'd be pissed if your neighbour left their house unlocked while they went on holiday and it turned into a crack-den.
Drupal 7 can auto-update by cron.
Right, yes, I know, that makes me crazy, but modern PHP is a fine language. HHVM, Hack, Composer, Packagist, the PSR standards: all of that comes together for a nice development workflow. PHP's shared-nothing architecture by default makes horizontal scaling an exercise in simplicity.
But: I don't like WordPress. Yes, it can autoupdate -- and that's certainly better than how things were prior, however WordPress' core code is horrendous. There's a reason why security issues are consistently found.
The bigger issue is the sorry state of most plugins; the bulk of vulnerabilities that end in compromise of WordPress sites are not from the core itself, but the plugins. An autoupdater for those certainly exists, but it doesn't help you if the people writing the plugins to begin with have no clue how to write not-insecure software.
These days, I avoid WordPress like the plague. When I do have to work with it, I've dragged it kicking and screaming into 2015: It lives in a Docker container, is fully 12-factor, completely managed through Composer (including Wordpress' core itself) and all code that I write for it is proper unit tested, PSR-4 autoloaded namespaced classes; this allows me to avoid crappily written plugins and rely on battle-tested libraries instead.
If and when it gets compromised, I can restore the Docker image within seconds, or lock it down as straight HTML by exporting it as a static site temporarily. WordPress can be decent if forced to be, but it's a lot of work and I'd much rather use something that doesn't have so much cruft clogging it up.
I mean heck; you still can't run the latest version of WP on anything other than MySQL, despite technically having a DBAL. Absolutely crazy, considering we have Doctrine or Propel!