This post is not written by me but is reproduced, with permission, from a post in the Weblog Tools Collection News Forums. It was written by Weathervane. Since Frank has downloaded 530 plus plugins, and most of his thoughts are well expressed and documented, this post might trigger some good conversation. Please chime in.
As a new WordPress blogger, I wanted to customize my installation, so I began a review of the available plugins. My first installation of WordPress was version 2.3.1. Because this version was a significant change, there was a list of v2.3.1-compatible plugins, of which I downloaded and tried most of them.
Since then, I’ve downloaded 530± plugins (this was what’s left after deleting extensions of commercial services), and tried/tested most of them. Five-hundred± is an incredible number and rivals, I think, Photoshop actions or plugins—and there are lots of those. The WordPress plugins community is impressively prolific.
Whenever I’ve had a problem with a plugin, I’ve added a text file to the plugin’s folder. (If it was a “Fatal Error,” “Warning,” SQL error, etc., I’ve pasted the error in the file.) Then I’ve gone to the author’s site and added a comment telling them about the error, including my version information for WordPress, MySQL, PHP, server, and browser. (I’ve frequently heard back from the author with their help.)
About blog comments for plugin pages: It sure is nice to have lots of comments but there are two issues that make them tedious when they’re about a technical issue: trackbacks, praise.
Maybe praise could be responded to with a thanks and deleted; it just clutters the list when you’re also using the comments for technical support. We have to scan through all that before we find answers. If we can find the answer, we won’t waste your time duplicating a question you’ve answered, and being disappointed when you don’t respond. (How ’bout using a rating plugin so visitors can leave behind evidence of their appreciation.)
Those trackbacks/pingbacks are the most unusable gibberish. “[…] blah blah, yada yada […]” makes no sense to the average person. (Developers/engineers talking amongst each other has been an obstacle for computer users since the microcomputer was popularized by the IBM PC and the Apple.) I understand that authors want traffic to their site but it’s just as easy to do by adding your URL to your comment entry—most comment forms have a “your Web site” input.
Your blog should be as creative as you want it to be when it’s blogging but it needs some standardizing when it’s about technical content, like plugins. A lot of plugin authors are already good about how they prepare their downloads. Establishing a standard, however, is mostly for the user. Below is a short list of recommendations for plugin standards—from a user’s point-of-view.
Naming Conventions
- Do not append your WordPress plugins with “wp-“ or “wp_.” We know it’s for WordPress, it was in your description. Use an evocative name even if it’s only “joe’s-.“ It’s not just you. When ASP was popular, everything (it seemed) was called asp this and asp that (as in asp calendar, asp blog, asp faq, and on and on).
- Tell us where we’ll find your plugin access. If your plugin options are in the Admin Area under Options, say so.
- Don’t create an Admin. Area menu item. Your plugin access has a home in Options or Management or within the other existing Admin. Area menu items.
- Do not add your plugin access in an unexpected Admin. Area menu item, such as a Plugins submenu item.
Operations Convention:
- It would help us if authors would either agree to include update notice capability in their plugins or let us know if it does not have it. This way we can schedule to occasionally visit their site’s plugin page.
- It would be a great help if plugins were always updated and tested in the latest version of WordPress. Too often a plugin is said to be compatible with version 2 or higher but activating it in version 2.3 or higher fails.
- Clearly state any conditions required for your plugin. Some plugins must be in their own folder (even if it’s only a one-page plugin); state if the folder must be named the way you provided it in your download file. Also state whether or not a one-page plugin can be renamed.
- Clearly state—in user language—what we need to do to get your plugin result. Please don’t say, “Place the if (function_exists(‘timeofdeath’)) {timeofdeath(); } function on your page.” We’re not savvy enough to know that what you actually want us to put in the page is <?php if (function_exists(‘timeofdeath’)) {timeofdeath(); } ?>.
And let us know where in our template to insert your function. An instruction such as, “Once it’s activated in WordPress, you can call it from your WordPress template using the yada_yada() function” is unhelpful to the untutored. - If the operation of a plugin is theme-dependant, how will we know that? There seem to be a lot of questions (usually as comments in the plugin’s page) whose answer relates to the blogger’s theme. Can the author can help us identify what needs to be in our theme/template for the plugin to work?
- I’ve begun to learn enough PHP to appreciate the value of “if (function_exists ….” That helps to gracefully fail the function if something’s happened to the function.
- If your plugin requires a Key or API or database file (for your IP-related plugin), as you know the URL to get one could you include the URL? We can go hunting around, say Google, until we find the Google Map API but it would be thoughtful to include that URL.
Structural Conventions:
- Have a unified file set for your plugin. You may have instructions at your plugin page but including a readme file and a link file in your download helps.
- The structure of the download file really helps us identify the nature of your plugin files and how to install them:
* If your plugin is only one file then put it in a subfolder called “plugins.” Everything else should be in the root folder. When your plugin download is uncompressed we’d have a folder with your readme, a URL shortcut, and any screen capture files. Within this folder is a second folder called /plugins containing your plugin file. * If your plugin has multiple files, then instead of /plugins, your folder would have an expressive name. It would help if the name of the subfolder was the same as the name we’re going to see listed in the Admin Area Plugins list.* 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.
- It would help us users if readme files contained a standard set of topics:
- Plugin name (as we’ll see it in the Plugins listing)
- Plugin version
- Plugin URL
- Demo URL(s)
- Author
- Author’s URL
- Author’s email or contact page URL
- WP Version compatibility
- System requirement(s)
- Description
- Features
- Release notes (what you’ve changed since the last version)
- Screen capture description(s) (if you included captures)
- Installation instructions (including structural requirements, if any)
- Configuration options (including where to find the option/management form(s)
- Usage (function parameters, with output examples if practical)
- Donation URL (if you’ve got one)
If these topics are clearly written, there’s no need for a FAQ.
Nice Gestures
- User testing. In business, there’s User Requirements Testing (URT). The people who commissioned the work test the application to ensure it meets the application flow they described in their requirements. There is another testing format that seems to have disappeared from the corporation, let’s call it Real Time Testing (RTT). I wrote about my experience with a plugin I really liked, Thinking It Through: The DG Review Site Plugin. I wish the author had given the plugin to a non-coder, blogger friend to try-out. The plugin’s a real nice idea but ….
- If you include images that you made using software that stores it’s originals in a specific format—like Photoshop, Illustrator—include them so we can customize them for our site design.
- We should maintain a list of existing plugin names, so that authors won’t duplicate plugin names. Microsoft did this a long time ago for various Windows objects/components. It cuts-out confusion.
- Someday, it would be nice if the WordPress would focus on plugins. Say, something that assists in installing them. A Manage or Options submenu, with a browse button to select the file or the folder to be added to /plugins. It would require some thinking but the WordPress people are pretty good thinkers.
- You should be using your plugin on your site, if for no other reason than to show us it works—it gives us courage. If your plugin page says, There’s an example of my plugin running in my sidebar, then have it running there. Occasionally check your plugin page to see that everything is up-to-date and correct.
Admittedly, this must seem ungrateful of me. Authors took the time to code, freely offered their work, and I’m suggesting a little more work. I think some standards would cut-down blogger frustration, requests for help, and give us all more time for blogging (or coding).
Weathervane,
I tend to add the WP prefix to most of my plugins for search engine purposes and also to distinguish on my site what is WordPress related and what is not. I can still see your point though.
As far as documentation: WP Extend already has readme guidelines. If plugin authors would follow those, then we’d all be set.
You have some excellent feedback on your post, especially the bit about comments and trackbacks. I’ve always encouraged users of my plugins to use the WP Support Forums to provide bugs/feedback. A comment section (in my opinion) is not the ideal environment for troubleshooting.
Nothing drives me crazier than uncompressing a package file and having everything explode into the current working directory. Please, please, PLEASE create a top-level directory that contains all the plugin files.
There are some good suggestions there. I’ll add another and take issue with one:
– If a plugin offers a tag to put in a post that gets replaced by some content, it’s best to make that tag an HTML comment so it doesn’t cause an error if the plugin is disabled.
For example, I’ve seen plugins use something like [plugin-tag], which shows up in the post when the plugin is disabled.
would automatically disappear when the plugin is not running. (Hopefully that example doesn’t get stripped out of here as a comment.)– I do have to take issue with the points about where in the menu structure plugin menus should be placed. There is no hard and fast rule other than the menu should show where it makes the most sense. I wouldn’t say that a plugin should never create a new top-level admin menu. It’s possible, although rare, that this could be appropriate for some plugin. The WordPress documentation does a pretty good job of explaining this.
– One other comment. I certainly wouldn’t want plugin standards to be so burdensome that plugin authors would not bother releasing their plugins publicly. For example, I’d much rather have a plugin available and poorly documented than not at all. I’d love to see the WordPress Extend page for plugins have an automatic link to a Codex page where users could help round out the documentation and offer usage tips.
FYI, As I suspected, my example above with the HTML comment doesn’t display even though I wrapped it in a code block. It’s in the source, though. Oh well, you get the idea.
The plugin files should be in a folder of their own, hopefully with a useful name.
Also, the structure of the zip archive should reflect the plugin’s file/folder structure when it is extracted to the /wp-content/plugins folder. This means that a plugin’s ZIP archive should not have explanations in /helloworld and plugin files in /helloworld/helloworld simply because WordPress doesn’t recognize the second level directory in Plugins manager. (This is really a pain because I use a OneClick Installer to upload and decompress the ZIP archive directly in WordPress.) Isn’t it reasonable to have readmes and plugin files in the same-level folder?
Such standards would be very useful. I did list my best-rated WordPress plugins a while ago. Unfortunately, many of them come with internationalization files built-in, which means a whole bunch of extra files most users don’t need. They should really create one archive for English users and another for the localized editions. What are your thoughts on this?
A great post describing the intricacies of creating a WordPress plugins however with naming conventions it is always better to use _ to separate variable and function names rather than using camel cases. I learnt this from Ryan one of core WP devs while trying to integrate one of my plugins into WP core.
Hi Doug, I love your suggestion that plugins use html comment syntax for their tags. I’ve run into droppings from disabled plugins a few times, and it’s very tedious to clean them up.
Nice reading article with some very good ideas! Thanks!
I have two more suggestions.
Secondly, I have quite a few examples installed that do not stick to their own name, consistently. This often shows up as entries in the Admin area that don’t correspond to the plugins’ own name. The most common version of this simplifies the name to the generic case. WP-Tables become Tables. WP-Quotes becomes Quotes. Small-Options becomes Plugins! With a lot of plugins installed, it’s hard to find what you installed, and it ‘hogs’ name-space to use generic names.
Firstly, we should compile a list of delimiter and escape characters used to demarcate filter-targets and action-points by the plugin, and have it available for reference … same idea as having a names-list. In my collection, there are already several ‘walking’ on each other and ‘racing’ to use the same ‘secret’ marks.
I am glad to see Doug Smith’s caution to not stifle the action. This discussion (and recent related posts) are conducted mostly by seasoned experts – and a great service it is to all! I’m sure it is good for WordPress, though, that the plugins game remain attractive for a wide spectrum of participants & interest-bases … even at the expense of some clumsiness. The guidelines will minimize problems.
Outstanding post – thanks Weathervane!
WP hackers probably won’t need this, but since you’re trying to make it as easy as possible for common users, there might be a will for making some kind of self-installer framework (think Firefox XPI…), that would enable users to “consume” the plugins without getting their hands dirty or eventually breaking something.
One more thing is that some plugin authors need to be more careful when using and picking globals because when you have a lot of plugins activated really weird stuff can happen when plugins aren’t “respectful” and start infringing on other plugins or the WordPress core. Globals should be used sparingly and only when necessary, but plugin authors should never use generically named global variables.
Other basic “politeness” rules should include using classes when possible, organizing your code logically, and similar programming best practices.
It’d be great to have a standards for plugins bill enacted by WordPress. If you’re not going to clearly explain your plugin, why are you sharing it with the rest of us?
This was a great read and I agree with the points mentioned. Too often I’ll have a plugin on my site that is poorly documented making it hard to track down its usage.
Another point is that I would like to see more co-development being done with users through the official wordpress.org channel. It would be nice to have the plugins being supported in once place where users can raise concerns as well as suggestions, instead of having to track down the official page which has an inconsistent process. At least official changes/features should be updated on the formal channel.
I know there is a forum like section, but it’s not utilized well enough and needs some improvement to make it more user friendly and functional.
I would also like to add the point that Jeffro raised regarding the uninstall functionality of plugins. This should be something that would be good to incorporate as best practice for plugin creation.
Lastly I agree with Doug’s comment regarding plugins that get disabled yet still show up as [plugin]. They’re functional when active, requiring little code, but annoying when you forget that you’ve deactivated it.
Your proposed set of standards is awesome, but I have one question. How many things that you have proposed in this article would be solved by simply using the WP.ORG Plugin Database?
Let me start by saying first, I love WordPress. It is one of the most forgiving applications I have seen as far as tolerating ‘sub optimal’ code that people occassionaly abuse it with.
I also am extremely grateful to the hard working folks who have already given us an entire worlds of useful plug-ins and are currently laboring away on thousands more.
That said, though, i think this post is one of the more important I have seen regarding the ‘care and feeding’ of WordPress itself.
We can not afford to continually release ‘innovative’ code into the wild without following some rational form of standards.
In particular we must rapidly move toward a rational method of uninstalling. Not every plug-in will work the way we expect it on our own blogs. When it doesn’t, we need to be able to quickly and cleanly uninstall it.
When plug-ins leave snippets behind, especially modification to the database we are setting the stage for an operational disaster in the future. The strength and the weakness of open source is that anyone can extend it. This make sit imperative that before issuing such an exstention one has to make sure it does not leave permanent footprints behind.
And please, as noted, stop calling every plug-in WP this or that … I save all the plug-ins I try/use in folders, neatly organized alphabetically … but now the ‘W’ area is 20 times the size of anything else … if you write for multiple platforms then please adpt the idea of naming things ‘functional name – wp’, ‘functional name – Joomla’, or something along those lines.
Again, I’m grateul, I only want to make a great thing better …thnaks all.
lol
in Germany there is an very old statute: how many toilet papers one man are allowed to use if he is an public servant.
this article sounds like this very old statute.
you made my day
regards
wp goes
I love the list of proposed standards, for the most part. Having a consistent set of guidelines will help bloggers and plugin hackers alike.
To Jon’s point about an automated plugin system, try Pluginstaller
To Aaron’s point about enforcing coding standards & best practices: Not all plugin developers are “programmers”. Many have simply discovered a need for their own site and hacked something together to fill the need… once finished they thought that someone else may have the same need. As long as people don’t do silly things like generically named globals, I wouldn’t get overly concerned with getting commercial-quality code out of your average wp-hacker.
I think adopting a core set of standards for plugins would be a great idea if the development setting was closed. By definition WordPress and its plugins are all open and while developing a set of standards is easy enforcing them would be practically impossible.
It’s also worth picking up on Keith’s point, I make my plugin available as it is useful for others, I accept donations for my work too. It’s been download over 17,000 times now. If each download was $1 that would be a heck of a lot of moeny to inspire me to created a solid plugin with all the features requested and thorough and well laid out supporting documentation.
In reality I’ve probably had donations amounting to $200 in total – just as well I have a day job and don’t expect my plugin to be recognised as commercial-quality code 🙂
I find myself fighting over making things work on my blog, Instead of dealing with writing to blog itself and put more content.
I found that it’s very hard getting substantial support from plugin developers or theme developers. I tried using forums and the wordpress online support on IRC (people there are VERY helpful, but not always you find someone there) to find solutions and support…. My point is that I wish things were clearer in terms of documentation since I waste so much time on this. I hope this post will make developers being more clear about their plugins\templates.
I think plugin author needs *praise comments*. Thats the only way they get a simple *thank you* for their knwledge their spartime .
I hope I can explain my meanings in english.
Theme Designer and plugin authors are working at their spare time- users would like to have their knowlegde – their time – their support – but most of the time – they wouldn’t give theme credit with a simple backlink nor with paypal nor something else.
This is not fair.
WP Theme Designer have to do this and that and something else.
Now someone wishes that wp plugin author have to do this and that and something else.
It sounds *impertinent* for me to use someones knowledge for nothing and to call for this and that.
I love open source and I’ll do my best to give support – but to say: hey plugin author *kill the praise commenst* , kill your trackbacks — because I would not like to search for support is impertinent for me.
Maybe I have to much respect for an open source plugin author, maybe.
This article doesn’t sound for me like a friendly feedback- it sounds like *you have to do this* .
Maybe I read to much between the lines. But some comments here confirm my meanings.
regards
Monika
Related to the threads of Keith & Matt Robinson above, we oughtn’t lose sight that most blogs and websites are transitory affairs and honestly have little long-term priority even to their owners. WordPress benefits from this phenomena & pattern. In honest likelihood, only a single-digit percent of the 2 million blogs on WordPress.com have any ‘sustained intent’ behind or in them.
Because the ‘itech consumer’ user-base of WordPress is so overwhelmingly the majority & is so huge, a tiny incident of recruitment to more-substantial roles with the WordPress enterprise, from the great unseemly pool of light-weight users … is probably a key element of it’s success & future.
Keeping it open & messy-tolerant is probably not just nice to the lesser-coders/dabblers, but important for WordPress’ own interests.
wow, you probably spent ages compiling that list of 500+ plugins and doing all that commentary. thanks for that!
“Praise comments”
I agree with Monica’s #22 input. I think Weathervane did us a fine service summarizing his extensive experience with plugins. But I also think his perspective is influenced by his choice & enjoyment of experimenting with an unusual number of plugins, and *trying to quickly learn about each*. (I do this too, I know.) So … I want to install 5 new plugins this morning before going to work … and now I must wade through pages of “Thank You!” comments to find bits of solid information. But Monica is right – the burden is on we who like studying plugins this way. Bring on the praise-comments! We who plow through hundreds of plugins can expect to wade through 100s of pages of ‘social’ comments. It’s social-ware, after all…
(Sorry Frank – great job! – but a diff on this point. 😉 )
It has been brought up that plugins submitted to the Official WordPress plugin repository solves a fair number of these problems. While that is true, it is also important to remember that users who download the plugins from other sites do not care whether the problems are solved in the plugin repository or not. Raising general awareness and helping plugin authors understand user gripes and coaxing them to adopt a general set of “good idea” guidelines is the best bet. I wish plugins were only distributed from the repository but that is not the case and probably never will be.
I urge everyone to remember that users could care less for perfect code or imitable readme files and nomenclature as long as it serves their purpose and they can get the functionality they are looking for. In that breath, since the subset of plugin developers is a lot smaller and their tech savvy is a lot higher, it should be easier to raise awareness within a smaller group. It is also easier to raise awareness for a few core and important issues than enforcing a whole raft of “guidelines” on a disparate group of developers some of whom could care less.
This is a great post to help plugin developers think about the possibilities and the nags from a prolific users’ perspective.
I definitely agree with Doug at #3 about using the html comment format for plugin tags. With the simple use of regular expressions a plugin author can create quite a complex tag system and negate the need for embedding php calls in theme templates completely.
With regards to limiting comments on a plugins page so support comments can be more easily found. I found this approach to be unworkable so decided to introduce a forum for support and try to keep support comments off the blog. This way you are not trying to fit a support system into something that isn’t designed for that purpose.
Leave comments for what they are, comments and praise (you can never get too much praise….).
@Mark (# 26) – I don’t know … making it (or saying it should be) that you can only use WP.org plugin repository for getting plugins .. isn’t that taking the concept of open source … well, flushing it? I’m sure there is a way for the WP creators to put a bit of code in their installations that pings back to their server saying whether or not XYZ plugin is a ‘registered WP plugin’ or not and enable/disable access accordingly. But that takes the whole community of the internet and the freedom of open source away.
While it is nice if people have a basic set standards – but a 10 page long list of “requirements” is a little much for people who are freely giving their work. If you don’t know how to use it, find it, edit it or customize it .. well, don’t use it. Maybe I’m being the brash one, but it’s not like you have 530+ commercial plugins that you paid for and can’t figure out. It’s open source. *FREE* Just figure it out.
Maybe I’m getting a little annoyed at this for personal reasons … but all the hard work plugin authors put into their stuff really doesn’t need extra complication by having a massive standard. I think this would kill 3/4 of the community factor. Maybe we should have 101 set standards for downloading and using WordPress?
Sorry for the smarminess of my comment … I can understand a TXT document … but that is at the discreation of the person making the plugin – not at the demands of the people downloading (again, for free) a plugin.
*sigh*
we should standardize the post “tags” if the plugin use some special “tag” inside post. Some of them use square brackets ala [gallery:], some of them use other tags, and it is a problem for some plugins, which then work with the content (e.g. formaters). So i would wote for square brackets with the name of the function at the begining as the stated gallery, and also that all formaters should understand this and do not try to rewrite it
I think I need to be a little more clearer on the issue of the WP Plugin Repository. I wouldn’t want to see WordPress plugins developers be forced to use the repository. However, I would like to see at least a set of guidelines for the repository for future plugins. This is the ONLY way WordPress would be able to have any sort of control over the plugin situation. With that being said, this would not stifle plugin development. Nothing says you can’t make your own plugin and do things the old fashioned way and release it on your own website to the public while doing support from your blog. This would still continue. I would just like to see the WP-Plugin Repository become the first in line regarding plugins.
While I see the point the original author is trying to make, if you force me to adhere to your programming standard, then you should be paying me. If I make something for myself and release it to the wider world because I hope someone might be able to use it, for free, then how can you expect to hold me to a rigorous standard? If my code’s not good enough for your standards, then maybe I should stop releasing it. And, if everyone who writes plugins takes the same attitude, no one will write plugins.
I use and develop for WordPress because it’s fun. If you make me adhere to the standards of a professional programmer, then it’s not fun anymore and I’ll stop doing it. I spend long hours being a professional network geek, so I don’t do it for fun anymore. Why do for free what I get paid to do? The same thing applies to programming. If you expect me to program like a professional, I expect you to pay me like a professional. Otherwise, I’ll just keep programming for fun.
And, yes, I have developed plugins for WordPress:
http://www.ryumaou.com/hoffman.....ge_id=1027
http://www.fantasist.net/scroll/?page_id=586
They’re free, and messy, so judge them as you will.
Good Read and nice suggestions. One of mine is to add an option to the plugin to be able to delete it from the Admin screen so i don’t have to go into my server and delete it manually.
Thanks
Frederick – if you use the WordPress “_e();” function, the text displayed will use the built-in WordPress internationalization functionality.
I am in the process of updating my own WordPress (http://wiki.benched42.net/inde.....ifications) plugins to include a complete uninstallation (removal of database entries created by the plugin). After seeing these guidelines, I’ll try to follow them as a part of the updating.
For the developers who are thinking “I do this for FREE, just be grateful with what I have provided!” — I’d just like to say that I would happily pay a buck or two (and have) for any plug-in that followed these standards. It would be a guarantee that I wouldn’t be wasting my time with installing and trying to figure out a FREE but crappy plug-in.
Consider it this way: your time is worth something and so is mine. It’s not fair to make anyone in the WP community a guinea pig for your plug-in unless they agree to it upfront.
Maybe there should be a divisions for plug-ins. You could have:
“Free, but risky, unpredictable and frustrating because of shoddy standards. May explode into directory without warning. !@#$%.”
“Free, made by someone who follows approved standards, available as a gift for the WP community.”
“Shareware, (based on the honor system?); follows approved standards.”
“Buy-ware, requires payment, made by highly experienced developer, follows approved standards, worth every damn penny.”
Just my 2 cents. 😉
(And a heart-felt thank you to all developers who do it right already. You are a blessing to others!)
Good work on going through all those plugins. Your entire process misses a couple of key points in the plugin world:
1) Plugins are mostly written by amateur coders. Many of them write this code once, test it once with whatever version they were running at the time, and they don’t do anything beyond that. There are tons of abandoned projects out there, stuck in version 1.x because the code graduated from school / got a job / lost interest
2) Most people by nature don’t consider the idea of future versions. So “tested in version 2” is correct, but only at the time of publication. Any true list of plugins would require the author to come back from time to time and “touch” the compatiblity and tested with versions. If the author has lost interest or the code is no longer maintained, it will slip to the bottom of the list and show not checked or compatible with current versions.
3) WordPress lacks a true API, so many plugins are in fact minor to major hacks of the code. Without a true API, almost all plugins will break as version move on.
So for me, I would think it would be high time for wordpress (version 3 maybe) to change the entire plugin structure to use a true API that would react the same version to version to version, which in turn would make plugins both more reliable and more durable. Until then, every minor or major upgrade is going to break a percentage of all plugins.
@alex #35 – …exposing my WP-situation ignorance: is there a prospect of an API? Or, is it the house bet the current setup is roughly open-ended? Obvious germane for plugins-standards/stability … Win95 code still mostly runs!
OTOH … WP’s success-formula would not appear to be broken! 😉
@christine in Comment34:
When I did my plugins, I didn’t make them with the intention of releasing them to the public. However, I had several people pester me about one of them until I finally made the code available, with the clear caveat that they worked when I tested them, but I wasn’t Sears or Craftsman (ie. I offered no guarantees) I do my best to support them anyway, because people still use them and seem to enjoy them. However, I have yet to see anyone donate even a thin dime for their use, ever after several hours of support to help them work out problems on their blog.
My point was that I don’t do it for money. I do it for fun. And it would very, very quickly stop being fun if I was doing work at a professional level and not getting paid for it. It’s fine to hold developers to a higher standard, but understand that if you do many non-professionals will simply stop releasing their code. My WordPress customizations would be mine and mine alone. And, I think if everyone took that view, the WordPress community would be a sadder, darker, more lonely place.
The only reason I released my Dale Reckoning plugin was because I rewrote the date and calendaring functions for a non-standard calendar and I thought that others who wanted to do the same might benefit from my work.
But, whatever, it’ll still be fun, for me, to mess around with my code.
@christine #34 – Have you been watching/reading Matt Mullenweg et al finagle a financial model for theme-developers? The process is hard to miss, by design! Well, I imagine the same type process is in the wings for plugins.
But it’s hard to get a theme-market going, and it will be harder yet with plugins. Clearly, though, Matt is looking at the peripheral code-support communities, hoping to find ways those who wish to work it for money, have some kind of shot & chance. He is counting on customers like you who would be pleased to have & use a for-pay market.
Um … a paying market would help enforce & reward plugins standards! 😉
Most plugin users don’t rtfm! You can write pages and pages of instructions but when they see the lengthy manual, they say Wat! I’m supposed to read that! No way!
So they go about installing and playing with it, thinking they can figure it out along the way. When thing breaks, first thing to do, go to the author’s website and shout for help!
Manual? What manual?! You provide the plugin, you must support the plugin (and me the user).
End of rant…
In the process of setting up our site I went through many a plugin. Most were fine, but some were absolutely perplexed by the fact that I had installed the wordpress core files under a subdirectory. I had to manually edit various plugin files to correct the path to the plugins folder. Extremely irritating, and not something I’m thinking the average WP user would be comfortable doing. So, accurately determining the install path, and reflecting that within the installed files would be a great boon.
Good article. Good suggestions. I hope developers will read that and co-op.
Thanks
I sometimes am overwhelmed with how many plugins there are when I am trying to find one specific one which I do not know by name. You have a great list of suggestions for the people at WP to clean up was is a great and forgiving platform for newbies like me to work with.
Those are excelelnt suggestions! I’m also new to WordPress, and if those suggestions were followed it would make things infinitely easier.
Hi Mark,
Thanks a lot for this extremely useful information. I am quite new in wordpress plugin development. When I started trying to find out about how to write a simple wordpress plugin and things like that, I struggled a lot in the beginning to find information, now though things have changed.
I have made a small plugin of my own too, that comes in quite handy for me, it is basically a widget wherein I can put any html code I want to and it will then be accessible to me as a widget and I can place it wherever I want to in my blog.
If I ever release any plugins, that I think can come in useful for others, I will surely keep your suggestions in mind while doing so.
I’m the one who wrote the article y’all are commenting upon. And thanks for compliment—you thought it was worth arguing pro or con. It’s encouraging to see so many people participating.
My suggestion that we get a plugin standard together is the same one I’d make about theme design: Professionalism. Blogging is whatever you want it to be. ‘Should’ the WordPress framework and its dependents be professional?
The only comments here with which I disagree say, in sum: Well, it’s free so you get what you get. No. I’d pay five to ten dollars for a good plugin—and have. There are some plugins that are developed to the point of being applications in their own right (Simpleforum, RS-Discuss, KB-Gradebook, GigPress, and a handful of others), and are worth a few dollars more. The only question is: How would we do that? A desktop application can have a trial timeout. Can we do that with a plugin? Could more of us voluntarily afford five dollars? It just doesn’t seem like much to ask, yet, as one commentor points out, we’re not thinking about doing it. Maybe the problem is that so much is free, we don’t think about a voluntary donation—a donation/payment that would lead to professionalism.
A plugin available via the wordpress.org repository could have, say, a WP Good Housekeeping seal of approval. I don’t know if we can ever shed plugin conflicts but if the plugin runs well standalone and has user-friendly instructions, it’s a Good Housekeeper. If the author met reasonable operating standards, they get to put a certified logo on their plugin page.
Just a thought.
PS: I did visit all your sites; very interesting. And if you’d like a list of all the plugins I tested and the results, you can write me at: imustneedglasses@yahoo.com
@Ted 36: The more open ended something is, the more likely that tool A and tool B won’t work together, or won’t work at the same time, and so on. People download stuff every day only to discover it doesn’t work with this version, hasn’t been updated in months, etc. Giving WordPress an more strict API and requiring things like version checking in code would be a very good start towards making things work for everyone. There is nothing more annoying that going back through 50 or 100 wordpress installs to remove a plugin or have to jury rig some code again because there is no true API to work with.
I enjoyed this article since it delves into more about the information given with plugins rather than how to code for them. I know I’m at fault for the WP naming thing myself, but it had to be since I used some generic names and one that I’m working on is for integration with another on-line service, so WP was the easiest way to give it some distinction and indicate it’s use. I only wish I had thought about how WordPress Extend was going to set up the repository and ZIP files then I would have made the file layout match the repository better.
BUT a nice follow up could be a more modern look at plugin coding and distribution especially since WordPress extend does help with some of the issues mentioned here. WordPress has changed so much in the past year and I see many plugins that could use a minor tweak here or there ( like using wp_enqueue_script() instead of mucking up *_head() ).. of course it looks like the upcoming 2.5 is already making me look at some serious redevelopment efforts. Looks like this will be a “working” summer.
I agree with this post 100%. It blows my mind sometimes, how many plugins there are, that simply just don’t have ANY README type file at all.. I don’t know what goes thru some of these peoples minds sometimes. I mean, if I see a plugin that doesn’t have a README file, or doesn’t explain to me in some way how to install the plugin, and get it to work, then I don’t even download the plugin at all, I don’t even waste my time with it. don’t plugin authors want people to download their plugins? if they didn’t they wouldn’t be posting them to begin with. Personally, I think its just a lack of communication and soft skills that some plugin authors have.
anyeay, I disagree with one part. every plugin I have ever seen, gets put in domain.com/wp-content/plugins I’ve yet to see a plugin that doesn’t get put there, so that part alone should be a standard.
I do agree about where plugin authors make us “hunt down” where in the admin area to find their admin panel. Sometimes its in Options, I’ve seen it in plugins before, I’ve seen it in presentation before. I mean, I agree they should standardize that so that authors are forced to put it in a certain place, so we as users aren’t looking for a needle in a haystack, esp when you got 500 plugins installed, I immagine its hard to find stuff with 500 of ’em. I have 20 and have a hard enough time.. =P
one final pet pieve I have about WP. I downright HATE it when plugins modify my dashboard, so authors, PLEASE don’t do that, don’t mess with the dashboard please. and for wordpress blog software itself, it does me no good to say “version blabla is available, go here to download” that annoys me to no end. I KNOW where wordpress is located. If your gonna tell us a new version is available, work it into wordpress to automatically upgrade. subversion SUCKS, and upgrading via unzipping and FTP’ing has messy results, and due to security reasons in this day and age for some strange reason, most webhosts don’t allow SSH access anymore, so we CAN’T run subversion even if we wanted to.. so my suggestion? do what forum software does and work it into the admin area to download and install right from the admin area. I know it can be done because Simple Machines does it just using simple PHP, so I know wordpress can figure out a way. That would help so much its not even funny. even if you had to type in your FTP info and all that, that would help SO many of us.
So taking all of these suggestions into mind, where do we go from here? How do we all move onto the next step as far as turning these guidelines into something of a reality? Do we create a codex page for these? How do we figure out which guidelines meet the criteria of actually being added to the guideline page and which ones don’t need to be added? Should this be official or unofficial guidelines?
Personally, I think unofficial is the way to go.
Another suggestion would be that plugins keep the same name. I just downloaded a plugin that started as xyz.php and is now wp-xyz.php.
If users aren’t paying attention, they’ll wind up with two versions of the same plugin on their sites. And it’s more than likely that they’ll assume that the plugin is updated and activated once they’ve uploaded it to their servers. But in reality, the old version will be the active plugin and the newer version is not activated yet.