Part 3: Can WordPress Multisite Help You?

In the previous two parts, we introduced you to new concepts in WordPress Multisite that a single site installation does not have. In this final part, we will guide you toward an understanding of when using WordPress Multisite is the best option, and help you determine if it is the right fit for your organization.

So far, I have provided a lot of information on what WordPress Multisite is and the benefits it contains, but what about the practical application of it? You came here wondering if WordPress Multisite might be the solution for you. This section will outline key things to consider when deciding whether or not to use WordPress Multisite.

When You Should Use WordPress Multisite

There are some instances when it makes perfect sense to use WordPress Multisite. Multisite typically works best when the sites on the network all run along a similar theme or have a limited differential in terms of required functionality. Let’s take a look at a few prime candidates.

Multilingual Network

If your site needs to be translated into additional languages, using WordPress Multisite can quickly get you there. The theme and plugins will likely be the same across all sites with only content differences. Each language would be its own subsite that could be configured with access only for the translators who need to be able to touch the content. This is a strategy we utilize here at WebDevStudios (WDS) with a subdirectory install that winds up looking like:

• English – http://acmecorp.com/en
• Spanish – http://acmecorp.com/es
• French – http://acmecorp.com/fr

Blog Network

WordPress can be a high-performance blogging engine. If your use case is to put together a group of basic blogs, WordPress Multisite in the answer. WordPress.com is a prime example of a blog network. Users have a limited set of functionality available to them and several different themes they can choose from. The variety in look and feel of sites hosted by WordPress.com is impressive.

While we are on the topic of WordPress.com’s service, I want to mention some of its staggering statistics. 

• 21.7 BILLION page views per month
• 79.2 million new blog posts each month
• ~74 million sites hosted (this number is questionable as the full number is not released)

Wow! That is a huge amount of data and traffic for one WordPress installation, and guess what? Nobody has ever reached the limit of Multisite’s capabilities. As long as you have the hardware to support it, there is theoretically no limit to the number of sites you can host on a WordPress Multisite install. WordPress.com proves that.

Multi-Department Corporate Sites

Earlier, I shared a multi-department Acme Corp example. It is a common scenario we see at WDS, wherein companies desire to have departmental websites in which each department controls its own content and has some limited ability to manage the look and feel from a common style guide.

One such client we worked with tapped WordPress Multisite for their intranet. It was not even a public facing site! It was one of the more creative uses I have come across and included:

• A couple dozen departmental sites
• Centralized file management for forms, memos, etc.
• HR/personnel management
• Employees’ corner
• Monthly corporate newsletter
• Classified similar to Craigslist
• Employee blogs

When You Should NOT Use WordPress Multisite

As awesome as WordPress Multisite is, there are also times when it does not make sense to use. Take a look at these examples.

Each Site Needs Significant Custom Development Work and/or Plugins

When you have a group of sites, even within the same organization, that need a significant amount of custom development work, WordPress Multisite may not be a good idea. One tiny mistake in the code for another site can have implications across the entire network—possibly crashing it.

Even when the “significant custom development” is nothing more than installing a bunch of plugins, WordPress Multisite can cause issues. Some plugins alter network operations in ways that only a super admin should be altering. Ideally, the network will have a well-defined purpose that limits the amount of customizations to functionality that will be needed per site.

A great example of this scenario is my own personal site https://ben.lobaugh.net. Being a developer, I have the ability to go in and tweak the code on my site as often as needed. I know that I can bring down the site if I screw up, but it will not affect anyone else. I am also not worried about ensuring the code I write is safe for a Multisite environment.

Each Site Needs Its Own IP Address

WordPress Multisite aims to make running a network of sites as simple and painless as possible. When you have a network of sites that all need their own IP addresses, a lot of complexity is introduced. It is absolutely possible to make it work, but it will require significant time investment in development operations to configure the servers properly. For a small network with a few sites, this may not be a big deal; but when you get into dozens and thousands of sites, it is simply not feasible.

Ecommerce

Ecommerce is a sticky wicket with WordPress. In recent years, ecommerce support on WordPress has improved dramatically for single site installs; however, Multisite ecommerce support has largely been neglected. This is in part due to the overhead needed to run a proper ecommerce site. There are additional database tables, relationships, and processing power needed to run an ecommerce site, in addition to things such as payment systems and SSL certificate requirements. Though it is possible to run WordPress Multisite in this manner, it requires a significant investment in time and architectural knowledge that usually makes it more time and cost-effective to use multiple separate WordPress single site installations.

You made it!

Congratulations on getting through all three parts in this series on WordPress Multisite. Multisite is a powerful tool that I hope you will be able to utilize. WDS loves WordPress Multisite, and we are always interested to see how others are using it. We would love it if you dropped us a line in the comments. If you would like to chat about your implementation or work with us on your project, head over to the contact page.

Looking forward to hearing about your projects!

Photo by rawpixel.com on Unsplash

The post What Is WordPress Multisite and How Can It Help You? (Part 3) appeared first on WebDevStudios.

The design comps used a web-safe non-system font called Canaro, which we set as the default in our sans-serif font stack. The client provided a Chinese language font that was unfortunately not web-safe, so we set Hiragino Sans GB and Microsoft YaHei as the other two fonts in the stack.

Hiragino is a beautiful font and the latest version of OSX El Capitan does some pretty nifty stuff with it when you’re typing in Japanese (so I hear). However, we started to get bug reports that the Russian language site was looking a little odd in Safari on OS X.

At first, I thought it was an issue with the dynamic text resizing in El Capitan, since I hadn’t duplicated the issue in Yosemite. However, some major cache clearing ensued and I was finally able to duplicate it and quickly figured out (thanks to Google) that while Hiragino Sans includes Cyrillic characters, they are kerned at the width of the kanji blocks.

Kerning is the word for the space between letters. If you know anything about typography, you might say that kerning is the word for the relationship between letters (don’t even get me started on ligatures).

Changing the kerning via CSS wasn’t really an appropriate solution for this issue; it’s resource intensive and is better used sparingly on larger text like headlines.

Adding more fonts via @font-face wasn’t really ideal either, especially considering the difficulties we’d had with custom fonts in non-Latin alphabets not being web-safe.

So I changed the font stack.

.body {
     font-family: "Canaro", sans-serif;
}

.body.ru {
     font-family: Helvetica, Arial, sans-serif;
}

.body.cn {
     font-family: "Hiragino Sans GB", "Microsoft YaHei", sans-serif;
}

Now we’re relying on system fonts for Russian and Chinese and the custom font for any language using a Latin character. In this instance we’re using WPML for internationalization, but the two other WordPress plugins I’ve used for this also set the country code as the body class, so it makes styling for specific languages easier.

That’s it! One weird edge case I may not encounter again, but it’s worth a mention if you’re developing sites with multilingual content that uses characters other than the Latin alphabet. Windows and OSX offer system fonts that display beautifully in any alphabet, but you may need to define different fonts based on the language being used.

The post Internationalization: Beautiful Typography in any Language appeared first on WebDevStudios.