Slides from the April 2015 WordPress Philly Meetup presentation on multisite, including considerations for setup, plugin selection and activation, theme modifications and network database cleanup.
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Â
Multisite: Lessons I Learned the Hard Way
1. Multisite:
Lessons I Learned the Hard Way
Susan Walker
susanwrotethis@gmail.com
www.linkedin.com/in/susanwrotethis
2. What is Multisite?
Multisite is a WordPress feature which allows users to create a
network of sites on a single WordPress installation.
Available since WordPress version 3.0, Multisite is a
continuation of WPMU or WordPress Multiuser project.
-- from wpbeginner.com
10. The Magic Dust
WordPress stores a unique ID and
path for each blog in wp_blogs. As
the multisite loads, WP uses this info
to know which tables to pull content
and settings from.
11. The Multisite Admin
The multisite administrator is called
the Super Admin. Instead of a site
dashboard and admin menu, there
will be a network dashboard and
admin menu.
12.
13.
14.
15. Multisite Terminology
In multisite, an individual site is
referred to as a blog. The terms âsiteâ
and ânetworkâ normally refer to the
whole multisite.
16. Multisite Terminology
Sites can run as subdomainsâŚ
⢠www.example.edu
⢠math.example.edu
⢠history.example.edu
⢠finearts.example.edu
17. Multisite Terminology
⌠or as subdirectories:
⢠www.example.edu
⢠www.example.edu/math
⢠www.example.edu/history
⢠www.example.edu/finearts
19. Who Uses Multisite?
Multisite is a good fit if you have web
sites with commonalities:
⢠site purpose
⢠content ownership
⢠design (themes)
⢠functionality (plugins)
20. Who Uses Multisite?
Examples:
⢠a professional groupâs blogs
⢠a chain with location-specific sites
⢠an arts organizationâs events
⢠university department sites
21. Who Uses Multisite?
Itâs useful if you have a number of
related sites, especially when you
have limited resources with which to
manage them.
32. II. Creating Sites
You canât use slugs twice. That is,
www.example.edu/biology canât be
both a page on the root site and a site
on its own.
33. III. Managing Plugins
Youâll need to:
⢠see if a plugin is multisite-friendly
⢠understand network activation
⢠avoid plugin overload
⢠consider activation access
34. III. Managing Plugins
Youâll need to:
⢠see if a plugin is multisite-friendly
⢠understand network activation
⢠avoid plugin overload
⢠consider activation access
35. III. Managing Plugins
Some plugins are built just for
multisite, some arenât but work on it
fine, and others ⌠not so much.
36. III. Managing Plugins
How can you tell?
⢠check the support forums
⢠ask the developer
⢠look in the uninstall file
39. III. Managing Plugins
Youâll need to:
⢠see if a plugin is multisite-friendly
⢠understand network activation
⢠avoid plugin overload
⢠consider activation access
42. III. Managing Plugins
Youâll need to:
⢠see if a plugin is multisite-friendly
⢠understand network activation
⢠avoid plugin overload
⢠consider activation access
43. III. Managing Plugins
Youâll need to:
⢠see if a plugin is multisite-friendly
⢠understand network activation
⢠avoid plugin overload
⢠consider activation access
47. IV. Modifying Themes
When you update a modified theme, your
code changes will be overwritten. Use a
child theme instead. Large multisites with
specific branding needs should consider
a custom theme.
50. IV. Modifying Themes
So, where do these changes go?
Save them in a PHP file and drop it
into:
wp-content/mu-plugins
51. IV. Modifying Themes
Must-use plugins make for a safe
alternative to functions.php mods.
⢠they load before regular plugins
⢠they canât be deactivated
⢠they wonât be overwritten
55. â-I. Cleaning Up
WordPress is remarkable, but itâs not
self cleaning. Be prepared to clear up
the clutter that invariably accumulates
over time.
56. â-I. Cleaning Up
Youâll probably need:
⢠an exit strategy for defunct sites
⢠a plan to clear unused accounts
⢠database maintenance tools
57. â-I. Cleaning Up
Youâll probably need:
⢠an exit strategy for defunct sites
⢠a plan to clear unused accounts
⢠database maintenance tools
58. â-I. Cleaning Up
Youâll probably need:
⢠an exit strategy for defunct sites
⢠a plan to clear unused accounts
⢠database maintenance tools
59. â-I. Cleaning Up
Youâll probably need:
⢠an exit strategy for defunct sites
⢠a plan to clear unused accounts
⢠database maintenance tools
60. â-I. Cleaning Up
Plugins are available to remove:
⢠options
⢠cron jobs
⢠roles and capabilities
⢠orphaned tables
62. â-I. Cleaning Up
And donât forget to dump unused media
files from sites. A lot of requests for
increased storage space would be
unnecessary if people deleted their
duplicate images.
64. More Missing Manual
⢠managing roles and capabilities
⢠finding good multisite tools
⢠using scripts to update settings
⢠automating maintenance with cron
⢠writing sustainable, reusable code
⢠sharing content across sites
65. Final Word of Advice
Never test new themes, plugins or
scripts directly on production.
66. The one thing thatâs scarier than seeing the White Screen of Death on your site âŚ
How multisite works may seem rather mysterious to novices.
In a single-site installation of WordPress, there are fewer than a dozen tables, though plugins may add more. The table names are descriptive. For instance, wp_posts is where the posts may be found, and basic user information is in wp_users.
On a multisite, each site has its own tables for posts, comments, terms and options. After the first site, often called the root site, the subsequent sitesâ table names contain the ID number of the blog. So for the second site, the posts table will be wp_2_posts.
Not all tables are duplicated. Some are shared by all sites. The wp_users table is one such global table.
Other global tables include wp_blogs and wp_sites.
The wp_blogs table is key to making multisite work. This is how WordPress knows which site on multisite is which.
This is an example of what a network dashboard might look like. This particular dashboard has been customized to display information about the multisite and the sites on it.
The Super Admin can see a list of sites that have been created on multisite.
There is a Network Settings page for settings that will be shared by all sites.
The terminology can be confusing. During this presentation each blog will be referred to as a site while the entire installation will be called a multisite or a network.
Multisite is not a good fit for everyone. If you have several unrelated WordPress sites, trying to consolidate them into a single multisite is not necessarily the best way to manage them.
Be prepared to Google a lot.
The rest of this presentation will touch on information that many Super Admins have to learn from experience.
Remember that just because you have one WordPress installation, you still to thing of server space in terms of the number of sites. A multisite on which each site has 150 MB of upload space will run into problems if youâre using budget hosting. Youâll also want to be sure to check with your hosting service in advance about restrictions, such as plugins they donât allow.
Youâll be prompted to make this choice when you set up your multisite. Certain multisite experts may recommend using subdomains for reasons that have to do with better SEO performance. For institutions trying to migrate existing sites with established identities, Iâve found that subdirectories provide more flexibility. You have the option of adding domains to selected sites using a domain mapping plugin.
If youâre using subdomains or domain mapping, expect to need a wildcard SSL certificate. A subdirectory installation without domain mapping can use a single SSL certificate.
Once youâre set up, think about a naming convention before setting up sites. You can change the site names later, but youâll need to fix links and images after you do. Planning ahead saves work.
If you think it canât happen to you, consider this multisite where there are sites for Writerâs Conference, Writersâ House, Writers, Writing Workshops and the Writing program.
Naming considerations for sites also apply to page names, known as slugs, on the root site.
Selecting good plugins is an important task for multisite.
More and better plugins are available for multisite than there were as little as two or three years ago, but you still need to check them out.
The uninstall file can tell you a lot. In this case the plugin will uninstall its options from the root site, but it makes no provision for the other sites on a multisite. Those options will be left behind in the database.
By comparison, this plugin gets a list of blogs and goes through each in turn to delete options from their respective tables.
On multisite, a plugin can be network activated. This makes it active on all sites. At the same time, it doesnât show up on the Plugins pages for individual sites and it canât be deactivated by administrators of those sites.
Youâll see the network activated plugins from the network admin area. There are some plugins that work well on multisite once theyâre activated individually, but they donât network activate properly.
We use a plugin called Multisite Plugin Manager to activate these plugins across all sites at once to create the tables and other resources for each site that a network activation fails to create.
Some Super Admins will install 100 or more plugins, but keeping the number to a minimum reduces the amount of maintenance overhead as well as the changes of a plugin conflict.
You may not want to grant administrators of individual sites the ability to activate any plugin available. Say there are 100 sites and a particular plugin has been activated on 40 of them. Then an update comes through that forces you to make emergency settings changes to each site where the plugin is installed. If on those 40 sites only seven of them are actually using the plugin, the extra sites are hampering you from getting the job done as fast and efficiently as possible.
The ability to enable site administrators to activate or deactivate available plugins is in the Network Settings.
Many of the considerations for plugins apply to themes as well.
Modifying theme codes directly is a bad habit of less experienced users. Never do it on multisite. When you modify theme code for one site on multisite, it changes it for all the sites using that theme.
To provide users with design options without having to support six or seven custom themes, we created a single theme with skins that they can choose from the Customizer. This provides design flexibility with significantly less code to maintain.
If youâve ever seen a tutorial for modifying a WordPress feature by adding code to the themeâs functions.php file, donât. If the code is to change site function rather than part of the theme, thereâs a better option.
Hereâs an example of a must-use plugin many people would have put in functions.php. This one removes âProtectedâ and âPrivateâ from password-protected and private post titles. It also customizes the excerpt text displayed for password-protected posts.
The only difference between putting it in functions.php and saving it in mu-plugins is that youâll need to add a few lines of metadata to the top of the must-use plugins file.
The name, description and other information will appear in the network plugins information.
If you clean up periodically, you have less mess to wade through to find and support your sites.
We have a standard procedure that if a site has not launched a year after the space was created, we remove it from the system.
Certain multisite experts may say to leave them in the system, but we delete users without any sites roughly every six months.
In addition to the plugins that donât clean up after themselves when they uninstall, there may be data left behind by plugins that have been permanently deactivated on certain sites. Settings, custom roles and capabilities and other data may be sitting in the sitesâ tables.
There are many other topics not covered by this presentation.
We have a multisite installation that exists solely to find out all the ways I can cause things to blow up.