Website Tech

Tag: WP plugin development

  • Checking if Plugins Pass Basic “Good Programming” Test

    On http://wordpress.org/ideas/topic/plugins-and-theme-repository-thorough-bug-update-and-security-review/ there is discussion about adding to WordPress a “system of testing and making sure that plugins and themes work, are up to date (no plugins over a year old, say) and are bulletproof secure. The plugin and theme repository should demand that every single plugin and theme should be rigorously reviewed and screened for security.”

    My suggestions for a Partial solution, that could Easily be checked for by the Plugin repository and by the WordPress Core:

    1) /wp-admin/network/plugins.php shows if are using the latest version of each plugin. But it doesn’t indicate the Date of the latest version, or if the latest version date is a long time ago. Adding the date would be extremely easy.

    2) On plugins.php display the version of WordPress the plugin was written for, just like the plugin repository page does. Display the user rating from the repository, for your installed version of WordPress with your installed version of the plugin.

    3) Plugin repository could list results of installing the plugin in a default configuration, with full error reporting on, testing for a) syntax errors, b) obsolete function calls, c) database errors, d) direct MySQL calls (e.g. bypassing WordPress security and roles), e) multi-site initialization errors (e.g. are tables created for the plugin when create a site? Does the plugin put data in wp_options or in wp_SITEID_options? ).

    The test site would be restored to default state after each plugin test. The test would be run at each plugin update posted to the repository. This sounds like something that could be easily automated.

    Not a guaranteed security or quality test, but a good check of the basics.

    @Ipstenu replied “We have yet to manage to do it in a way that didn’t net a bajillion false positives that we have to look at them all manually anyway :/ ”

    Nope. Purely objective reports.

    Have PHP error logging set to maximum, use software to count each category of error, report the findings. Already includes obsolete WordPress functions, obsolete PHP functions, syntax errors, mismatched variable types, uninitialized variables, and more.

    Look for occurrences of the most common MySQL function calls (instead of WordPress database functions), report the number.

    Get a list of tables after adding a new site (single MySQL query). Software subtract the list of tables started with. Report the difference (or maybe a little more secure, the # tables).

    Another test: Any plugin using wp_ instead of the actual table prefix, isn’t programmed well.

    Similarly, # rows in [tableprefix]_options before and after (shouldn’t change, plugins should use [tableprefix]_[siteid]_options).

    Show the whole list in a new tab in the Repository, for each version, and watch plugin authors clean up their act!

  • Check Plugins are Multi-Site Compatible

    As a WordPress Multi-Site administrator, make sure a plugin works with multi-site before installing it. Plugin authors should state if the plugin works with multi-site.

    Testing is best done on a separate installation of WordPress (the one good reason for having multiple WordPress installations), so if there is a problem it doesn’t affect your production site.

    Plugin Authors: If you have tested the plugin with multi-site, then claim the feature in your marketing. I would not use a plugin that doesn’t say it works on multi-site, since even though I am technically qualified to do that testing it is much too much work to have to do.

    Does the plugin always request the table prefix from WP? (One immediate clue is a plugin that uses ‘wp_’, the default, even though that isn’t what you used when installing WordPress; then WordPress appends the site ID to that prefix for all user data.)

    Does the plugin always request the folder locations from WP? In multi-site mode, each site gets a unique file upload location.

    Does each site of the multi-site get its own set of plugin tables, for plugin options and for user data?

    When a plugin is activated on an existing site, are tables checked for, and created if needed? (Or do thousands of error messages about missing tables clutter the error log? Yuck!)

    When the plugin is network activated, and a new site is created, does the plugin activation work? Is there a reminder in administration panels, to configure the plugin for the site?

    When a site is deleted, does the plugin deactivation work?

    If the plugin creates file (for example, a podcast creating plugin would have the podcast episodes listed in a .xml file), does each site get a separate result file, or separate collection of files?

    Improper multi-site use would assume the table prefix, or assume the folder locations, or use one set of plugin tables for all users, or use one folder for all user’s media files, or allow unauthorized people to include in their post or results some information from other users, or allow unauthorized people to modify someone else’s tables or files.

    Plugin Author: State in the installation instructions or FAQ whether the plugin is safe to use in a multi-site installation. State whether the plugin can be network activated or must be activated on each site. State in the change log when multi-site features are added or fixed.