good_plugins_habits.txt

good_plugins_habits.txt
Draft article I began in August 2008, forgotten since. Still a few good things. A few others I don't like anymore :)







- make several smaller files instead of everything in one file, so things get included only if needed.
Example:
if (is_admin()) require(dirname(__FILE__).'/plugin_adminfunctions.php');
It also makes sense to split a big file into various smaller files when they cover different fields of action: one file for functions regarding comments, one for the query stuffs

- stick to one syntax : function naming, indenting, line breaking or not before {} blocks, etc...
It's probably better to adopt WordPress' coding standards:
function no_camel_case( $param ) {
	// one tab indenting
	...
}

- Give your functions a unique name ! I'm amazed at how many plugins I see that are using functions with names such as ValidateEmail() or CheckInfo(). This is the best thing to do if you want your plugin to collide with another.

- no short tag. <?php and no <?

- gracefully degradable. Always have in mind : will everything break if my plugin is disabled or if something goes wrong ?
	- <!--sometoken--> or <dostuff>hello</dostuff> instead of [dostuff]hello[dostuff]
	- enclose function calls inside "if function_exists()" blocks when you can

- Warn about db impact. Is DB modified ? Any core table modified ? Any new table added ? In a typical usage, how many queries will your plugin add to my blog's front page ?
Avoid by all means modifying a core table.

- Try to minimize db impact. I often see plugins that update_option() first off, on init. Poking the DB should be done only if there is a real need for it. Think of it like if you had to pay for each single query to the DB.

- Take it easy with the options. It's always tempting to add a gazillion of options in wp_options and make your plugin the most flexible ever, but don't add 20 entries in this table when you can store all your options in one array and one entry.
Bad :
add_option('myplugin_option1', 20);
add_option('myplugin_option2', 'hello');
add_option('myplugin_option3', FALSE);
add_option('myplugin_option4', 'posts');
Good :
add_option('my_plugin', array('option1'=>20, 'option2'=>'hello, 'option3'=>false, 'option4'=>'posts'));
Cleaner and faster in the database, easier in case of uninstall.


- Explain uninstallation procedure. One should be able to try a plugin and remove it in the minute without any side effect on their blog. User must feel that if something goes wrong or if they don't like it, they will be able to remove the plugin and have their WP install as if nothing happened (no db modification, no useless files or databse entries left etc...)

- Group hooks (add_action and add_filter) all together rather than spread all over the file. This may be a very personal choice, but I've found that it makes things a lot easier when you try to figure out what's going on, and what is the typical "flow" of events.

- Comment source
As a plugin coder myself, I often download and try plugins for the sake of curiosity, just wondering how this or that part is written, or thinking "I'd do this like that" and checking how the author handled it (remember, "there's more than one way to do it")
. Comment it.

- test on a windows install, on a almost-deprecated install, on a cutting edge install. Windows installs are picky about backslash handling in paths, and about some Linux concepts such as file locking. Develop with Linux in mind, but make sure it works on Win32 and even IIS if possible.

- check for hardcoded things: make sure you never use 'wp_table', make sure the plugin's path is always guessed by the script itself. Don't assume that the user will decompress it with a proper folder structure.

- test on a non-default WP install : have a test blog set up with table names not prefixed with "wp_", and with Wordpress core files in a subdirectory not named /wordpress. This is a great way to quicky make sure you didn't hard code any table name or path.

- think about your target user. Most wordpress users are just users. Typical user is no techie, PHP ignorant, does not know what's a virtual path or a physical path, has never heard of phpmyadmin to create a table, is reluctant to edit their theme or plugin because of fear of unrecoverably breaking things.