Weblogtoolscollection News » Wordpress News

Suggestions For Plugin Standards

  • Topic started 6 years ago
  • 3 posts so far
  • Latest reply from XRF

  1. weathervane

    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 <?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.
    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).

    Posted: 6 years #
  2. I'm also thankful for the work that the developers do. But I'd also like to ask that plugin developers stick with one name for their updates - especially when they instruct us to just overwrite the old files.

    I've had plugins that start as wp-xyz.php, then become wp_xyz.php or wp_x-y-z.php. Users wind up with two versions of the same plugin with the same name.

    I'd also like to see index.php or index.html files in the folders. Or is that not a good thing?

    Posted: 6 years #
  3. XRF

    Blogging Pro also talks about the issue of plugin standards here here

    Check it out at: http://www.bloggingpro.com/archives/2008/01/15/wordpress-plugin-standards/


    Posted: 6 years #

RSS feed for this thread

This topic has been closed to new replies.

Back to top

0.124 - 12 queries