4 Things I Learned While Building My First WordPress Multisite

Posted on: May 16, 2018 Leave a Comment

Earlier this year with the help of a co-worker, I built my first WordPress multisite.

Our plan was for the primary site to have a custom theme including custom post types, sortable archives and lots of custom metaboxes to create inputs for the different fields to be filled in with each CPT (custom post type). To begin, we spent some time reading the documentation from WordPress, and a handful of other posts to get a feel for what we needed to do to get started. Luckily WordPress has great documentation, and WPMU DEV has a couple of holy grail articles with pretty much everything you need to know to launch a multisite network: WordPress Multisite Masterclass and The Ultimate Guide to WordPress Multisite.

Next, we sat down and decided what kind of setup we would like to use for this project. We settled on a domain-based network in which on-demand sites use subdomains – meaning we have one domain (e.g. “cooks-central.com”), and when you create each new site on the network it gets a subdomain on that main domain (for instance, “bubies-favorites.cooks-central.com”).

Overall, with the help of the guides, the installation was pretty straightforward.

In a short amount of time we had our multisite network up and running. Once we completed the setup, the serious work of building out the functionality and styling the templates could begin. Here we went a bit sideways, which really became apparent when it came time to clone the theme to the next site on the network.

We started by creating our own plugin so that templates could be shared across all the sites. We did this because we couldn’t structure our files the way we normally would with the templates and styles all neatly tucked into one theme. All of our templates were moved out of the theme and into our plugin. The goal was to eventually have several themes to choose from with minimal tweaking and styling to be done. But I’m getting ahead of myself.

In spite of all the preparation ahead of time, this is where my list of things I learned begins:

• Choose your vars carefully!

  Assuming you are already using a CSS preprocessor like Sass or something else that allows you to create variables for oft-used CSS values, avoid naming conventions like $roosterRed or $buttonBlue. Once you’ve cloned the theme, it can be tough to match up the new color palette with the base theme, and it will look odd if your IDE’s linter is displaying $blogBlue as a light lavender from the new color palette. We wound up refactoring and simplifying our variables to names like $buttonColor, $gradientPrimary, $secondaryTextColor etc.

• Enqueuing your custom page templates from a plugin is the best way to go.

  In the early stages of development I began building templates as I normally would for a single website. First I made the obvious mistake of naming a template by it’s page name, but this led to another question. At that point we did not have templates in the plugin, and I was trying to get my mind around how we would have the same custom pages for all themes, but they weren’t templates yet. So as you may have guessed by now, this is when we wisely moved all templates to the plugin and found a great snippet from WP Explorer: Add Page Templates to WordPress with a Plugin. Now, when a new site is created, it has all the custom templates included – a user just needs to pick the page template when creating the page.

• Hardcoding is the devil and you shouldn’t do it.

  

  Credit: Wellcome Library, London.

  Really, this should be a no brainer. You don’t want subsequent users to have to hunt around theme files trying to replace an icon or figure out where that $roosterRed is coming from. This goes for all content management websites really, but in the case of a multisite it is especially painful. There are ways around hardcoding – for example, we used the WordPress customizer to give users a place to upload media like hero and background images that can change with every child site.

• It’s OK if your base styles are complex.

  Keep the adjustable stuff simple though. We ended up creating a highly intricate base design for the first site – the first clone of that site became the starting point. There are a handful of items in our Sass that would need to be changed or adjusted for each new site, so for the sake of simplicity we created a Sass file that contained all of those variable elements in one place so the rest of the Sass files would be untouched.

Conclusion

Multisites expand the possibilities of what WordPress can do. In our case, we were able to build a reusable website product for companies in an industry we know very well – all under the umbrella of one multisite we can maintain and improve, allowing us to deliver greater value to our clients. With a bit of planning and prep (and some improvisation along the way, for sure), it was a great learning experience. Do you have lessons learned from building multisites? Let us know in the comment section below.

— Elaine Thomas – Developer, 11 Online