We’ve updated the base WordPress theme we use at Soupgiant for WordPress 3.1+ and to make more use of the WordPress API. Along with the standard features you would expect in a WordPress framework, it includes templates for the Theme My Login plugin, custom default code for Formidable / Formidable Pro plugins, custom html output […]
I was asked on Twitter recently if it’s possible to pass WordPress data to JavaScript, wp_localize_script() is the tool to do it with.
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.
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.
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