Recover WordPress Network Install How to

WP Network Recovery So something did not work out with a (WP) WordPress 3.5 Network (multisite) install. Or maybe you want to inspect the contents of another network database. Most WordPress Network databases are recoverable. The road to recovery might seem long and daunting, but if you work through this recovery process, you will gain confidence in yourself and WP. Certainly this is not the superficial shortcut to getting WP Network up and running. To go down that road, just delete the network tables from your database and try again. See Reinstall Network Saving Posts. If you want to learn WP Network, read on.

Required Tools You Will Need

ability to work with website files: create, edit, change permissions
ability to connect a sql client like phpMyAdmin to a database
browse tables, run simple sql queries, edit records

Words of Wisdom

Before you invest in recovering your Network, if you have not already done so, please review your main site:

File and Folder Structure
Prepare main site for Network install
Revert to Single site mode and confirm operation of main site

File and Folder Structure

Files and folders are where you want them? This will have implications in managing files/folders as your site grows going forward.
What URLs do you want the public to use to access your sites? http://site2.domain.tld or http://www.domain.tld/site2

Option 1:
This is the structure that most WP documentation leads you to. This is fine if you don’t plan on adding any other folders. Consider that you might want to add private folders to hold logs, notes, php code, etc. One or more of these you may want to deny access to the web server, or in other words prevent public browsing.
The pattern will look something like the below. The first slash / represents your root whose physical path might be: …/html, …/home, …/public

/.htaccesss or web.config
/index.php
/wp-activate.php, wp-blog-header.php, wp-xxxx.php, ...
/wp-admin/...
/wp-content/...
/wp-includes/...
 and optionally
/logs/...
/protected-php/...
/other-docs/...

Option 2:
With WordPress 3.5.1, we recommend giving WP its own subfolder, and running WP from the web document root folder for your main domain.tld. This means WP’s index.php and url rewrite file must reside in the root folder, and the rest of WP’s files and folder are in a subfolder /wp/ for example.
The pattern will look something like the below. The first slash / represents your root whose physical path might be: …/html, …/home, …/public

/.htaccesss or web.config
/index.php
/wp/wp-activate.php, wp-blog-header.php, wp-xxxx.php, ...
   /wp-admin/...
   /wp-content/...
   /wp-includes/...
/logs/...
/protected-php/...
/other-docs/...

Note: If you choose to move files and folders read and comprehend codex giving WP its own folder. Then use your web-based control panel, because it should be faster and use less bandwidth than using FTP. Further, we like to keep a local master copy of the WP files that are on the web server, for development and recovery. You might enjoy our article on setting up a development environment. We like the FTP client FileZilla. The ability of your FTP client to preserve file timestamps is important, so you can determine at a glance whether the local or server file is newer.

Prepare main site for Network install

Before installing a WP Network, it is paramount to prepare your main site. Configuration that works in Single mode may not work in Network mode. The WP codex article Before You Create a Network nicely explains the preparation. If the main site is not prepared and fully functional, the Network mode is sure to be problematic.

A commonly overlooked requirement of a domain-based Network is preparing the main site url. Before You Create a Network, as of Mar ’13, stated “If you have www in the settings for your domain URL, and plan to use subdomains for multisite, make sure that both the Site address and the WordPress address are the same. If you plan on changing them to domain.com or http://www.domain.com, do so before you begin the rest of the setup for multisite, as changing the domain name after the fact is more complicated.” Our Changing Site URL. article includes a method to quickly test changing the Site URL before making changes permanent.

Operation of main site in Single site mode

Before you proceed, you should have proved to yourself the Network portion of the database and/or configuration is causing the problem. Revert or flip back to Single site mode by editing wp-config.php:

This is the only setting needed to FLIP between Single and Network mode
define(‘MULTISITE’, false); # false for Single mode, true for Network mode

So now back in Single site mode:

Can you login to the Site admin dashboard /wp-admin/?
Does the front end come back online and operate fully as seen by the public?
Test all of your main site: posts with media, add media, permalinks working, etc.

Road to Recovery

OK, now that the file and folder structure is cool, the main site is prepared for Network, and the main site functionality is confirmed, let’s get to a working Network.

WordPress Database Repair

the following defines are set in wp-config
define(‘MULTISITE’, true);
Note: db Repair will NOT touch the Network tables if define(‘MULTISITE’, false);
define(‘WP_ALLOW_REPAIR’, true);
Note: if WP_ALLOW_REPAIR is not in your wp-config add the line above, near your Network lines for convenience
Warning: WP_ALLOW_REPAIR must be changed back to false as soon as you have run ‘repair’ or ‘repair and optimize’ because anyone can browse to it.
Request or browse to …/wp-admin/maint/repair.php. Repairs all tables

Sample output from wp-admin/maint/repair.php:

The wp_users table is okay.
...
The wp_blogs table is okay.
...
The wp_site table is okay.

The wp_sitemeta table is okay.
...

Database Table & Field Requirements

18 is the number of tables for a Network without any subsites added
Tables added by Network Install?

Bottom Line:

There are three fields in the WP Network database that must be correct
db.wp_blogs.blog_id 1 ‘domain‘ and ‘path‘
- ie. ‘domain’ field could be domain.tld, or www.domain.tld
- ie. ‘path’ field usually /
- path could be /wp-install-dir if you run WP from a subfolder
db.wp_sitemeta ‘siteurl‘
- ie. ‘siteurl’ field could be http://domain.tld, or http://www.domain.tld/wp-install-dir (note this one includes http://)
Optionally* db.wp_site.id 1 ‘domain’ and ‘path’
- ie. ‘domain’ field should be identical to ‘domain’ in wp_blogs.blog_id 1
- ie. ‘path’ field should be identical to ‘path’ in wp_blogs.blog_id 1
*The two above are optional because in wp-config the two below will override what is in the wp_site record
- define(‘DOMAIN_CURRENT_SITE’, ‘domain.tld’);
- define(‘PATH_CURRENT_SITE’, ‘/’);

The Details

The Login Redirect Loop will result if the code below evaluates to true
More detail: wp_redirect( network_admin_url() ) called by /network/admin.php if below == true

( $current_blog->domain != $current_site->domain ) || ( $current_blog->path != $current_site->path )

Run this one line sql query against your Network installed database. It will not change data, only read it. If the two domains or the two paths are not equal the Network Login Loop will result. If they are equal, but incorrect your Network won’t work
Note: This sql select query will not work as written if wp-config $table_prefix has been changed from the default “wp_”
If $table_prefix is not default, change “wp_blogs AS b, wp_site AS s” to “<prefix>blogs AS b, <prefix>site AS s”

SELECT b.domain AS 'blogs-domain', s.domain AS 'site-domain', b.path AS 'blogs-path', s.path AS 'site-path' FROM wp_blogs AS b, wp_site AS s WHERE b.blog_id = 1 AND s.id = 1 LIMIT 1;

Example output:

blogs-domain     site-domain     blogs-path  site-path
domain.tld       domain.tld      /           /

Also, in the table wp_sitemeta the field ‘siteurl’ should also be accurate
‘Siteurl’ will include the http://domain.tld/ with the trailing slash

SELECT meta_value FROM wp_sitemeta WHERE meta_key = 'siteurl' LIMIT 1;

phpMyAdmin database ‘browsing’ might be easier

confirm/update fields in the following three tables:

table wp_site

should only have 1 record
if needed, edit fields ‘domain’ and ‘path’
ie. domain “domain.tld”, and path “/” (without quotes)
source of WP object $current_site
override db.wp_site overrides in wp-config:
- define(‘DOMAIN_CURRENT_SITE’, ‘domain.tld’);
- define(‘PATH_CURRENT_SITE’, ‘/’);
proof: set db.wp_site domain and path to “wrong.com” and “/wrong” but define 2 above correctly
performance: commenting, or better yet, removing the 2 defines would realize a miniscule gain, WP calls db to build objects anyway, not tested yet
sql to inspect: SELECT domain, path FROM wp_site WHERE id = 1 LIMIT 1;
sql to update: UPDATE wp_site SET domain = ‘4assistance.com’, path = ‘/’ WHERE id = 1 LIMIT 1;
if domain defined wrong, site admin OK, admin bar links – only Network Admin and child links wrong and get WP HTTP 404, manually request /wp-admin/network/ – should be login loop (blog domain != site domain, and browser redirected to http://4assistance.com/wp-signup.php?new=4assistance.com
Curiosity:
if db.wp_site.domain is wrong but overridden by wp-config DOMAIN_CURRENT_SITE site operates 100%, BUT Network Dashboard -> Settings -> Network Setup suggests define(‘DOMAIN_CURRENT_SITE’, ‘wrong.com’)

Table wp_blogs

focus on record with blog_id equal 1 for now
if needed, edit fields domain and path
other ids are records for other sub sites installed, adjust as necessary
source of WP object $current_blog
available db.wp_blogs override: unknown
sql to inspect: SELECT domain, path FROM wp_blogs WHERE blog_id = 1 LIMIT 1;
sql to update: UPDATE wp_blogs SET domain = ‘4assistance.com’, path = ‘/’ WHERE blog_id = 1 LIMIT 1;
if db.wp_blogs.blog_id=1.domain wrong, probably “Server not found”,
if db.wp_blogs.blog_id=1.path wrong,

Table wp_sitemeta

find meta_key ‘siteurl’ usually meta_id 14
‘siteurl’ has to be the URL to your physical WP install without trailing slash
ie. if WP installed in domain root, then this is just a link to your domain, but if WP is installed in its own subfolder, append the path to that folder

Test Network Operation

OK, let’s see if WordPress Network is working. Confirm settings in wp-config:

define(‘WP_ALLOW_MULTISITE’, true);
define(‘SUBDOMAIN_INSTALL‘, true); # false if using path-based sub-folder sites

Generic wp-config.php for an installed Network:

define('WP_ALLOW_MULTISITE', true); # enables main site dashboard > Tools > Network Setup
define('MULTISITE', false); # false for Single mode, true for Network mode, only setting needed to FLIP between
define('SUBDOMAIN_INSTALL', true); # false if using subfolder Network ie. domain.tld/site2
define('DOMAIN_CURRENT_SITE', 'domain.tld'); # overrides db 'domain' field in wp_site table
define('PATH_CURRENT_SITE', '/'); # overrides db 'path' field in wp_site table
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
# next line is optional, reference http://codex.wordpress.org/Editing_wp-config.php#Automatic_Database_Optimizing
define('WP_ALLOW_REPAIR', false); # if true public can request /wp-admin/maint/repair.php. Repairs all tables, MULTISITE must be true to include the Network tables

Use WP_DEBUG for extra info

define(‘WP_DEBUG’, true); # true for extra messages on screen, BUT SAME SEEN BY PUBLIC, false when not troubleshooting

Does the Network Work?

If you haven’t seen a functional Network yet, know that there are two Dashboards. The Site admin for each of the sites is most like the Single mode dashboard. The other is the Network (Super) admin dashboard, where you will add sites, network enable plugins and themes, and so on.
Can you add a new site?
If the Single, main site, had posts, are they accessible from the front end?

Yes, What’s Next?

Update your URL Rewrite file from settings in Network admin, you’ll find this in Settings -> Network Setup
On apache this is .htaccess, and on IIS it is web.config.
Happy Networking

No, what else can I do?

Post a comment here
Create a new forum topic @ wordpress.org