These are some notes from my experience here at TRU running two different WordPress sites that are enabled as multisite, or more properly, networks of sites. Among the reasons for doing this include wanting to have a platform to offer WordPress blogs to other people, or maybe hundreds of them or in cases where you have themes/plugins that you want to make use of across different sites. It means you are running a single installation of WordPress, so you update one, and they all are updated.
It was not a strict plan to run two multi-sites for the work here at TRU, but now it makes sense. They are actually both running on the same Reclaim Hosting account.
The first one is for our SPLOT tools, Smallest (or Simplest) Possible (or Portable) Learning (or?) Online (or Open) Tools (or Technologies) – set up at http://splot.ca. Brian Lamb gets credit for the name- but a short URL is prime.
I already wrote about some of the recent design updates for the site including the wacky animation on the subtitle. This os primarily the development spot where I am building and testing the tools.
On this multisite, the set up is sites by subdirectory (the easiest way to set up multisite), so all of the sites have URLs like http://splot.ca/writer or http://splot.ca/collector. It’s almost no difference in URL length (e.g. compared to writer.splot.ca).
I actually do not remember why we set up in this mode, but it somewhat makes sense as all of the tools are really iterations of the general site concept, a collection of tools.
On the other hand the TRUbox site https://trubox.ca/ is a collection of many different sites. I’ll take credit for the domain, almost just a castoff word I mentionediin here in December where we discussed setting up a WordPress sandbox site as a place for the Open Learning instructional designers to experiment with blogs and potentially developing a prototype for a group web site. (trubox = … a TRU sandbox).
This site is set up to use subdomains for sites; and now this makes sense for subdomaining where all of the sites will be different, whereas the SPLOT site are all sites of a similar kind (tools). The setup for this looks more complex than it is; the main thing is getting the wildcard zone set up for your DNS (I did the ones for trubox in cpanel). The Codex has this part explained well, and gives some suggestions for how to set up your network in these two different ways.
This site has more of our public facing ones, such as The You Show, all of the sites we are setting up for participants to have their own sites, plus a number of experimental sites for new developing projects. And my own portfolio site (this one). I also made a demo site where you can swap between a set of themes so people can get a better sense of what the themes can do.
I’ve ended up moving versions of the tools developed on SPLOT, such as TRU Collector and making it a version on on TRUBox as the Image Pool. One of the benefits I am finding of doing the development of these projects as WordPress themes means when running on a multisite, I can update all of the sites at once, since it is just editing the theme files.
Okay, that was the introduction. Now for some things I want to remember about these multisites.
- On installing themes, only network activate ones you want to make available to all potential sites. A lot of my SPLOTs are child themes, and it would make no sense to use on a regular blog. Or perhaps we might have a specialized theme for one project that would just be confusing to other users. But you can go into Sites from the Network Tools, edit a site, and enable a non-networked enabled theme for just one site.
- For plugins, only network activate a small number of plugins, the ones you want on every theme. The other plugins are then turned on by site owners as they need them. The ones I have found worth network activating include:
- Akismet– kills spam as much as possible
- Cookies for Comments helps too deal with spam.
- Jetpack gives a lot of extra functionality, stats to all blogs. It can also be activated site wide (or per blog) at the network tools level.
- Limit Login Attempts deals with brute force login attempts.
- Simple Custom CSS this has been useful on helping users with individual blogs where they want to tweak the appearance at a blog level (one person I worked with did not like how Twenty Fourteen capitalized headers); some themes have panels for custom CSS, but many do not. So this makes it available in all themes.
I’ve considered activating FluidVids for WordPress as many themes, while labeled responsive, do not seem to correctly scale embedded videos
- Next are two plugins I have found extremely useful at the Network admin level
- Network Mass Email lets us send emails to all users who are admins on the site, e.g. to send them updates on new themes, plugins, or other news about the site. You can select all users who are Admins, and then toggle off single ones that you amy want to skip.
- NS Cloner may be the most valuable one we have found– it lets use clone an existing site on multisite to a new install. So we can create sites that are like complete templates, and clone not just the theme, but the settings, the plugins, menus, all content. It even updates any internal links that are coded to the source URL.
For example I created a site on TRUbox for an English teacher using the TRU Writer Tool. Once I created one site as a “shell” it was a snap for Brian to clone it to a similar site for another section.
I had hope as the instructional designers here experimented with portfolios in different themes, we could clone some of these, and remove / make generic the content, and have them ready as cloneable sites.
- On TRUbox, where we are hosting an assortment of blogs for a variety of uses, I found the Diamond Site Widget plugin handy so I could have a shortcode that generates a list of all blogs hosted on the site:
- Maybe one of the biggest tripping points with multisite is what happens for sites that want to use embed codes, iframes, or embedded JavaScript. Even if you are an admin on a multisite hosted blog, if you use any of these elements in a post, page, WordPress strips them out. The only users who can use these are Network Admins. This drove me crazy on ds106, as I could put in an embed code, and then someone who was an Admin on a site would edit it, and all the embeds would disappear.
While there are ways people try to end around this, it gets messy. I assume there is some uber security reason for this, but it confounds us because on a single hosted site, an Admin is supreme, they can do anything.
This is where you need to ask people to use WordPress auto embeds. There ware ways to write simple plugins that can add capability for sites WordPress does not support. Or you can find plugins that let people do the same thing with widgets or shortcodes.
- Another thing that tripped me up recently was that the way parent theme for the You Show site is designed, some of my modifications do not work via files in the child theme (long story, but many modern themes have so many disaggregated parts, templates, and libraries in sub directories, and often they do not code the references for these to consider child themes).
So I ended up with two theme files that had to sit in the parent theme. Over the last few months, I have seen my changes wiped out twice. As it turns out, WordPress 3.7 introduced automatic updates for all plugins and themes from the WordPress repository. There are ways to disable the autoupdates, but I just want one theme to not be updated. As it turns out (I cannot locate the source) I was able to do this by editing
style.cssand changing the version number in the header comments and the name of the theme.
This is not at all a comprehensive guide to everything Multisite (I’m always on the learning curve) just some stuff I’ve picked up in the last few months. I highly recommend WordPress Multisite 101 by Mika Epstein and Andrea Rennick, it is a gold resource. And Mika answers tons of questions about multisite in the WordPress forums.
I’d say multisite is a definite choice when you are hosting separate blogs for a number of users. It lets you be a mini WordPress.com, where you choose the themes and plugins to make available. It also makes sense where you might be setting up more than a handful of sites that will make use repeatedly of similar sets of plugins and themes, or where you have sites where you want to give access to a pool of users. If you just have a small number of sites, like 3, 5 that are al different, I might look at separate installs- WordPress is so easy now to update, that doing so in a few sites is not that much a hassle.
Multisite has been beyond valuable in my TRU projects, and its a great example how something that was developed via the open source process as an external set of tools has been folded back in as core.