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.

This going to be my last post on the issue uninstallers for WordPress plugins. This is an explanation of the code I have submitted to the WordPress trac, and a plugin to give you an idea of what it does differently to the previous two versions I produced.

I think it is important to note that although I have submitted this code for inclusion in the core, that doesn’t mean it will be included exactly as I submitted it, or even that it will be included at all, but I am hopeful.

In the first version a separate file was required, but it was fairly evident that this wasn’t going to be the best solution. The second version changed this, allowing the plugin author to register a callback function, and added functions to help ringfence the uninstall content from the live plugin content.

In the final version not even this is necessary.

The most important function in version three is register_plugin_assets(). This function, used in an activation function allows the plugin author to register the options they intend to add to WordPress, the database tables they intend to add, and to register a callback function within the plugin itself.

register_plugin_assets( $plugin_file , $callback , $options = array() , $tables = array() );

Registering the tables and options lets WordPress take care of uninstalling those, meaning that the plugin author doesn’t need to write any code at all to handle uninstallation unless it requires more complex changes or file deletions. In many cases $callback can be set to NULL.

If a callback function is registered, before the tables and options are removed, the plugin will be loaded to allow the callback function to be used. There is no longer a need to ringfence that code; however, it will mean that plugin authors need to be careful about what their plugin does that isn’t triggered by a hook.

On the surface the process works the same. When a plugin is deactivated, and there is something to uninstall, the uninstall option will be presented beneath the plugin entry. Although, the discussion on the trac is that it may be in a table column of its own I have left it as per previous versions as that is what I actually submitted and because of the limitations of doing it as a plugin.

You can download Fun with Uninstallation 0.3 here.

The plugin is as close to the code I submitted. As it was written for the version of WordPress currently in development I haven’t done much testing on it outside of that. The version I tested the plugin on was 2.3.2.

This is a quick post, actually more of a test, to explain my plans to start using asides to offer feed only content.

I don’t intend to start publishing hundreds of “hey look at this” posts but where I think something is worth posting, but I don’t have enough to say to warrant a War and Peace style tome, then I may well decide to offer it up to only those kindly souls who regularly read what I have to say.

With any luck, assuming the plugin does what I think it should, this will be the first.

I’ve had a few comments recently from people using one of my plugins but having difficulties with the CSS. This is not so surprising because of the great variety of themes out there; however, it occurs to me that a set of standards for theme CSS might be useful for both themers and plugin authors.

If you take a look at the source code of of some blogs you may see five to ten entries for external CSS files, plus several style tags in the header itself, all of which will effect and potentially override each other.

The base CSS in the theme itself can render any one of those effectively inoperable depending on whether it uses ID attributes or classes, and how deeply it specifies the content.

There’s a nice, quick and easy, primer on CSS Specifity at HTML Dog and a slightly longer and more in depth piece at on specifity Smashing Magazine.

All this really means is that you can have two identical themes but, because of the CSS used, a plugin will work well on one, and work poorly on another, and the variety of themes means that it can be impossible to compensate for all of them successfully.

One possible solution to this is to try and set some standards; not an easy task, I know.

Take the standard layout, #header, #sidebar, #footer, #content. All using ID tags. They are an efficient way to go when building a theme but if you style #sidebar ul li ul li, you need to be at least that specific to override it. Knowing that it is how Kubrick does it means you probably style exactly that in the plugin in the hope that others copy it.

Now take that same plugin an put it in a different container, for example, #sidebar2 ul li ul li. The plugin probably won’t work now because the best you can do to in a plugin is be generic about the container (e.g. div ul li il li / ul.plugin li ul li) because you have no way to know what it will be called.

This isn’t a simple matter. To design CSS deliberately to avoid conflict and allow extension takes some thinking about.

What I want to know is how often has you installed a plugin and found that the CSS doesn’t work as expected? If you build themes do you already try and build it with this in mind? if you think there should be standards then what should those standards be? what is the best way to avoid conflicts? and finally do you think it is it even possible to set standards for something like this? Let me know.