Theming With Wordpress Multisite

I was recently asked to do some WordPress development on a set of two sub-sites that would nest under a main site. It seemed like a good chance to try out WordPress multi-site. However, as per everything, there are gotchas that you find out when actually implementing a new feature.

Why use Multisite?

There are a lot of good reasons why not to use WordPress Multisite, mainly if the functionality is going to change a lot between sites, or there aren’t many common users. However, these sites were a good opportunity to do it: shared domain (though you can map to different domains if need be), a custom theme that would only change in colours any minor imagery between the sites (though this wasn’t quite as simple as I assumed), and a combination of people working on only one site, or needing access across the board.

Setting it all up

The Multisite installation is well documented and relatively painless (once you’ve enabled wp-config.php to allow for multisite, you can even make new sites from the WordPress Dashboard!) . The main difference is that when logging in, you become the Super Administrator able to switch between sites and able to activate plugins and themes (see below).

However, there are some annoying quirks of the system probably stemming from the functionality originally being a plug-in.

Uploads don’t Share Across Sites

This is probably to be expected, but I mention it anyway. While it does mean in some cases you may have to upload a media asset several times, it also means that administrators on each site can delete files without fear of it breaking one of the other sites.

Custom Upload Paths? Er, No.

I was ecstatic when I found out earlier this year how to get uploads out of that obviously ‘made with wordpress’ wp-content file folder. (Yes, I get excited about strange things). However, if you try and do anything like this with Multisite, you’ll just end up with errors, as far as I can tell. (The files will save, but the media library won’t accept them). So, you’re stuck with paths looking like /wp-content/uploads/site-1/IMAGE.JPG. It’s not ideal for people who’d rather play down the WP aspect or try and safeguard file hacking by moving the folders out of the obvious places, but I guess that this is one of the teething issues for a website becoming a CMS.

Mapping Sub-sites: All Or Nothing

Similarly, the WP folder rewrites are pernickety. As far as I can tell, you can’t have a non-Wordpress top level along with non-WP subfolders.
I was hoping to have the multisite work as subdomains, but couldn’t due to hosting constraints. So, it came down to using subfolders. They actually work reasonably well (you just need to set them in network settings). However, my original plan to have two subfolder sites and a top level static page were quickly scuttled. In short: if you want a top level site and subfolder ones, make them all run as WP sites, even if the top level one is a single page.

Plugins and Themes Don’t Have to Be Network Activated to Be Available

Another weird thing to get your head around is the Network Activation settings. From what I can see, Multisite strips administrators of individual sites of the ability to add themes and plugins. However, from the Sites Settings as a super-administrator, you can allow these to be specifically available to a site. This is different from Network activate which makes a plugin/theme available to all sites.
Another interesting point is that you don’t have to activate a parent theme when you activate a child one (useful if you’re worried about people messing with the parent theme and causing all end of trouble).

Theming

Child Theme or Roll Your Own?

In the past, I was inclined to use my own defaults when it came to theming. However, now, I’m more inclined to use child themes, particularly when it comes to WordPress. This is because WordPress changes incredibly quickly, so I assume that their themes should be more likely to make the most of new developments. (Also, to be honest, WordPress has always had great themes, far more so than Drupal, which could often be overkill).

Cancelling things out in functions.php

However, there are some gotchas involved with using these themes. One of the nefarious ones I noticed was the “powered by wordpress” footer appearing as an overlay on the page. These things are easily rectified in functions.php however.

No Grandchildren Allowed

Unfortunately, you can’t have a child theme of a child theme (which you can do in Drupal and is incredibly useful). So, if you want ways to get around this, you have one of three options:

1. Duplicate themes and activate for each site only. This would be the most painless way, but obviously involves duplication, particularly if you’re making global changes to how the theme appears on both sites.
2. Use the theme options for each site. To be honest, this is probably the official WordPress way, but I would rather not do it, as it means that your admins can change the colours (thanks to another annoying WP default, anyone who you need permission to be able to change widgets also gets permission to change themes and theme options). In this situation the sites were also highly designed down to the colours, so it made sense to be able to hard code the options.
3. Use body classes to target specific sites. I preferred the idea in this case of being able to target different sites with CSS overrides and thereby use the single theme as a master theme. However, perhaps unsurprisingly, there is nothing in the body tags that lets you target a specific site on a multi-install. I ended up adding in a class through functions.php. function add_slug_body_class( $classes ) {
   global $post;
   if ( isset( $post ) ) {
   $classes[] = $post->post_type . ‘-‘ . $post->post_name;
   }
   return $classes;
   }
   add_filter( ‘body_class’, ‘add_slug_body_class’ );

On hindsight, I’d probably change this to be ‘site-1’ etc as this is less likely to change than the site title (which is what I hacked it from at present).

Other thoughts

The risk of editing themes and other administrator power. As I mentioned earlier, it’s irritating that by default editing widgets also means that you can edit the theme. However, I’ve been helped out by an unexpected benefit: the hosting we use has strict settings when it comes to editing files on the server in that it has to be manually unlocked.

All up, it is pretty cool to see a single theme used in different ways on a multi-install site. And it’s handy to be able to tell clients that they can delete whatever they want on their subsite without worry of ruining everyone else’s. Still, I think it still is early days in regards to WordPress Multisite, and would be happy to see them both improve their upload file system, and allow grandchild themes.