This is a followup to my previous post on adding scripts only to the WordPress pages that need them. Please read that first, or this might not make much sense…

To cleanup the dynamically generated head section even more, you can disable the styles associated with scripts that aren’t loaded on every page.

The easy way to do this is very similar to what I talked about last time – add this code to your functions.php file (or custom-functions.php if your theme supports it):

The plugin I’m working on is WPNG Calendar, which displays a stream of events from Google Calendar. I want to show it, in this case, only on the site’s About Us page. I’ve already deregistered the scripts associated with WPNG Calendar on most pages, so now I want to hide the styles on the same pages (why load them if you don’t need them?).

So now you’ll do the same thing as in the previous post with a twist:

  1. View the source for a page on your site and find the CSS stylesheet links associated with the plugin that you’ve already deregistered on most pages;
  2. Open up the file that calls that stylesheet – in my case I’m looking at wpng-calendar.php.
  3. Search for wp_enqueue_style within the PHP file and find the handle for the stylesheet you want to deregister. The handle is the first element in parentheses after the wp_enqueue_style element – in the snippet above they are thickbox and style.

A Problem That You Can Fix Yourself!

What happens if you can’t find a ‘wp_enqueue_style’ in your PHP file? This is unfortunate; it means that the plugin creator isn’t making easy for you. Using wp_enqueue_script and wp_enqueue_style makes it simple to work with the tools WordPress has built-in, but there’s a way around this.

Look for a link that calls a stylesheet – something like this:

Comment that line out and add your own wp_enqueue_style line, replacing the handle with the stylesheet name and editing the source link as needed (refer to this reference for parameters, I didn’t include what I wasn’t sure about):

Now you have a stylesheet being loaded in the way WP intended it to happen and you have a handle (‘style’) that you can plug into the deregister function.

Do the same thing for any other stylesheets being called, add those handles to the function and you should be good to go. This is the final version of my function:

You can see that I’m hiding the styles from the head section on all but three pages:

I hope this is helpful – please let me know if you find these two posts on restricting plugin loading useful and understandable.

The WordPress site I’m working on now (WP 2.9.1) has gotten very slow – in part I’m sure that’s because of the large number of plugins that are now loading every single time. I looked around for a bit to find some resources online for restricting plugin loading by page, so I’ll summarize what I did here (not being a PHP coder I didn’t understand at first how to accomplish it, but this is the less-techie version).

This is the snippet of code that got me started, from Justin Tadlock’s blog post; it will disable Contact Form 7’s loading site-wide:

add_action( 'wp_print_scripts', 'my_deregister_javascript', 100 );
function my_deregister_javascript() {
wp_deregister_script( 'contact-form-7' );
}

This snippet goes in the functions.php file (or custom-functions.php if your theme uses that).

But if you want Contact Form 7 to show up only on your contact page, how do you allow it to do that? By using an if statement, like one of the commentors on Justin’s post suggested:

add_action( 'wp_print_scripts', 'my_deregister_javascript', 100 );
function my_deregister_javascript() {
if ( !is_page('Contact') ) {
wp_deregister_script( 'contact-form-7' );
}
}

This snippet will disable Contact Form 7’s loading on all pages except Contact. So now, how to use this for other scripts?

Disabling Scripts on a Page-by-Page Basis

First thing you’ll need to do is find out what’s loading that shouldn’t be. View the source code for one of your site’s pages and make a list of which plugins are loading that aren’t needed site-wide. For example, in my site I’m using WPNG Calendar plugin on my Events page but nowhere else, so that’s one I need to restrict.

Next, you need to find the handle for each script. To do this, you’ll need to open up the main PHP file for each plugin that’s on your list. I did this for WPNG Calendar by going into the plugins folder in FTP and opening wpng-calendar.php in an editor, then doing a search for wp_enqueue_script, which loads JavaScripts into generated pages in WordPress. The handle is the first element in parentheses in each wp_enqueue_script line.

wp_enqueue_script(‘wpng-calendar‘, get_bloginfo(‘wpurl’) . ‘/wp-content/plugins/wpng-calendar/js/functions.js’, array(‘date-js’), ‘0.85’);

In this case the handle is ‘wpng-calendar’ but I found that there were a number of other scripts being called into play by wp_enqueue_script – date-js, jquery-js, thickbox-js and wiky-js. I’ll also add those to my deregister function so that they’re only called on the Events page.

Potential Problems

As Justin Tadlock stated – not all plugins use the wp_enqueue method for calling scripts (and styles too) because they’re not aware of it. Using wp_enqueue makes it really easy to use WordPress’ built-in tools for managing scripts and styles. If you can’t find that in the particular plugin you want to hide, I’m not sure how you should proceed yet – I’ve encountered the same problem and don’t have a fix now.

Forward…

This is the snippet I added to functions.php to restrict loading of the calendar on all pages except Events:

add_action( 'wp_print_scripts', 'my_deregister_javascript', 100 );
if ( !is_page('Events') ) {
wp_deregister_script( 'wpng-calendar' );
wp_deregister_script( 'date-js' );
wp_deregister_script( 'thickbox-js' );
wp_deregister_script( 'jquery-js' );
wp_deregister_script( 'wiky-js' );
}
}

This worked perfectly. And you can do the same with any other plugin scripts that aren’t needed site-wide. If you need to show the plugin on multiple pages, change the if line to this:

if ( !is_page(array(2,'events','about-us')) ) {

Check out the conditional tags page in the WordPress Codex for more information on selecting multiple pages.

sidebarwidgetApplying CSS styles to a particular widget in WordPress (2.9.1 is my current version at the time of this posting) is surprisingly easy.

I’m using the WPNG Calendar widget to pull in events from Google Calendar. I wanted to apply special styling to it that matches the styling of one other key widget on the home page, so here’s what I did. I found the id for the calendar widget (wpng-calendar) and then went into my CSS file to add this:

div#wpng-calendar {
position: relative;
width: 301px;
padding: 0 0 5px 0;
margin: 12px auto 10px;
background: url(../images/teaser.png) no-repeat bottom left;
}
div#wpng-calendar h3 {
position: relative;
top: 0;
margin: 0;
padding: 0.5em 0 0 1em;
background: url(../images/teaser-top.jpg) no-repeat top left;
}
div#wpng-cal-widget-events {
padding: 0.5em 1em 1em 1.2em;
}
div#wpng-cal-widget-events ul {
margin: 0 1em 0 1.5em;
list-style-type: disc;
}
div#wpng-cal-widget-events ul li {
padding: 0 0 0.2em 0;
line-height: 1.4em;
font-size: 13px;
}

Easy, and I now have a nicely-styled events listing in my sidebar.

I just started a free Google Sites website that I’m going to use as a company wiki. I’ve been thinking about doing this for awhile and now that I have a part time intern, figured it would be a good time to get some of the documents and procedures in a place where I can share them easily (only with people I allow access, of course).

Today was super-busy.

I dreamed about being cold for several hours before finally waking up (with a 40-lb Springer spaniel laying on us) to find that it really was cold – the pilot light in the furnace had gone out and it was 58 F when we checked the temperature. Thankfully it doesn’t seem like it needs a repair, it’s fine tonight.

After breakfast, I finished up a proposal, packed up my project folders and notebook and went to spin class. I really like the group ride classes better than the ones that don’t even pretend to have anything to do with actual road riding. The class was full, but happily I got there early enough to get a pass (people without passes get booted).

Then I had three meetings in a row – first with a current client to discuss the SEO research my partner has completed; the second with a prospective client for whom we’re submitting a joint proposal; and the third for a current web design client who’s decided he wants his logo updated.

I went by the bookstore to look around for some inspiration about the logo, but didn’t really find what I was looking for. No problem; I’ll do some more Googling on the topic tomorrow. But I’m kind of glad today is over, work-wise…

After a good solid week of headaches related to Win 7, system restore, and corrupted USB port drivers, after completing a repair install yesterday all seems to be back to normal.

This morning when I turned on the machine I found four restore points – the test one I made late last night and three others that were created during the repair install. So… it seems like the problems are gone… Fingers still crossed, but for now, okay.