Working with Multiple Themes Outside of the WordPress Installation Directory

Published Monday, July 7, 2008 @ 6:58 am • 0 Responses

[ ~{*}~ ] As you may observe, the WordPress installation that powers Perishable Press is located in a subdirectory named press. This configuration was intentional, as I wanted to have the option to easily install and maintain multiple versions of WordPress in variously named subdirectories. As much as I enjoy this flexibility, many would argue the SEO-related benefits of installing WordPress in your site’s root directory, or at least making it appear that way by using WordPress’ easily customizable “Blog Address” options setting.

For example, say you have WordPress installed in a subdirectory called “gibbonz”, but you want your blog’s home page to exist at http://your-domain.tld/ and not http://your-domain.tld/gibbonz, as would be the case by default. To make this happen, you have several choices, including this method, which I summarize here, assuming the “gibbonz” scenario outlined in the preceding discussion:

  1. In the WordPress Settings panel, leave the “WordPress address” unchanged (i.e., http://your-domain.tld/gibbonz) and set the “Blog address” to your site root (i.e., http://your-domain.tld).
  2. Copy the index.php and htaccess files from your WordPress (gibbonz) directory into the root directory.
  3. Edit the index.php file to reflect the location of your WordPress installation by changing the line “require('./wp-blog-header.php');” to “require('./gibbonz/wp-blog-header.php');
  4. In the WP Admin area, ensure that your permalink structure does not include the gibbonz subdirectory. You will need to ensure that your htaccess rules are updated with the correct permalink directives.

Upon implementation, your blog will be served as if it were installed in the root directory. The subdirectory will not be shown in any permalink URL, nor will it be referred to anywhere else in the site. Thus, if you aren’t planning on using the subdirectory to serve unique content, this method is all you need to ensure that plugins, scripts, and themes function properly in the root URL. For sites with multiple themes (such as this one), users will experience seamless theme presentation throughout the site, including the site root.

On the other hand, for bloggers with subdirectory installations of WordPress that wish to continue using the subdirectory as a unique destination, the previous method of displaying your blog from the site root is not an option. Let’s use this site as an example. The site root is located at http://perishablepress.com/ and WordPress is installed at http://perishablepress.com/press/. I use this to my advantage by serving uniquely purposed content on each of these different pages. For the current theme, the root page features the latest article, while the subdirectory page is an archive view of the first 11 posts. As one who maintains multiple WordPress themes, I find this configuration to provide maximum flexibility.

Along with this flexibility, however, comes an important caveat: maintaining your WordPress-subdirectory as a unique, web-accessible destination means that sites with multiple themes will need to implement their own root-page theme synchronization technique. In other words, with your multiple-theme blog in a web-accessible subdirectory, you need to code your root page in such a way as to ensure seamless theme presentation. For example, say Fonzi wants to use your happenin’ “Jukebox” theme. He clicks the link, skins the site, and begins to surf. During his travels through your site, Fonzi inevitably finds himself navigating to your home page (you know, the one that serves WordPress-generated content even though WordPress is installed in a subdirectory). “Uh-oh,” now the Fonz is like, totally confused because your home page is coded to display your site’s default theme instead of the cool Jukebox theme that Fonzi wants. Fonzi sees the Jukebox theme everywhere on your site except the home page, because it hasn’t yet been configured to accommodate user-defined themes.

The easiest solution in this case would be to code your root page in such a way as to check the user’s theme preference and then deliver the correct version of index.php accordingly. To do this, you don’t need to include an entire copy of each available theme (e.g., header, index, sidebar, footer) for each corresponding if statement, but rather call each theme’s index.php file directly, using PHP’s include_once(); function. If that doesn’t make sense now, don’t worry — it will after the next few examples, where I illustrate the concept by sharing the root-page theme-switching code used here at Perishable Press.

When placed in the web-accessible root (home page) for Perishable Press, the following PHP code delivers the appropriate index.php file according to the active theme selected by the current user (tested in WordPress 2.0, 2.3, and 2.5):

// display user-defined themes outside of WP directory
<?php require_once("./press/wp-blog-header.php"); 
if (!empty($_COOKIE["wptheme".COOKIEHASH])) { 
	$press_theme = $_COOKIE["wptheme".COOKIEHASH]; 
} elseif (empty($_COOKIE["wptheme".COOKIEHASH])) { 
	$press_theme = get_current_theme(); 
}
if     ( $press_theme == "Apathy"      ): include_once( "./press/wp-content/themes/apathy/index.php"      );
elseif ( $press_theme == "Bananaz"     ): include_once( "./press/wp-content/themes/bananaz/index.php"     );
elseif ( $press_theme == "Casket"      ): include_once( "./press/wp-content/themes/casket/index.php"      );
elseif ( $press_theme == "DOS_FX"      ): include_once( "./press/wp-content/themes/dosfx/index.php"       );
elseif ( $press_theme == "Entropy"     ): include_once( "./press/wp-content/themes/entropy/index.php"     );
elseif ( $press_theme == "Finished"    ): include_once( "./press/wp-content/themes/finished/index.php"    );
elseif ( $press_theme == "Garbage"     ): include_once( "./press/wp-content/themes/garbage/index.php"     );
elseif ( $press_theme == "Headline"    ): include_once( "./press/wp-content/themes/headline/index.php"    );
elseif ( $press_theme == "Information" ): include_once( "./press/wp-content/themes/information/index.php" );
elseif ( $press_theme == "Jupiter"     ): include_once( "./press/wp-content/themes/jupiter/index.php"     );
elseif ( $press_theme == "Killer"      ): include_once( "./press/wp-content/themes/killer/index.php"      );
elseif ( $press_theme == "Lithium"     ): include_once( "./press/wp-content/themes/lithium/index.php"     );
elseif ( $press_theme == "minimalist"  ): include_once( "./press/wp-content/themes/minimalist/index.php"  );
elseif ( $press_theme == "Naked"       ): include_once( "./press/wp-content/themes/naked/index.php"       );
elseif ( $press_theme == "Optimized"   ): include_once( "./press/wp-content/themes/optimized/index.php"   );
elseif ( $press_theme == "Perishable"  ): include_once( "./press/wp-content/themes/perishable/index.php"  );
else                                    : include_once( "./press/wp-content/themes/default/index.php"     );
endif; ?>

Thus, if a user prefers my Lithium theme, and decides to “skin” the site with it, the previous code will ensure that the root URL — the site’s home page ” stays consistent and serves the correct theme. To determine each user’s theme preference, this method checks for a cookie set by the ubiquitous Theme Switcher plugin, which is generally installed on multiple-theme sites. If a cookie is present, the PHP variable $press_theme assumes its value, which is the name of the user’s preferred theme. If no cookie is present, the script sets the $press_theme variable to the site’s current default theme, which is determined via the inherent WordPress function, get_current_theme();. For example, to echo your blog’s current default theme from outside of the WordPress core directory, this works for WordPress 2.0, 2.3, 2.5, and probably several others:

<?php require_once("./press/wp-blog-header.php"); ?>
<?php $current_theme = get_current_theme(); ?>
<h1><?php echo $current_theme; ?></h1>

In either case, once the theme variable has been set to the proper theme, the remainder of the script simply tests the value against each of the site’s currently available themes. When a match is found, the script includes the correct index.php file for the chosen theme. If no theme preference is determined, the script resorts to the site’s default theme.

The beauty of this method is its simplicity. Just copy and paste the script into your site’s root index.php file and enjoy the results 1. Of course, you will also need to edit the require path in the first line to reflect the correct location of the wp-blog-header.php in your subdirectory-installation of WordPress. You will also want to change the theme names in the first column, and the theme directories in the second column, such that they match your own configuration. As always, “test, test, test!”

While this method is extremely easy, it takes advantage of the flexibility inherent in segregated root and blog URLs. Let’s say you wanted to display the home.php file for several of your custom themes, maybe to spice up the layout or optimize for search engines or something. No problem. Using the code above, instead of including the index.php file for any selected themes, simply include your home.php file instead. You could use this strategy to include virtually any page for any given theme — single.php, archive.php, welcome.phpwhatevah!

Footnotes

1 Note that when using this method from a locally installed version of WordPress (i.e., the installation directory in somewhere within localhost), you will need to create and use cookies that are distinct from the default theme-switcher cookies. Doing this is easy. Open your theme-switcher.php and place the following immediately before the first instance of $redirect = get_settings('home'):

setcookie("indextheme" . COOKIEHASH,
	stripslashes($_GET["wptheme"]),
        $expire,
        '/'
);

Additionally, the main script will need to be modified to reflect the alternate cookie information:

<?php require_once("./press/wp-blog-header.php"); 
if (!empty($_COOKIE["indextheme".COOKIEHASH])) {
	$press_theme = $_COOKIE["indextheme".COOKIEHASH];
} elseif (empty($_COOKIE["indextheme".COOKIEHASH])) {
	$press_theme = get_current_theme();
} 
.
.
.
?>


Share your thoughts..

TopRead official comment policy

Contact Perishable Press

  • Contact Jeff via form

Search Perishable Press

About Perishable Press

Perishable Press is the virtual playground of Jeff Starr — visionary, founder and lead developer of Monzilla Media, a small web and graphic design company in the lush desert oasis of Moses Lake, Washington. Perishable Press features articles and tutorials on many aspects of digital design..

Read more..

Perishable on Twitter

automation is great: i've got photoshop batch processing 300+ images while FTP is simultaneously uploading them to the server..

Perishable on Tumblr

Tons of Firewalls

Tuesday, 7 October 2008, 1:45 am

Recently overheard on conservative talk radio (instructing listeners how to obtain a free promotional video from their new website):

“This website has tons and tons of firewalls, so you have to use your real email address to download the video..”

The Quiet Search Revolution

Monday, 6 October 2008, 12:15 pm

Just a thought.. As awesome as Google is these days, it would suck if they ended up owning the entire search-engine business. When they get to the point where all competition is impossible (due to their sheer size, financial resources, media influence, etc.), how many alternate search engines will have the resources for continuous improvement and top-quality search results? When this happens, we will have no choice but to do exactly what Google tells us to do.

As deeply ingrained as it is for everyone to instinctively and unthinkingly turn to Google for their search activity, it is time to leave a few alternate search tabs open for as much use as possible. Instead of using Google just because that’s what you always do, try your search on MSN, Yahoo, Ask, or any of the other independent search engines instead. Sharing traffic with other search engines is a nice, quiet way to keep the competitive spirit alive and well in the search-engine business.

Disappearing WordPress Posts

Wednesday, 1 October 2008, 7:50 pm

Today I experienced difficulties while trying to publish or even save new posts in WordPress. I would compose the post as usual, add all of the keywords, tags, meta tags, and so on, but as soon as I clicked the “Publish” or “Save” button, the post would just disappear from existence.

The weird thing is that during the drafting process, WordPress’ default auto-save feature showed that the post had been saved at expected intervals. Unfortunately, after trying to publish several different posts, WordPress showed absolutely no record of the posts ever being created. They simply vanished into thin air.

Fortunately, a little investigation revealed the culprit. If you should find yourself dealing with this same issue, here are some different things that you should try. First, re-upload fresh copies of your entire WordPress installation. I don’t know why exactly, but apparently various files can either go stale or completely disappear from the server. Overwriting or writing fresh files may do the trick.

If that doesn’t work, check your WordPress database for errors. In my case, a little investigation revealed that something had caused a couple of fatal errors in the wp_posts table. Fortunately, checking and repairing the table solved the issue.

Tumblr Battles

Wednesday, 1 October 2008, 5:30 pm

Please excuse the duplicate Tumbr posts.. seems there is no way to ping Tumblr to refresh/rebuild the RSS feed according to changes in post content. So, to resolve the issue I have discussed now like two or three times regarding paragraph elements and proper feed formatting, I have no choice but to repost a majority of my text posts.

This is necessary for the proper import and display of my Tumblr feed into WordPress. Currently, there are five items displayed at once, each styled according to proper inclusion of paragraph tags. Thus, whenever the Tumblr feed “forgets” to enclose single-paragraph posts with the proper tags, the result is an unstyled post entry displayed on my site.

Assuming that makes sense, you will please excuse my dust while I repost a few older entries in an attempt to reconstruct (the hard way) a properly formatted Tumblr feed.

More Optimization Measures

Wednesday, 1 October 2008, 5:27 pm

Another important step in improving the performance of my recent redesign involves the optimization of both CSS and JavaScript content. During development there were around 15 server requests for these two types of files, 10 JavaScript files and 5 CSS files. This was okay for my own use, but would not work for production purposes.

Optimizing these file types involves consolidation, compression, and caching. Consolidation of 10 JavaScript files into three is huge improvement. Now I deliver one JS file for the functionality of the site, one for Mint, and another for Analytics. Likewise for the stylesheets; after consolidation, a single stylesheet is delivered to all modern browsers. There are two additional stylesheets as well, but they are targeted at IE6 and mobile browsers and will not load elsewhere.

Once the files were consolidated as much as possible, it was time to optimize or “crunch” them. Using the sexy Flumpcakes CSS optimizer, I was able to reduce my stylesheets by around 25%. Likewise for JavaScript, I used xtreeme.com’s optimizer to shave an additional 20% off the size of my JS content.

Finally, once I had consolidated and compressed my JS and CSS files as much as possible, I wanted to further my optimization efforts by ensuring that these files were cached by the browser. By setting far-future Expires headers for everything but the statistical files, my site gains an additional performance boost by eliminating the need to reload preexisting content.

Read more on Tumblr..

Subscribe to Comments Recent Dialogue

  • Adam Singer: Thanks for this. You're right, if it isn't broken, don't fix it. I was about to update my permalinks and install a plugin to redire...
  • Marilyn: It looks great on my browser! I wish I had that much creativity in my head! It's gorgeous!...
  • Randy: "Too girly?" It looks like a great design. Define "too girly!"...
  • Christopher Ross: .htaccess based redirects are wonderful. I'm always baffled by web professionals who don't take the time to learn more about them....
  • federico: Hi Jeff... tnx so much...it worked perfectly... c u Federico...
  • Cooltad: The skin seems (mostly) fine in my expert opinion. Your one of the few people able to make a design with a transparent table and a b...
  • Neal: The free Intro to Linux book is a great place to start http://www.ischool.utexas.edu/mirrors/LDP/LDP/intro-linux/html/index.html ...
  • Louis: @Jeff: Your “Archives” page is slick, although I would expect a cleaner implementation from such a vehement advoc...
  • Jeremy: Well I think that you may be over-critical, I don't see a darn thing wrong with it - I like it a lot!...
  • Jeff Starr: Alright, this is exactly the kind of information I was hoping to get. Lots of great ideas and recommendations here. I will be reading...

Read more recent comments..