A few weeks ago I wrote a post in which I adapted an idea from a zOompf article to delay the loading of print stylesheets until after a web page has fully rendered. I’ve decided to convert the code from the original post into a plugin and add it to the WordPress plugin directory.
Recently I stumbled across an article detailing browser performance with the CSS print media type. In most recent browsers the print stylesheet held up rendering.
The article suggested a solution, which I decided to automate for WordPress.
Mullenweg believes that, because WordPress is released under the GPLv2 license, all themes and plugins developed for WordPress must also be released under the same license. Pearson disagrees. I believe that Mullenweg is wrong. WordPress themes can operate on other blogging platforms with minimal changes.
One of the standout problems when using plugins with WordPress MS is when they define a constant for the plugin’s url as the script starts executing.
In Part 1 we introduced the wp_register_script and wp_enqueue_script functions developed to avoid JavaScript conflicts.
In this section we’ll deal with a more complicated example. We’ll also take what we’ve learnt about including JavaScript and apply it to our CSS.
Problems arise when your theme or plugin both use the same JavaScript library or if Prototype and jQuery are both used on the same site.
Two of the most important WordPress functions are often ignored by WordPress theme and plugin developers. Introducing: wp_register_script and wp_enqueue_script.
Of all the Wordpress functions, I think wp_register_script, wp_register_style, wp_enqueue_script, and, wp_enqueue_style are the most elegant.
Since threaded comments were enabled in Wordpress 2.7, most themes check if the visitor is browsing either a page or a post and adds the JavaScript required for threaded comments if they are.
I prefer a slight variation