Random plugin structure should be deprecated

[robertaccettura]

Current State

Plugins are currently a bit of a mess. They generally fall into a few categories:

1. A single file. often wp-name.php
2. A handful of files.
3. A directory full of files, and perhaps a few subdirectories within that.

There are several problems here:

Namespace Collisions - each plugin potentially violates each other's namespace if they don't use unique filenames. A good example of this is readme's. Most are lost unless you rename them. Potential for worse exists with common names "feed", "comment", etc.

Management - uninstall isn't always easy since associated files aren't always clearly named. This leaves potential files on the filesystem, and could be a potential security issues.

Upgrades - I've already had one case where I didn't upload a plugin to the ideal location, and the one click update functionality failed.

Suggestion

All plugins should have a parent directory. For example:
/wp-content/plugins/wp-mobile/wp-mobile.php
/wp-content/plugins/wp-mobile/README.txt

/wp-content/plugins/wp-super-cache/Changelog.txt
/wp-content/plugins/wp-super-cache/plugins
/wp-content/plugins/wp-super-cache/readme.txt
/wp-content/plugins/wp-super-cache/wp-cache-base.php
/wp-content/plugins/wp-super-cache/wp-cache-config-sample.php
/wp-content/plugins/wp-super-cache/wp-cache-phase1.php
/wp-content/plugins/wp-super-cache/wp-cache-phase2.php
/wp-content/plugins/wp-super-cache/wp-cache.php

By doing this, the entire thing is simplified. All plugins can then be easily upgraded by replacing the directory, removed by removing the directory, etc. Many plugins already do this on their own (such as wp-cache).

My suggestion is that this methodology be encouraged, and eventually the old method of php's in the plugins directory require opt-in via a constant in wp-config.php perhaps in the 2.7 timeframe.

This would remedy the above problems and provide a much cleaner plugins directory that's easier to manage.

[markjaquith]

We are certainly encouraging it with the way we provide WP Extend/Plugins downloads and plugin upgrades. Once we have plugin installation in core, this should be mostly taken care of. I don't think deprecating plugin files in /plugins/ is necessary. That'd be a headache for a lot of users.

[strider72]

Ultimately the poorly designed plugins are culled by lack of popularity -- people don't use them when they realize they cause problems. They do cause some pain before they get that far, unfortunately. HOWEVER...

Mark -- I believe WordPress's presumption that "of course" all plugins should go through WP Extend does a significant disservice to many plugin authors (e.g. auto updates that do not distinguish which plugins are _not_ checked....)

So saying "this won't be an issue once WP Extend does... whatever" is not a particularly good answer.

[DD32]

(e.g. auto updates that do not distinguish which plugins are _not_ checked....)

There is a ticket elsewhere for the autoupdate and UI, but no ones done any work for a UI for it: #5117

However, I'm not too sure on what the rest of the message is trying to say..

Mark -- I believe WordPress's presumption that "of course" all plugins should go through WP Extend does a significant disservice to many plugin authors

WordPress "Encourages" that plugins are added to the WordPress.org database, but obviously, Doesnt require it for plugin operations, but does require it for any plugin-related tasks such as auto-update or update notifications(unless the plugin takes care of that itself).

All plugin authors are going to ultimately have to release plugins in the format which WordPress uses. - If WordPress was to drop support for the current plugin system entirely(not gonna happen..) then plugin authors would then re-release plugins in a compatible format, Its the plugins which need to adhere to the way WordPress works rather than WordPress bending backwards to support old plugins or poorly coded plugins. (IMO)

Files simply droped in the /plugins/ folder is ok, But its strongly recomended by me and others to put it in a folder, Simply so WordPress knows what files are what, If its just a simple plugin, then feel free to put it straight in /plugins/ but be warned that the WordPress plugin upgrade will put it into a folder.

I dont think ignoring single-file plugins in /plugins/ is a good idea, its good for backwards compatibility and simple custom plugins, Overtime, WordPress will probably sort them into folders as updates come out (assuming its on wordpress.org)

(apologies for repeating myself, or some points not making total sense)

[strider72]

DD32 --
Not trying to start a war ;)

I was responding to Mark's comment that this issue would be fixed as WP Extend makes changes, which is based on a presumption that plugin authors use WP Extend. I just think that assumption is a bit dangerous, and thus worth pointing out.

I'll take a look at that other ticket (#5117) & maybe pick it up if I think I can hack it.... :)

[DD32]

I was responding to Mark's comment that this issue would be fixed as WP Extend makes changes, which is based on a presumption that plugin authors use WP Extend. I just think that assumption is a bit dangerous, and thus worth pointing out.

Ah, Theres where the mis-understanding was (Its late! :P)

I dont think Mark meant that the issue would be fixed as such, But organisation will be much more improved if generally the plugins were automatically put into folders by WordPress rather than relying on users. (Plugin installation from within teh admin panel: #6015)

[Otto42]

Perhaps we could start putting a warning or other type of message on plugins that are not located in a subdirectory of the plugins directory. That would be a good start, and would a) encourage plugin authors to include subdirectories and b) warn users that upgrades and such won't work properly without subdirectories.

However, in order to do this, we need to follow that path as well. Set an example. And by that, I mean that Hello Dolly needs to be in a subdirectory.

[strider72]

I don't believe putting warnings up in front of end users is the answer. I would definitely support a campaign to encourage plugin authors to make "nice" plugins, but throwing "Caution" signs up in front of end users doesn't serve any purpose that I can see.

You can't stop a careless programmer from making broken plugins. Trying to do so will be a huge waste of effort. A poorly working plugin is its own (bad) publicity.

I think this should be a public campaign, and not something that can be remedied in code.

...unless you're suggesting that plugins outside of directories should be deprecated and eventually unsupported; which may or may not be a good idea. I actually like this idea, though there should be a _long_ lead time before support is actually *dropped* -- we're talking WordPress 3.0 at least!

(Heh -- re-reading the original ticket, deprecating it is _exactly_ what the original poster was suggesting!)

I'm all for setting a good example by updating "Hello Dolly". Somebody recently did just that and posted it to WP-Hackers -- if it's a good update it should be made into a new ticket and patch.

[jacobsantos]

It is ultimately up to the user on where the plugin is located. Namespace issues can only be resolved with plugin authors and proper programming practices. As noted before, the plugin upgrader does fix this issue as long as the plugin is added to the Plugin Extend site.