If you’ve gotten this far, you’re ready to run a network! As with all things, there are some more advanced topics. From this point on, you will have to be comfortable with managing the files on your server and accessing the database.
Many of these topics will use plugins, as well.
G
O BACK TO A SINGLE INSTALLAfter all that, sometimes people realize that they didn’t want Multisite. It can be removed fairly painlessly.7
1. Delete any extra sites you may have created, either moving the content and users to the main blog or wherever you desire. One the sites are deleted, you cannot retrieve the content.
2. Remove the lines added in the wp-config.php file.
3. Restore the .htaccess file to the default (you can usually restore these by resaving the permalinks).
4. Remove the wp-content/blogs.dir (don’t worry, your main site stored everything in wp-content/uploads).
5. Drop these global tables from the database: wp_blogs wp_blog_versions wp_registration_log wp_signups wp_site wp_sitemeta That’s it!
E
XPORTINGA
S
ITEIf you want to export one site from the network and install somewhere else, you will have to make a couple important decisions. If all you care about is the content, a traditional WordPress export will be just fine.8 You
can simply import the content on the new location, be it a separate install of WordPress, or just a different site on your network.9
If you need to keep the look and feel of your site, all the plugins, theme settings, and users, it’s vastly more complicated. The basic steps would be to:
1. Install WordPress in the new location.
2. On the existing site, make a note of all users on the site and their user ID.
3. Create your authors (their passwords will change, everyone will have to cope)
4. Export all the wp_x_[tables] from your database, where x is the site ID.
5. Rename the tables in that export file to just wp_[table]
6. Search the export file for the old site URL (i.e. http:// example.com/sitename/ ) and replace with the new one (i.e. http://newexample.com )
7. Make a list of all the users and their IDs. Compare this to the list you made in step 2 and make sure you know everyone’s old and new user ID.
8. Edit the wp_posts values for post_author, changing accordingly based on the table you made in step 7.
9. Import the database.
10.Copy /wp-content/blogs.dir/ID/files/ from the old server, and place it in /files/ on your new server.
If at all possible, just use the traditional export/import. You’ll get a much cleaner database in the end.
8 To export, see http://codex.wordpress.org/Tools_Export_Screen 9 To import, see http://codex.wordpress.org/Tools_Import_Screen
M
OVING YOUR NETWORKMoving a network from one server to another, provided none of the URLs are changing, is as simple as copying over the database and all the files.
If, instead, you are changing domains, then the best way to move Multisite is to move the files, edit the .htaccess and wp-config.php (if the folder name containing Multisite changed), and then manually edit the database. Search for all instances of your domain name, and change them as needed. This step cannot yet be easily automated. It's safe to search/ replace any of the wp_x_posts tables, however do not attempt blanket search/replace without a special search and replace script.
You can get a copy of the Search and Replace Script at http:// interconnectit.com/124/search-and-replace-for-wordpress-databases/
If you're moving Multisite from one folder to another, you will need to make sure you edit the wp_blogs entries to change the folder name correctly. You should manually review both wp_site and wp_blogs regardless, to ensure all sites were changed correctly.
Also manually review all the wp_x_options tables and look for three fields and edit as needed:
home siteurl
fileupload_url
If you are moving from subdomains to subfolders, or vice-versa, remember to adjust the .htaccess file and the value for SUBDOMAIN_INSTALL in your wp-config.php file accordingly.
P
RE-C
ONFIGURINGP
LUGINSBy default, plugins are either on or off, and the settings are handled per-site. In some cases, you want to pre-configure plugins for your users. In order to do that, you need to use the plugin ‘YD WPMU Sitewide Options.’
http://wordpress.org/extend/plugins/yd-wpmu-sitewide-options/
R
ESTRICTINGP
LUGINSIf a plugin is not network activated, it’s available for all sites to activate as they chose. Sometimes you don’t want this, but instead want to limit certain plugins to only be run on certain sites. There are multiple plugins that can be used for this, depending on how you want to manage plugins.
Exclude Plugins
Exclude plugins from appearing in plugins menu for normal user in WordPress multisite.
http://wordpress.org/extend/plugins/exclude-plugins/
Restrict Multisite Plugins
Provides an interface similar to how the ‘themes’ section looks. http://wordpress.org/extend/plugins/restrict-multisite-plugins/
Plugins Enabler
Hides all plugins by default, and allows you to re-enable per-site. http://wordpress.org/extend/plugins/plugins-enabler/
Multisite Plugin Manager
Allows you to manage plugin activation.
http://wordpress.org/extend/plugins/multisite-plugin-manager/
M
APPINGD
OMAINSYou can run multiple domains from one Multisite, by using a domain mapping plugin. You will need to create a site for each domain, but once that’s done, it’s fairly simple to map the domain. The plugin ‘WordPress MU Domain Mapping’ is very reliable.
http://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/ The complicated aspect of mapping a domain is in mapping the domain to your server. The basic step is to point the DNS settings of your new domain to your existing server. However, depending on your host, you may also have to park the domain in order to add it to your own DNS server. If you’ve never parked a domain, or made an add-on, you should check with your webhost first.
Once you’ve sorted out mapping the domain, you can point it to your site ahead of time, and verify it works by going to http:// newdomain.com, which should take you right back to http:// example.com/
From the Domain Mapping menu, set either your Server IP or the CNAME, pick your options, and hit save.
The options are as follows:
• Remote Login – All sites will log in through your main domain. This is good, because once you’ve logged in to one, you logged in to all (due to how cookies work). The downside is everyone will see their URL change when they log in.
• Permanent redirect (better for your blogger’s pagerank) – Instead of using your original URLs (like http://subsite.example.com ) you now use http://newdomain.com. Leave this checked, you want it. • User domain mapping page – If you want to allow users to map
their own domains, check this.
• Redirect administration pages to blog’s original domain (remote login disabled if redirect disabled) – All sites Dashboards will r e m a i n r e f e r e n c i n g t h e m a i n d o m a i n ( i . e . h t t p : / / s u b s i t e . e x a m p l e . c o m / w p - a d m i n i n s t e a d o f h t t p : / / newdomain.com/wp-admin )
•Disable primary domain check. Sites will not redirect to one domain name. May cause duplicate content issues. - As it says.
• Then you go to the ‘domains’ Menu and add in a new domain. It’s as simple as filling in this form:
That’s it!
If you’re running subdomains, sometimes you want to be able to create sub-sites off the subdomains, like http://subsite.example.com/newsite, or, in the case of mapped domains, have it run it’s own network.
While it is possible, it always requires a plugin, and it can get complicated very quickly.
WP Multi Network
http://wordpress.org/extend/plugins/wp-multi-network/ Networks+ ($25.95)
http://wpebooks.com/networks/
S
PLITTINGY
OURD
ATABASEIf your site gets very large, you may need to split it into multiple databases. HyperDB and SharDB are the best plugins for the job, but both require a great deal of SQL savvy.
http://wordpress.org/extend/plugins/hyperdb/ http://wordpress.org/extend/plugins/shardb/
R
EMOVING‘B
LOG’
FROM THEURL
OF YOUR MAINSITEIf you installed Multisite as a subfolder setup, you may recall that the /blog/ slug shows up in your posts, and you were told you can’t change that? Actually, you can remove this if you absolutely must, but it’s not supported nor recommended.
Go to Network Dashboard -> Sites and edit your main site.
Click on the ‘Settings’ tab and scroll down till you see Permalink
Structure. Delete /blog from that so you just have /%year%/
%postname%/ or whatever you want your format to be.
Please keep in mind, you now can never edit your permalinks on your main site, except through this method. If you go to your main site’s
dashboard and use the Permalink page there, the slug will magically return.