Customising a standard theme for many sites

This is a presentation I made at the New York Times to the WordPress Big Media and Enterprise meetup in New York.

You can watch the video over on the WordPress.com VIP blog.

The slides:

I’ve written up my fairly copious speaker’s notes below, but the best thing to do will be to watch the video (coming soon) and flick through the slide deck.

Our client approached us for a WordPress multisite which could host 30 or so of their titles, using one standardised theme and one standardised set of functionality. 30+ sites with one theme.

Our solution for them is based in the WordPress theme customiser, as well as using WordPress’ widget areas to handle the more complex layouts.

These solutions can be applied for other organisations with a large number of websites. You can use these techniques to differentiate between your sites, you can reduce maintenance, and you can keep editorial teams happy. 

I’m going to talk through three of the areas where we allow the editorial teams control within the standardised theme to take ownership of their site:

  • Colour
  • Typography
  • Layout

The first element I want to talk about is colour. 

We started off with the idea that we could have the user pick a limited set of colours to define a palette. We’d then use colour calculations to extrapolate complimentary colours, to lighten and darken, so we had a much wider array of colours to assign to page elements.

This became unwieldy. We found ourselves adding more and more colour options to avoid clashes: dark on dark, or red on green. The more explicit colour choices we added to try to get around these issues, the more we seemed to complicate things. Our solution was to define two colour palettes in the customiser, then we split the page into three areas:

  • The header, with one palette
  • The body has a palette
  • Lastly the footer can be assigned a palette

So each of the three sections can use either Palette A or B. (We started off calling them “light” and “dark”, but realised we sometimes wanted “neon” and “greyscale”, so we lost the limiting semantics.)

We’re still doing some colour calculations, for example in the rollovers for the “see more”, “more photos”, boxes.

We’ve got about 12 areas you can choose a colour for:

  • Background
  • Heading
  • Sub Heading
  • Body Font
  • Meta Font
  • Link
  • Link Hover
  • Highlight
  • (etc)

One approach with customising CSS, header images, etc, is to have a STYLE block inserted into the head of the document which overrides the static CSS in style.css. We don’t take this route.

Instead we’re using LESS. You could use SASS, as WordPress Core does now, and I think we backed the wrong horse when we started with LESS… but it all amounts to the same thing, which is CSS pre-processing, which allows us to inject variables into the CSS for things like logo paths, colour values, and so forth. Simpler. Cleaner. Enables colour calculations, which we still use to some extent.

Let’s talk typography. There are a number of font services available: Typekit, fonts.com. We went with Google Fonts API and created a custom control for the WordPress customiser which shows multiple values in one control. The control picks up new fonts with variants and weights from the Google Fonts API. 

We don’t set individual font sizes for different elements, instead we set a base font size, and everything else is a multiplier. (More LESS.)

Now let’s talk about layout. 

We started considering a much more freeform approach: editorial teams would be able to draw widget areas across the page, and then drag widgets into these. We would then work out how to make that layout display responsively across the usual breakpoints for mobile, desktop and tablet. !We eventually decided this was adding too much flexibility. Instead we’ve gone with a grid of widget areas which can be used or not used. Flexibility within guiding rails. You can do what you want within a set of known possibilities. Use or don’t use widget areas to control how many columns of information you want on your homepage. Because everything is a known grid of these widget areas, we can handle the breakpoints for responsive design really well.

Looking at this page, it’s constructed of lots of little loops of posts. Essentially a WP Query builder, and display controller for posts within a widget.

The sections are controlled from the widget. You select your criteria to get the post, or events or reviews. 

Which gives us this. Large image, two small images, ten listed stories as bullets. 
Let’s talk category archives. !One client request was that we were able to differentiate categories by layout. Some categories will tend to have nice images you want to highlight, and others will be best shown as simple lists. !We built a customiser control which allows you to choose how to display each category archive separately. Similar to the query widget display: choose a layout with large images, small images or no images, choose whether you want the author, comments and dates to show. 

I hope these notes made some sense, but it will probably be easier to watch the video!

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.