I disagree strongly: if your notices are printing into form fields (as one example), those values get submitted into the plugin and you will not get the behavior you expected, and the plugin is thus broken. Granted, your plugin isn’t doing this, but the bottom line is that notices are not acceptable in a plugin meant for mainstream use.
To reproduce:
- Turn on PHP notices
- install the plugin on a fresh install of WordPress 3.0.1
- Click tools menu.
Produces this notice:
Notice: Uninitialized string offset: 0 in /path/to/wordpress3/html/wp-content/plugins/custom-field-taxonomies/scb/Forms.php on line 216
This is the line:
$match = @self::$formdata[str_replace( '[]', '', $$i1 )];
It throws a notice because $formdata is not initialized. I would suggest using something like this in that particular block:
if (!empty(self::$formdata))
{
$key = str_replace( '[]', '', $$i1 );
$match = self::$formdata[$key];
if ( is_array( $match ) ) {
$match = $match[$i];
}
}
Also, don’t use the “@” to suppress errors unless you absolutely need to. PHP has certain cases that you simply CAN’T anticipate — e.g. you can’t test whether or not a file is valid PHP before you include it, so that’s a legitimate place to use error-supprssing or a try/catch block.
This is some good code — it’s well-documented and pretty easy to follow and it’s a nice contribution to the WP repo. I was going nuts last night after downloading over 20 different plugins and nearly all of them were developed without notices enabled, so forgive me if my comment came across as over-zealous.
