<?php require('./wp-blog-header.php'); ?>

on the top of your page, you still have access to all the WordPress functions and code library.  Which is great, because if your Navigation is built through a WP page hierarchy, you can still have access to it, and any changes in the backend will be reflected on your orphaned page.

All is right with the world.

Or so it seems.  The underlying problem with this is when you include the all encompassing “wp-blog-header.php” it tries to put this page in the framework.  And the way the framework operates when permalinks are in place is completely database driven.  So if an actual file exists in a sub directory, but it isn’t a part of the WordPress hierarchy, WordPress sends out a 404 header.  Now there’s a conflict, because the browser is getting a 404 header, but a file actually exists in the location.  Firefox and some versions of IE interpret this fine, but some versions of IE don’t.  And more importantly, neither does Googlebot… which means you’re page isn’t going to get indexed.

Fortunately, there’s a relatively easy way to get around this.  Basically, don’t include wp-blog-header.  I can already hear the virtual screams:

But but but!  I want the tags!  Isn’t that the whole point?! *anger* *confusion* *lamentations*

It’s definitely the point.  And luckily, there’s a relatively easy way to accomplish this.  Basically, we just want to include the specific functions of WordPress without making this specific page or pages part of the CMS.  So don’t include wp-blog-header.php at the top.  Use this instead:

<?php
       require('./wp-config.php');
       $wp->init();
       $wp->parse_request();
       $wp->query_posts();
       $wp->register_globals();
?>

This will only pull the specific framework functions without putting the page as a part of the whole.  In essence, WordPress won’t look for the corresponding page or post with “/your-sub-directory/”, but you’ll still be able to use all of the functions such as wp_head().

And you thought nonsensical 404’s couldn’t be fun… for shame.

$(document).ready(function() {
   $("a").click(function() {
     alert("Hello world!");
   });
 });

The problem arises when a different system grabs the $ variable.  All of the sudden you have multiple $ variables being used as objects from multiple libraries, resulting in the error console message “$ is not a function”.

Fortunately there is a pretty easy way of fixing this in the form of jQuery.noConflict.  Running this function gives control of the $ variable back to whichever library first implemented it.  This will help to ensure that jQuery won’t conflict with other instances of the $ object in other libraries.

But please note, in doing this, you are re-assigning the variable so you will only be able to access jQuery commands using the ‘jQuery’ variable (which has just replaced ‘$’).  So our above code example would look something like this:

jQuery.noConflict();
jQuery(document).ready(function() {
   jQuery("a").click(function() {
     alert("Hello world!");
   });
 });

It doesn’t seem to be a very common problem and only occurs when multiple instances of the object crop up, but that’s easy to do in WordPress when multiple plugins begin conflicting with each other.   Follow the link for the  full jQuery documentation on jQuery.noConflict