
What I Love About Wordpress Plugins - madmax108
http://meta.discourse.org/t/what-i-love-about-wordpress-plugins/5697
======
jacques_chester
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.

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

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

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

------
Svip
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...](https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=blob;f=languages/messages/MessagesEn.php;h=c5dba69dc0dbe10af14991d83a7b515ee75642f5;hb=HEAD)

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.

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

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

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

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

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

