What I Love About Wordpress Plugins | Hacker News Reader

What I Love About Wordpress Plugins

meta.discourse.org

18 pointsmadmax10814 comments

As a wordpress administrator, I detest plugins.

There's no isolation. If a plugin breaks or is slow, the whole of Wordpress breaks or is slow(er).

That's not entirely their fault. Every PHP application that runs in a shared hosting environment is stuck with the same unsolvable stability / security problems:

* Shared login to the database means and plugin or theme can see any data on any table

* Single-process structure ensures that a single glitch halts the world

* Serial execution means a slow plugin can choke a site

And so on and so forth.

I still believe that when web apps are targeted at VPSes a lot of this pain will go away. Imagine if plugins ran as jailed processes and communicating by message queues. If a plugin faulted or didn't meet the render deadline, its input would simply be skipped and life would go on.

A man can dream.

Some of this is inherent to the nature of plugins that alter the guts of a large program—look at the issues Firefox has had. At best Wordpress could rewrite itself to be insanely parallel _just in case_ a plugin in any particular area is slow, but that's a whole lot of work, the result is harder to maintain, and PHP isn't particularly amenable to it.

As I said, they are constrained by the general LAMP architecture. You can't make it more parallel, you can't make objects more independent.

> the result is harder to maintain

This I disagree with.

I have to disagree with the filters. Sure, it's convenient at first glance, but it turns into a nightmare. The filter functionality in WordPress leads to spaghetti code at it's worst. I don't want to think about how many times I've had to comb through a dozen plugins on a WordPress install trying to find some obscure, poorly written filter that breaks something in a very peculiar way.

I think the problem is that you're altering some global state with no knowledge of how others may be altering the same data, and the code itself becomes an entangled mess of callbacks.

To be quite honest, I dislike GetText() quite a lot. Drupal re-implements it as t(), but it still is fundamentally lacking in context, which Drupal later had to add as a second parameter. The English word 'order' can be translated to »sortering« or »bestilling« depending on context in Danish.

I much much more prefer MediaWiki's approach, by naming all message strings something related to their purpose, this often results in a name structure, that defines their grouping and purpose, takes up less space, and does not require context definitions, because it does per default.

As a result, you contain all your messages - per default at least - in a message file, such as this: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a...

But each message can be altered, which is then saved in the database; if a message is not in the database, its default is used.

Aaaaand of course there are downsides to every convenient feature.

Ability to install plugins directly from the admin interface? Instantly enable them without restarting anything? This is only possible because your plugins directory and everything in it is writable by the web server. In other words, any plugin can mess with any other plugin, or even WordPress itself. The only reason this doesn't happen is because you have yet to come across a malicious plugin.

WordPress plugins can do anything and everything. They are very powerful. Therefore, they should be treated with the same level of caution that any powerful yet relatively unrestrained program deserves. Like ActiveX controls on IE6 (shudder). You don't simply search n' download them for a test drive, unless you really really trust the competence and moral integrity of the author and the repository.

...so one of the basic security things one must do on a webserver is separating the vhost unix accounts (to avoid compromised installs overtaking other vhosts), as well as separating the web server virtual account from the FTP account.

Wordpress then can update itself using your FTP credentials, but a malicious or hacked plugin can not compromise the site.

That still leaves the wp-content directory and everything in it, including other plugins, writable by the web server. A malicious or compromised plugin can then check whether some of the highly popular plugins are installed, and modify their files to compromise the whole site. You don't need access to WordPress's core files to inflict a huge amount of damage.

Some directories do need to be writable for caching and uploading purposes, but those are just data, and data is usually inert. It's dangerous to leave any executable file (*.php) writable by the web server.

>That still leaves the wp-content directory and everything in it, including other plugins, writable by the web server.

You don't have to have the wp-content directory writable by the web server. I certainly don't on the WordPress installs that I maintain. I also do not have FTP open and listening. Users can SSH/SFTP files up if they wish, but I don't let the web server write into the Wordpress area for specifically that reason.

It does not, read exactly what I've written above - there are three users in total: your ssh login-account, the (user-unique) PHP account (suphp or similar solution used for this) and the user-unique FTP account.

So, if you set up the ACLs and permission bits correctly, the webserver has no write rights, only you and the FTP user have.

> Therefore, they should be treated with the same level of caution that any powerful yet relatively unrestrained program deserves.

A friend of mine's mother routinely compromises his vps simply by installing themes which include the popular TimThumb (https://code.google.com/p/timthumb/) plugin. Through the plugin, it's easy for an attacker to install web shells etc.

This is true of many plugin systems, and RubyGems for example is not immune from this. The difference between installing a new gem however, is that as a software engineer or developer it's your job to have confidence in the security of the gem. With a Wordpress plugin, any user of Wordpress can easily install it, and sometimes it's the theme which includes the plugin.

The old Tim Thumb is vulnerable. The writer of tim thumb fixed that security hole though after the issue from what I read.

The Ruby/Python fanboys might downvote me for this, but the author here states the biggest advantage of the PHP ecosystem in general: most popular software is unpack-and-it-works! And that on near every OS/server combination out there.

Why downvote? It's true, and we need to be stealing that somehow.

Reply on news.ycombinator.com