The HTML markup consists of a simple HTML select element that triggers a certain JavaScript function via the onChange hook. The JavaScript function in turn just sets the window.location to the given file and so the browser starts downloading.

<script type="text/javascript">
function download(d) {
        if (d == 'Select document') return;
        window.location = 'http://example.com' + d;
}
</script>
 
<select name="download" onChange="download(this.value)">
<option>Select document</option>
<option value="a_file.pdf">A PDF document</option>
<option value="another_file.pdf">Another PDF document</option>
</select>

This technique can be used to jump to any page you want, e.g. you may use a select box instead of a large menu on your page. It helps you to include information – e.g. a long list – in a page with the compact select dropdown box that can be placed almost everywhere without consuming much space.

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.

While the link tags were introduced in an earlier release of WordPress the meta tag came with 2.5. I’m pretty sure that the latter will cause incompatibilities with a lot of existing themes that have a line like this in their header.php:

<meta name="generator" content="WordPress 2.3.2" />
<!-- leave this for stats please -->

In this post I’d like to share my ideas about removing some clutter from your WordPress installation. Namely:

• RSD and WLW links
• generator tag
• some JavaScript

Removing RSD and WLW links

Getting rid of this stuff is as easy as using the WLW Disabler plugin. After installing and activating the plugin the links are gone. That’s great.

Getting rid of the generator tag

Maybe it’s possible to write a nice plugin that removes this tag too but a quick and dirty hack is to edit the file general-template.php; you can find it in wp-includes. On line 1187 set the variable $gen to an empty string:

// ...
$gen = '';
return apply_filters("get_the_generator_{$type}", // ...

If you come up with a clean solution to this please leave a comment.
Update: I found a nice solution and wrote about it.

Living without JavaScript

Although this isn’t really related to the previous two I’d like to share this one too. I’ve disabled most of the JavaScript that comes with WordPress quite some time ago. And it works great for me: especially the admin pages load a lot faster.

Furthermore I got rid of Prototype that doesn’t play well with SmoothGallery. So, if you’re using the WordPress SmoothGallery plugin this might be something for you.

Just open the file wp-includes/script-loader.php and comment out the line saying:

$this->default_scripts();

That’s it.

Conclusion

If you don’t use Windows Live Writer and the like, using WLW Disabler should be of no harm for you. Disabling some of the JavaScript will give you a performance boost but you’ll lose some of the nifty features at the same time.