I ran into a very interesting problem today. WordPress is great as a CMS, but sometimes for special functionality on specific pages you just need to go outside of the shell, but the great thing is, you can still use the framework right? By including
<?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.
[...] at the post by the nice folks at Adrogen (a Denver website design company) and quickly implement the solution they offer. They suggest using the following 5 lines of code to include WordPress instead of just including [...]
This SOOOOO fixed the issue I was stressing about ALLL weekend. Thank You!!!!!!!!!!
No problem! Glad it could help!
thanks a lot! saves my ass!
This worked for me. Thanks!
I’m surprised more people haven’t written about this problem. This is the only place I found that mentions it.
Pete, many thanks, this post helped me out! I’m thinking the same as Josh – amazed I haven’t seen this anywhere else. Was debugging why Googlebot was throwing off 404 errors – wp_blog_header was the reason. Regards, Jason
Hey Jason,
Just glad it could help out. Its a really weird bug that hopefully will be corrected with subsequent releases, but if not, at least there’s this
Brilliant! Thanks.
yes! spent about 30 minutes on this problem … you saved me another 3 hours.
thanks so much.