Weblog tools collection has a copy of a forum post made by Weathervane about WordPress plugin standards I’ve taken a read through these standards and these are my thoughts.

Jeffro makes the point that there are a few of these points that are easily solved by the use of the official WordPress plugin database. I totally agree on this point.

I have taken to releasing plugins in two ways. If I intend it for distribution and use (official release if you like) then I will use the plugin database. This provides version control and automatic update notification to users and defines a folder structure automatically.

Where a plugin is an example of functionality or a proof of concept then I will make it available on my website.

I do think it is important that people downloading a plugin from the database should expect a certain level of quality and completeness and for that reason I distinguish between the two methods of making a plugin available.

One thing I would like to see added to the database itself is a feedback mechanism for support. One the criticisms made by Weathervane is that too many comment lists are often full of praise posts and this can make it difficult for users with a problem to find a solution in the comments. I agree, but I am still not comfortable deleting comments, even if they don’t actually add value to the conversation.

In the comments Ronald has suggested that the WP Support Forums are used to provide bugs/feedback. I think he has a good point, but it does create a third place for plugin users to check and requires authors to read a lot that may not apply to them. Part of the need for standards is also a need to standardise where people go for support and I expect users will still ask questions in comments and by e-mail.

The Reader Appreciation Project has long advocated separating trackbacks from comments regardless of the content of the post. Doing this certainly makes the post easier to read so if you don’t do this I would certainly agree that turning off trackbacks would be a good idea.

Operations Conventions

On the whole I agree with the points in this section of the list but it does bring up a question for me about what we should be able to expect users to do, or not do.

Weathervane asks that we clearly state the conditions required for the plugin. This is a good point, but, I would like place some responsibility back on the user as well.

He asks that we state whether files have to stay in the folder provided, if the folder provided must be named as it is, and whether plugin files can be renamed.

My answer to that is that in all instances you cannot change anything if you expect it to work.

The plugin author should be responsible for naming things so they are likely to be unique, and properly filing them, but from the moment of unzipping, that plugin should be considered whole and indivisible, unless explicitly stated.

Structural Conventions

I think this section is particularly important, partly because I disagree with some of these points.

If your plugin is only one file then put it in a subfolder called “plugins.” Everything else should be in the root folder.

The WordPress plugins database creates a folder automatically and this really helps the unzuip and go process. I don’t think that plugins should reside in the plugins folder ever. Not because there is necessarily anything wrong with it but because it creates this kind of confusion.

Unzipping the plugin creates a folder. Inside that folder is a readme file, and the plugin file, plus any other documents required.

Now for the biggie: Some plugins have files that go into multiple folders (/plugins, with others going elsewhere, like /wp-admin). The plugin could uncompress to a folder called /installation with two folders in it: /wp-admin and /wp-includes/plugins, containing their respective files—or something like that. With this structure I only have to drop the folders in /installation into my WordPress folder and it’s done.

Should plugins really contain files that will go into a folder other than plugins? In my view no. Never. I really think one of the standards should be that every file necessary is contained with the plugin’s folder.

Some of my own

Weathervane’s list was a good list, and gave us some things to think about, but we all need to chip in and add to that, so here are some of my own.

Plugins shouldn’t try to style parts of the admin page differently, for example, using image replacement techniques to make the admin page header look fancy. I can understand wanting to use less verbose, or more accessible HTML, and that is fine, but the normal user shouldn’t see a difference in the actual appearance, or everyday use.

Secondly, it may be a good idea to develop some plugin design patterns.

In some ways I have done this for the people using my fun-with-plugins tool, but of course the code that produces isn’t open for review and so doesn’t really count.

I think plugin patterns would not only help new developers avoid reinventing the wheel but also make it easier to produce plugins in general.

I’m really interested to see what the standards drive comes up with. I think it is great that the discusion is happening but it does need to be more just a discussion, so if anyone has any wise words about next steps and how to centralise this process chip in please. I suspect the codex is the way to go but a certain level of agreement is probably needed first.