How do I restore a single sub-site on a Multisite Network?

UpdraftPlus Premium can import a stand-alone WordPress backup into a WordPress network, as a new site. If using this facility, then it is important to be familiar with all the information on this page.

To restore a single sub-site on a WordPress multisite, click to restore your backup as normal. The restoration wizard will give you the option to choose a specific site to restore.

Please view this instructional video:

Play video

To use this feature, simply press the ‘Restore’ button in UpdraftPlus in the usual way. After the backup is downloaded and scanned, you will be given the choice of which site to restore, as in the screenshot below.

Note: you will only be given the choice of which site to restore if:

• You are on a WordPress multisite install
• You are restoring a backup from the same install
• You are running WordPress 3.5 (released December 2012) or later
• You have selected the option to restore your database, or uploads.

This is because all other file entities except uploads (i.e. media) are shared across all sites. A WordPress network only has one installed set of plugins and themes (though, of course, different sites may have different ones marked as activated (which is in the database) – but, the files on disk only exist once). (N.B. On WP Network installs that started life before WordPress 3.5 (released December 2012), media on secondary sites is stored in the ‘Others’ backup, and the option will show if you select this entity, rather than ‘Uploads’).

If you choose “All sites”, then the entire backup will be restored – everything on the network should then be restored back to its previous state. If you choose one of the individual sites from the backup, then only tables and media belonging to that site will be restored. (For those interested in the internals of WordPress, that means the tables with the site ID prefix, and media in the specific sub-directory of your media folder belonging to the site).

It is important to understand that this feature can never be guaranteed to work seamlessly, and in many cases will require further manual work, or can’t work at all.

There are two main reasons for this:

1. WordPress plugins (and much more rarely, especially with properly-written ones, themes), need to be deliberately coded for WordPress Network support. A plugin which works on a stand-alone WordPress install, may not necessarily work properly on a WordPress Network – or may not work the same way. This can either be by deliberate intention (i.e. different behaviour by design), or by omission (e.g. the developer simply never tested the plugin on multisite installs). It is fairly easy, especially for less advanced plugin developers, to write plugin code that assumes things which are always true on stand-alone WordPress installs, but are not true on Networks, and don’t work the same way there (or don’t work at all).
2. Some components of a WordPress site are shared resources, that belong to the entire WordPress install. There’s not always a possible automated way to merge these components, if wanting to import a single site into a multisite. This is discussed more below.
   With features of WordPress core, you are safe; WordPress core itself is of course network-aware. And with WordPress’s growing popularity, plugins are increasingly so – especially the more popular ones.

If you choose to restore the “main” site (i.e. the ‘default’ site), then you should be aware that this can include some site-wide settings. Under the bonnet in WordPress, there’s nothing stopping plugins and themes from storing their settings anywhere – and some, which are not written to be multisite compliant, may store their settings in the “main” site, instead of specifically in the part of the WordPress database reserved for site-side settings.

The same can be true for media as well as settings.

WordPress core itself certainly does store things where it’s meant to, and popular, widely used plugins, are of course, are more likely to be fully multisite compliant.

Since these things are under the control of third-party plugins/themes (of which there are over 40,000 in existence!), if restoring your “main” site affects non-main sites, in respect of some plugin or theme, what support can be provided in this scenario from UpdraftPlus is very limited. The power of the WordPress plugin system is that more-or-less anything can do anything. Don’t let this warning put you off; most plugins are well behaved!

Nonetheless, it is still true that some parts of WordPress’s innards don’t necessarily translate well from single-site to network, and that a lot of things are under the control of plugins, not UpdraftPlus. As such, you should be aware that, whilst UpdraftPlus always seeks to be cautious and apply best practices, yet importing a single site into a WordPress network may bring about issues which UpdraftPlus cannot control. Please be aware of this, and have appropriately realistic expectations (including of what our support channel can do – in particular, we cannot investigate or provide work-arounds for plugins or themes that are not WordPress Network compliant, or perform general investigations into import issues). If it helps, you should consider this kind of import as “beta”, and not be too surprised if the end outcome is “there’s no way to import this site”.

In WordPress Multisite, some files are organised on a per-site basis – specifically, the media files (uploads). Each site within the network has its own folder. However, other files are shared. These are discussed below:

Plugin and theme files: these are shared. As such, there can only be one version of any specific plugin or theme, on a WordPress Network. If your backup set contains a plugin/theme that is already installed on the WordPress Network, then UpdraftPlus will ignore the one in the backup set – i.e. it will always retain the installed version. As such, you will want to check that resources on the site you are importing are compatible with the versions already installed on your network, if and when dependencies exist. Any themes that you import will be network-activated (i.e. made available to all sites).

WordPress core (i.e. the files that make up the basic install of WordPress itself) is also a shared resource, and hence cannot be restored as part of an import of a single site into a multisite. For this reason, you also need to consider whether your destination site and backup set are from different WordPress versions (generally, WordPress is backwards-compatible, but not forwards-compatible – you can import data from previous versions, but not future ones). UpdraftPlus will forbid you to proceed if you select WordPress core as part of the content to be imported from a single site into a multisite.

Other content from the wp-content folder (other than plugins and themes): These are also shared. There are several plugins which store data directly into their own sub-folder of the wp-content folder. Sometimes, this is the wrong thing to do, and the plugin should be using the site-specific ‘uploads’ folder (e.g. there is a popular gallery plugin that does this). Unfortunately, this content can’t be automatically merged across sites, when wanting to merge a single site into a multisite. Some other plugins legitimately store data directly into their own sub-folder of the wp-content folder, because their data really is install-wide (not per-site). (UpdraftPlus is an example of this; as a backup plugin that creates whole-install backups, its data doesn’t belong in per-site folders). UpdraftPlus will forbid you to proceed if you select other wp-content content as part of the content to be imported from a single site into a multisite. If you have any such content (not all installations do), you will need to review it manually (i.e. inspect the content of the “others” zip(s)), and copy over the relevant parts manually.

Must-use plugins: These plugins (found in wp-content/mu-plugins, if any exist), are compulsory plugins that are active throughout the WordPress install. For a single site, this only affects that site – but if used on a multisite, they will affect all sites. You will need to manually review any of these plugins that you have, and import them by hand. They are not always appropriate for adding to your multisite (e.g. some web hosting companies install an mu-plugin to tie your site into their management tools; or, you may have an mu-plugin which you wouldn’t want to modify behaviour across all sites).

You should never import a WordPress backup from an untrusted source. Internally, WordPress has basically no walls of separation – which is what makes plugins so powerful; they can do anything. If you import a site, then faulty code can bring down your entire network; and malicious code could infect the whole network, in ways that are hard to detect or correct. Note also the possible implications for stability of the notes on shared resources above (e.g. different versions of plugins/themes on different sites). You should consider cloning your network, and testing out the import operation on your test copy first.

There is no easy way to import users and user-associated data from your standalone site. This is because internally, WordPress uses numbers to identify users, starting from 1 – and these identifiers could be stored anywhere in the database (including anywhere that any of the 40,000+ WordPress plugins care to put it). As a result, different WordPress sites are likely to have different users with the same user ID, and unpicking that mess is a very non-trivial task. UpdraftPlus “resolves” this by asking you to re-assign all content (all posts/pages, including custom post types) to a specified user. (You may want to create a specific user for this first, and then assign it admin rights to the site after import). This solution will still not be able to identify/re-assign data in tables belonging to third-party plugins – so, if you have plugin that have user-specific features, you will want to verify their operation afterwards.