Most of the time this is a good thing because it’ll be easier for your users to implement the plugin on their sites. It gets really ugly if the theme loads certain scripts by default which are incompatible with the scripts needed by your plugin. And users concerned about performance – e.g. using Yahoo! YSlow or Google’s PageSpeed – may want to include only things that are really needed on a particular page.

This post presents a solution using custom fields that allows the user to tell the plugin when to include scripts and styles. Doing it this way helps the user to manage your plugin because of it’s added flexibility without hacking the code. Newbies trying to circumvent a certain incompatibility and power users tuning their sites to maximum performance both will love this feature of your plugin.

Prerequisites

In my experience custom fields aren’t very popular and not everybody using WordPress knows what one could do with them. Regarding this lack of knowledge you should make it as easy as possible to use your plugin even if somebody doesn’t know what custom fields are. By default your plugin shouldn’t use custom fields altogether but just load scripts and styles on each and every page.

Your plugin should work out of the box without any further modification. Just loading necessary JavaScript and CSS on every page seems to be a good default. So, just testing whether a certain custom field is set to a predefined value isn’t the way to go. In case your plugin hasn’t got a configuration page in the admin area yet it’s time to add one now. Allow the user to enable the usage of custom fields there.

Once a user tells your plugin to use custom fields you shouldn’t load the scripts and styles like you did before but only on posts/pages with a certain custom field. In case your plugin needs some configuration options allow the user to use the value of the custom field to set these options.

Bringing it all together

Above, I outlined some of my ideas on how things should work. You can do it different here and there but in the end I guess it would be great if all plugin/theme developers would use more or less the same strategy when it comes to using custom fields; this would help the users using your plugin if they’re familiar with custom fields from another plugin.

The code needed is pretty simple: just check whether the user wants to use the custom fields and then evaluate whether the current post/page has got one. It may look like this:

// right at the beginning of an action like:
// wp_print_scripts, wp_head or wp_footer 
if (get_option('my_plugin_use_cf') == true) {
  global $post;
  $meta = get_post_meta($post->ID, 'my_custom_field', true);
  if (empty($meta)) return;
}
 
// use wp_enqueue_script and wp_enqueue_style here...

In case the user wants to use the custom fields but the current post/page hasn’t got one the scripts and styles won’t be loaded. If the user may add options to the custom field you should parse them here.

Conclusion

From a plugin/theme developer’s perspective it’s straight forward allowing your users to use custom fields controlling how your plugin behaves. As a user it’s great having the possibility to use custom fields in case one wants to control how scripts and styles get included. Not only adds this extra flexibility to a plugin but makes updating a snap: you don’t have to remember how and where you changed the code.

I haven’t covered the issue that using custom fields may get tricky if your plugin is called directly – rather during the loop – maybe via an iFrame. If you do things like that it’s likely that you know how to access the database yourself or bootstrap WordPress to use $wpdb anyway.