WordPress SubDomain GoDaddy Network Shared Hosting

WordPress SubDomain GoDaddyHerein is the condensed version of installing a (WP) WordPress SubDomain GoDaddy Network on free or shared hosting. This process might be applicable to other shared hosting providers. Shared hosting is economical and will not provide the power required by higher traffic sites. When that time comes you can move to more powerful resources. This study was conducted with WP 3.5.1. You might also be interested in our article on setting up a local WP development site for testing.

Caveat: As of the publishing date of this article, free nor shared hosting supported wildcard DNS. That means the WordPress SubDomain GoDaddy Network described here will not support dynamically adding subdomains. For example, let’s say you have your main site URL as domain.tld and want to add site2.domain.tld to WP. You will have to manually add “site2” as a sub-domain of domain.tld using your domain’s hosting control panel, before it will work in WP.

Steps to WordPress SubDomain GoDaddy Network

  • Set up your domain so that HTTP requests for www.domain.tld are permanently moved (HTTP 301) to domain.tld. On apache your root folder /.htaccess will need something like:

RewriteEngine On
RewriteCond %{HTTP_HOST} !^(site2|site3|site4|site5)\.domain\.tld$ [NC]
RewriteCond %{HTTP_HOST} !^domain\.tld$ [NC]
RewriteRule ^(.*)$ http://domain.tld/$1 [R=301,L]

  • Get comfortable with backing up and restoring your WP database. I like wp-backup-db plugin.
  • Read the WP codex Before Creating a Network
  • Install WP >= 3.5 on your domain.tld file system. I recommend giving WP its own subfolder but running it from the root. Minimize your Network setup time by doing this before Network install.
  • Confirm your main (first) site configuration by testing: can post, comment, add media, view media in posts, menus functional, permalinks working, user accounts if you will allow users to create accounts, login to Site admin, etc.
  • Read this WP codex article on Network Install, and you are ready to edit wp-config
  • define(‘WP_ALLOW_MULTISITE’, true);
  • Install your WP Network
  • Login to Network (Super) admin
  • Confirm your Network admin configuration by testing: admin bar links, all My Sites menu item links are working, confirm URL Rewrite configuration in Settings -> Network Setup, plugins network enable/disable, themes network enable/disable, etc.
  • Navigate to your main Site admin, note differences from Single mode Site admin, ie. how has the Settings -> General page changed?
  • Now you are ready to add a subdomain site

The Magic, or Work, of Adding SubDomains to GoDaddy Hosting

  • Add your second site’s subdomain to your domain in your hosting control panel
  • Point the subdomain at the same folder as your domain
  • GoDaddy will add the necessary DNS entries to your domain’s zone file
  • Other shared hosting providers that provide subdomains should do the same.
  • If you would like to see the DNS changes hours before the majority of the general public, set your primary dns server to the name server for your domain on your client computer
  • In WP Network admin -> Sites, add the sub-domain you just set up in your hosting account.
  • Get busy building your second site.
  • Repeat these steps until you have all the sub-domains you need.


Recover WordPress Network Install How to

WP Network RecoverySo 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.

You Are Here

  • Main site in Single mode operated good
  • An existing WordPress network was detected
  • Can’t login to site nor network admin
  • Error connecting to database
  • Pages redirect to unexpected locations

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

  • 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
/wp-activate.php, wp-blog-header.php, wp-xxxx.php, ...
 and optionally

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
/wp/wp-activate.php, wp-blog-header.php, wp-xxxx.php, ...

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


Reinstall Network WordPress – Save Posts

Have you tried unsuccessfully to Recover Your WordPress Network? Yes, I just want to reinstall the WordPress Network. OK, delete the network tables listed below. If you do not delete any of the Basic tables listed further down, you probably won’t need to reinstall WordPress. Any posts you had on the main site will also be preserved. If you need to preserve posts from any of the sub-sites, tables named wp_#_xxxx, you should solicit professional help.

Network Tables Installed by WP 3.5.1

(from WP Codex)

  • delete or empty all the following network tables
    • wp_blogs
    • wp_blog_versions
    • wp_registration_log
    • wp_signups
    • wp_site
    • wp_sitecategories
    • wp_sitemeta
    • wp_users
    • wp_usermeta
    • optionally remove any/all wp_#_xxxxx    ie. wp_2_xxxx…, wp_3_xxxx…, etc.

then follow how to create a network, which cautions your single site must be setup the way you want it BEFORE installing the network.

Basic Tables Installed by WP 3.5.1

  • wp_commentmeta
  • wp_comments
  • wp_links
  • wp_options
  • wp_postmeta
  • wp_posts
  • wp_term_relationships
  • wp_term_taxonomy
  • wp_terms
  • wp_usermeta
  • wp_users

Beware Settings->General Site URL, or Site Address (URL)

Changing Your Site URL, or Site Address

In Single site mode, WordPress 3.5.1 leads you to believe you need to change the site URL, or ‘Site Address (URL)’ if you want to run WordPress from a folder other than where you installed it

On screen is, “Enter the address here if you want your site homepage to be different from the directory you installed WordPress.”

NOT TRUE  according to that same Codex document, see section “Using a pre-existing subdirectory install”

Our idea with these paths is to point them to the location of the WP index.php that you use to ‘run’ WP. If index.php is in the root, then these paths must point to the root. If WP is installed in a subfolder and you wish to ‘run’ it from there, then append the folder path.

Quick Test of Site URL, or Site Address (URL)

Maybe you changed either of the above addresses and now you can’t get back into your site. Add these two lines near the bottom of wp-config which will override the fields ‘siteurl’ and ‘path’ that you just changed in the database table wp_options. Adjust the paths to the location of your index.php

/**** That's all, stop editing! Happy blogging. ****/

Note: These define paths used only when in Single site mode. While these are defined you will not be able to edit them in General -> Settings, only read them. But hey, it’s a quick method to test both settings until you get it right.

Making the Site URL, or Site Address (URL) Permanent

  • Confirm you can login and note the paths that work. Test all of your main site: posts, media, permalinks, etc.
  • Next step is to make the ‘home and siteurl’ changes in the database permanent
  • Then read Changing the Site URL for options on making your ‘test’ changes permanent.
  • This will also ensure that if Network is later installed, you can flip back to Single mode without errors

Once the database fields in table wp_options are set and tested, you can remove

from wp-config


How to Create a Development WordPress Site Mirror

Here is one way you can set up and run a development (dev) WordPress site, then move the database to production (prod) without manipulating data. Here’s how the “mirrors” were created.

Considerations in Brief

We developed on separate hardware for dev and prod, but this method may work just as well on the same machine, with at least one virtual machine (VM). The requirement is that the “two” have access to distinct DNS services.


It is probably best to create the production database (db) first. Dev will probably be more flexible, and prod more restrictive, especially if shared hosting is involved. Nice to have will be the same table types, as in Isam and InnoDb if using mySql. Because moving data will be via export/import it may not be critical. The two systems described here, both had InnoDb tables. The dev database was created using the same db name, db user, db password,

Web Servers

Not being a good consumer, a four year old laptop stood in as the dev server and client. It ran Win 7, PHP 5.2, mySql 5, IIS7.5, and WordPress 3.5.1. The prod site was on a shared host server running Linux, PHP 5.3, mySql 5, and apache


DNS was the “magic” that allowed using the “same” domains and database hosts. The prod database and web servers were separate machines with distinct host names and IP addresses. The dev “server” running windows simply used the drivers\etc\hosts file and pointed the site domain name and database host name at the localhost thusly:     domain.tld     database.mywebhost.domain.tld

  • tld means top level domain, as in .com, .net. org, …
  • switching the client between working on dev or prod server, simply involved renaming the hosts file.

Moving WordPress site from Development to Production

WordPress database was exported by the WordPress plugin wp-db-backup. On the windows dev box, mySql client performed export duties, while on the prod Linux server phpMyAdmin did the importing.

Read more WordPress Core
Happy development

WordPress Network Setup Offers Broken URL Rewrite Rules


This was repeated with WordPress 3.5.1 installed on shared Linux apache hosting. The hosting account supported multiple domains, with each domain running from a subfolder of the hosting acccount’s web server document root. No attempt to repeat this behavior was attempted with shared Windows hosting.

  • For example, the web server document root was:
  • And http://domain.tld/ was set up to run from:
  • Now we wanted to use WordPress on domain.tld, AND we also wanted the core files in a subfolder as in:

WordPress is installed to the above folder. If WordPress can’t write to .htaccess or web.config files, WordPress proposes the required URL ReWrite code. Either way, .htaccess or web.config is configured to rewrite incoming HTTP requests, so the web server can find the requested files. Testing the new site, you encounter the following symptom.


  • Your WordPress site appears, but is rendered without any style. If the site does not render at all, you have other issues to solve.
  • You might also notice javascript is non-functional
  • Inspection of HTTP headers, using tools built into your browser, reveals numerous 404 errors


  • URL Rewrite not working because it is miss configured through no fault of your own

In Single Site mode, WordPress Dashboard -> Settings -> Permalinks -> Save Changes, or
in Network mode, WordPress Network Admin Dashboard -> Settings -> Network Setup,
may offer incorrect url rewrite rules

Is this only on apache???????????????????????

WordPress rightly or wrongly finds the root folder that should be available to the web server, so an extra folder is appended to the rewrite rules, which breaks url rewrite that WordPress.depends on.


Edit your .htaccess or web.config, removing the offending folder from the rewrite condition


Login Loop WordPress Network Admin

WP loginThis article referred to the Network Admin login loop as experienced on WordPress 3.5.1 in subdomain Network mode. Not to be confused with the Site Admin login loop when WP is running in Single mode, although some of the early troubleshooting steps suggested here apply to both types of login loops. Manually requesting the Network Admin login URL could look similar to http://domain.tld/wp-admin/network/. which gets you to http://domain.tld/wp-login.php as seen in your browser location bar. This is as far as you can get. This loop can discourage, but you are not far from logging in to the Network Dashboard. Your network is installed and your WP is accessing the database as planned.

Login Loop Symptom:

  • you may have logged into the Site Dashboard using http://domain.tld/wp-admin/
  • the loop presents itself when getting into the Network Dashboard
  • Entering correct login credentials, the login loop just ‘refreshes’ the login page. If wrong credentials were entered, WP is kind enough to indicate that above the login form
  • request w/FF or IE http://4assistance.com/wp-login.php redirects to http://4assistance.com/wp-login.php?redirect_to=http%3A%2F%2F4assistance.com%2Fwpress%2Fwp-admin%2F&reauth=1 (note physical folder /wpress), had ff browser tabs open, failed login logs out the one logged in


  • Web browser history can illicit the login loop, especially when first installing your Network. Your Network Dashboard is configured to work, you browser is keeping you from getting to it.
  • You may have done one or more of the following: moved your WP install, changed url rewriting, changed domain names, edited your wp-config.php.

Breaking the Loop:

Preliminary Steps

  • Eliminate the simple first.
  • Clear browser cache, including cookies for your domain.tld.
  • For your web browser, check out ‘Private’ browsing. It does not save any history when you quit, especially useful during setting up any WP.
  • Confirm the follow two lines in wp-config are correct, because when either is defined, they will override the corresponding record in the wp_site database table
    define('DOMAIN_CURRENT_SITE', 'domain.tld');
    define('PATH_CURRENT_SITE', '/');
  • Try commenting them out, one at a time. Perhaps the records in the database are correct.

Technical Inspection

  • Two database tables added by installing Network, wp_blogs & wp_site each have two fields that must be the same in both tables. Once in a while domain and path can be changed in one table and not the other.
  • Function wp_redirect( ) will be called if this is true, and what the browser sees is the login page refreshed.
  • You will have to be able to edit your database using a client like phpMyAdmin to continue. Failing that, you still have options like hiring professional help, or attempting another installation of WP and Network.
  • To inspect these fields, following are a couple of options: edit an admin.php file, or run our one line sql against you db, or manually compare them using your favorite database client

admin.php file method

  • If you’d like to see your two domains and paths, the way your WP sees them, insert the php code below in the: /wp-admin/network/admin.php
  • Find around line 16 the line that reads “wp_die( __( ‘Multisite support is not enabled.’ ) );” Insert the code that follows, just below this line.
# begin flail
/*  <- prepend this line with # as in "#/*" to activate this flail (also the one below)
$blog_dom = '$current_blog->domain: "'.$current_blog->domain.'"';
$site_dom = '$current_site->domain: "'.$current_site->domain.'"';
$blog_path = '$current_blog->path: "'.$current_blog->path.'"';
$site_path = '$current_site->path: "'.$current_site->path.'"';
$same = 'This is good, some other config is causing the problem, url rewrite, PATH_CURRENT_SITE not /';
$diff = 'These are different, we need to change something';
$dom_same = ( $current_blog->domain != $current_site->domain ) ? "$blog_dom NOT equal $site_dom, fix required" : "$blog_dom EQUAL to $site_dom, no problem here";
$path_same = ( $current_blog->path != $current_site->path ) ? "$blog_path NOT equal $site_path, fix required" : "$blog_path EQUAL to $site_path, no problem here";
echo "<h3>[".basename(__FILE__)."][".__LINE__.'] '.$dom_same.'</h3>';
echo "<h3>[".basename(__FILE__)."][".__LINE__.'] '.$path_same.'</h3>';
*/  <- prepend this line with # as in "#*/" to activate this flail
# end flail
  • In your browser, request http://your.main.site.domain.tld/wp-admin/network/ and you should see the results of the above test
  • If your WordPress or URL rewrite by web.config or .htaccess is bad, and you installed WordPress in a separate folder, include that folder name in the above URI

one line sql query method

  • Use your favorite database client to run the following sql
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;
  • Expect output something like this with the command-line mysql client: I hope yours is less messed up than this example.
| blogs-domain    | site-domain | blogs-path | site-path |
| domain.org      | wrong.com   | /          | /blog     |
  • Remember that the two wp_site table records (wrong) above, can be overridden if defined in wp-config as below:
    define('DOMAIN_CURRENT_SITE', 'domain.tld');
    define('PATH_CURRENT_SITE', '/');

Manually Inspect (Browse) database

table wp_site

  • should only have 1 record
  • if needed, edit fields domain and path
  • ie. domain “domain.tld”, and path “/”

table wp_blogs

  • focus on record with blog_id equal 1 for now
  • if needed, edit fields domain and path

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


Override Default WordPress Network Add New Site URL

We need to find how the Edit Site page -> Settings tab -> Siteurl field string is generated.Add New Site page, network/site-new.php, “Site Address” if adding a subdomain, will appear in the Edit Site page -> Info tab -> “Domain” field and Settings tab -> “Home” field

The form:
Siteurl field in html is id=”siteurl“, site-settings.php?id=siteid builds the url
Posts to itself?action=add-site

base siteurl existed in
obj WP_Admin_Bar->user->blogs->1-siteurl == “http://4assistance.com/wpress”
obj active_blog->siteurl, COULD we use active_blog->path, yes if it doesn’t break main site by adding it there.


Adding New WordPress Network Site on Shared Hosting



  • Want to add a new WordPress Network site
  • Main site resides an shared hosting


  • Can’t set up wildcard DNS because of shared hosting
  • Network Admin adds site OK
  • attempting to view new WordPress Network site yields “Server not found” or “This page can’t be displayed


  • The world needs dynamic name system (DNS) entries to get to your new WordPress Network site
  • Add, or have your web hosting service add, a subdomain to your hosted domain
  • If your web hosting does not permit subdomains, it’s time to change your hosting package or your hosting provider.
  • (plug) We’d be happy to provide your hosting for you.
  • Adding the subdomain for your new site should automagically add the required DNS entries to enable the world to view your new WordPress Network site

To receive free assistance, post a reply or comment


Fix WordPress Plugin wp-db-backup Fails Downloading to Computer

Problem: wp-db-backup fails to “Download to your computer”


  • Running WordPress 3.5.1 subdomain Network
  • WordPress plugin wp-db-backup version 2.2.3 (current as of Mar, 2013)
  • Backup option “Save to server” works normally


  • Backup option “Download to your computer,”
  • browser fails to download the backup file, no browser errors
  • wp-db-backup finishes the backup normally
  • Running in WP_DEBUG mode reveals notices and warnings
    • Notice: is_site_admin is deprecated since version 3.0! Use is_super_admin() instead. in /…/wpress/wp-includes/functions.php on line 2839
    • Warning: Cannot modify header information – headers already sent by (output started at /…/wp-includes/functions.php:2839) in /…/wp-includes/option.php on line 568
    • Warning: Cannot modify header information – headers already sent by (output started at /…/wp-includes/functions.php:2839) in /…/wp-includes/option.php on line 569

The Hack:

  • File: /…/wp-content/plugins/wp-db-backup/wp-db-backup.php
  • Replace the following line, near line 1439
if ( function_exists('is_site_admin') && ! is_site_admin() )
  • with this line:
if ( function_exists('is_super_admin') && ! is_super_admin() )

Please comment, whether you have success or not. Thank you.