In addition to WordPress single site installations on VIP Go, we also support WordPress multisite (also known as WordPress Networks). A WordPress multisite allows you to run multiple WordPress sites from the same WordPress installation, using the same set of user accounts. One common use case for a WordPress multisite is to support multiple languages, using the Multilingual Press plugin from Inpsyde, one of our VIP Featured Partner Agencies.
Specifics of how WordPress multisites work are available in the WordPress Codex article on WordPress Networks, but here are some key features:
- A multisite can use any combination of domains, subdomains, and subdirectories.
- All subsites share the same database.
- Several tables are shared by the entire multisite:
- In addition, each subsite has its own set of the following tables that, after the first subsite, are prefixed by site ID (e.g.
wp_for tables for site ID 1;
wp_2_for tables for site ID 2; et al):
- While the users table is shared, users can have unique roles (or none at all) on a per-subsite basis.
- Subsites all deploy from the same repo and the same branch.
- Plugins and themes can be made available on a per-subsite basis.
Reasons to use a multisite may include:
- Themes and plugins need to be updated only once for the entire network, instead of once per site.
- Editors and administrators who have access to multiple sites can easily navigate between them.
- Administrators can create new subsites quickly and easily.
Reasons not to use a multisite may include if you have different development teams per site who should not share access to the same repo.
Order of launching sites on a multisite
1 is the first site in a multisite network and will be listed first in the Network Admin > Sites listing. A non-convenience URL (something other than
*.go-vip.net) must have its DNS pointing to this subsite before any other subsite can launch.
This first subsite can be used for administrative purposes only: it can use a default theme, have no content, and have access restricted by Maintenance Mode. But all new subsites in a multisite network will initially exist as subdirectories of subsite
1’s domain. It can therefore be useful to have a custom domain in subsite
1 for branding purposes, such as
While plugins are installed via GitHub and are activated at the network level, by default, subsite administrators cannot enable or disable plugins. A network administrator can make this functionality available by checking the appropriate box at the bottom of