Blog Surfer

Suggestions For Plugin Standards
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 […]

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

1. 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).
2. Tell us where we’ll find your plugin access. If your plugin options are in the Admin Area under Options, say so.
3. 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.
4. Do not add your plugin access in an unexpected Admin. Area menu item, such as a Plugins submenu item.

Operations Convention:

1. 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.
2. 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.
3. 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.
4. 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 .
   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.
5. 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?
6. 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.
7. 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:

1. 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.
2. 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.

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

1. 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 ….
2. 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.
3. 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.
4. 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.
5. 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).

Tech Sector Braces For next Economic Hit
Keeping track of the economic news is getting nerve-racking - akin to watching a train wreck in slow motion. In the past 24 hours we’ve seen . . . - A Fortune magazine study showing that about 75% of Americans who think we’re either already in a recession or are heading toward one (no surprise to me — we in the media have been scaring people half to death over the economy over the past year. That sentiment has now taken hold among consumers in a self-induced prophecy. The trouble is, about two-thirds of the economy relies on consumer spending. So if Americans pull back financially, we…

WordPress/Automattic Publisher Blog
WordPress Publisher Blog is (going to be) written by various team members at Automattic and their goal is to help all publishers get the most out of WordPress. They will cover features that are often overlooked, highlight plugins that extend WordPress functionality and showcase interesting sites being built with WordPress. They are looking for publishers […]

WordPress Publisher Blog is (going to be) written by various team members at Automattic and their goal is to help all publishers get the most out of WordPress. They will cover features that are often overlooked, highlight plugins that extend WordPress functionality and showcase interesting sites being built with WordPress. They are looking for publishers working on innovative projects using WordPress and would like to field questions from users. From the comment that Raanan left on PressedWords, it would appear that they want to focus on large WordPress installations that are doing lots of custom work and help publishers find the proper resources.

A definite daily read!

Matt Cutts On Securing WP
Matt Cutts has published an article which highlights three different ways to secure your WordPress installation. The first tip involves locking down your Admin directory. Matt configures his .hatccess file so that only his IP address is allowed to access the WP-Admin directory. For the second tip, you should create a blank index.html file to […]

Matt Cutts has published an article which highlights three different ways to secure your WordPress installation. The first tip involves locking down your Admin directory. Matt configures his .hatccess file so that only his IP address is allowed to access the WP-Admin directory. For the second tip, you should create a blank index.html file to place into your wp-content/plugins directory. Not doing so allows your plugin folder to be wide open, giving nosy people an idea as to what plugins you have installed.

Matt’s third and final tip involves subscribing to the official WordPress development blog - http://wordpress.org/development/feed/ As we should all know by now, this is the best way to stay up to date.

Matt also offers a bonus tip where he suggest removing the line of code within your header.php file that publishes your WordPress version.

All of these are excellent tips. But what do you do to secure your WordPress installation?