What a mouthful that title is! Just wait ’till you read the next sentence. If, like me, you installed a few WordPress blogs into subdomains before the advent of WordPress 3 with Multi Site features and you now want to consolidate your blogs into a WordPress 3 network with all subdomains managed from one WordPress Multi Site installation then you will need a little tutoring about how to convert your multiple blogs into one Multi Site blog network. I have successfully moved many subdomain installations into a single Multi Site installation and now it’s time for me to be nice and let you know how to do it. So grab yourself a drink and get comfortable because you could be in for long read and a few hours work if you have a big site to export. If your site is small then it will take you about 30 minutes to import to a virtual subdomain. Good luck!
Before you start you need to be aware of a few things:
- Check that the plugins and theme(s) used by your individually installed blogs are compatible with WordPress Multi Site. Most plugins and themes will function faultlessly but when they go wrong…
- A fault in any one of the sites in your Multi Site set-up could bring down your complete network. To my knowledge, the only faults that will bring down your network are plugin, theme and database related. Plugin and theme errors are easily fixed by the deletion or removal of the faulty plugin’s or theme’s files from /wp-content/plugins/ or /wp-content/themes/, respectively.
- WordPress Multi Site subdomain (and subdirectory) sites all use the same database as the parent (non-subdomain) site. It is possible to give them a database of their own and I will explain how to do that in a later article. If the database breaks try to repair and optimize it with PhpMyAdmin or whatever your host’s database management software is. Back up your database regularly.
- A regular WordPress installation (non- Multi Site) uses the default table prefix of WP_ for all of its tables. The Multi Site database is a little different: the table prefix for the first (primary/main/top) site uses the table prefix WP_ and all other sites have the table prefix WP_n_ (where ‘n’ equals a site’s number); the prefix number is usually equal to a site’s creation order and is the same as its unique storage directory’s number (under wp-content/blogs.dir). For example, the main blog uses the table prefix WP_ and the upload folder wp-content/uploads; the first addon site will use the table prefix WP_1_ and the upload folder /wp-content/blogs.dir/1.
- The deletion of an addon site will remove its table data from the database and its upload directory from /wp-content/blogs.dir. The creation of a new site or recreation of a deleted site will not fill-in any numerical gaps in the database table structure or the /wp-content/blogs.dir directory structure. For example If you delete the most recently created site and it uses wp_3_ and /wp-content/blogs.dir/3 then recreate it, it will use wp_4_ and /wp-content/blogs.dir/4; no site will ever again use wp_3_ and /wp-content/blogs.dir/3.
- Plugins installed by the main site’s administrator are usable by all blog authors if “Enable administration menus>Plugins” has been ticked under Super Admin>Options. For example, if you have 10 subdomain blogs created by 10 authors and you (the administrator) have installed 100 plugins then all 10 users will have access to all 100 plugins.
- The difference between Activate and Network Activate for plugins is:
- Network Activate enables a plugin across all sites within the network;
- Activate enables a plugin for the local site it is activated within (one site).
- Plugin settings do not cascade through every networked site i.e. if you install the TinyMCE Advanced plugin to to improve the native WordPress visual editor then the changes you make to one site’s editor will not be effected within other sites of the network. Unfortunately there is no way to enable network wide plugin settings changes, yet.
- Every subdomain or subdirectory site added to a WordPress MS network is given its own storage space in /wp-content/blogs.dir/[site number]/. Even so, some WordPress Multi Site folders are shared by all sites within the network that sit on the same domain. Those shared folders include all the ones under /wp-content except /wp-content/uploads and /wp-content/blogs.dir.
- Multi Site subdomains are virtual entities. Do not bother to look for them, you will not find them because they only exist in the site’s database. You can read more about how this is accomplished here.
- When including files into a single domain site (non Multi Site), you would usually place included files in the installation’s root directory (/) or in some subdirectory of the root directory, for example
- /an-included-file.html
- /subdirectory/an-included-file.html
Multi Site site’s function in exactly the same way. Included files are placed under the main domain’s root folder and are referenced relative to that root folder. Be careful not to muddle up the names of the files included in each of your sites.
- A virtual subdomain created with Multi Site will neither override nor overwrite a real subdomain so even if you create a real subdomain called one.domain.tld and a virtual subdomain called one.domain.tld (both have the same address), the only one that will be served to visitors will be the real one; the virtual one will be hidden until the real one’s DNS record is deleted.
Now that you’re a little more knowledgeable, let’s move onwards and upwards…
How to Move Multiple WordPress Subdomain Blogs to a Single WordPress 3 Multi Site Blog
Want to republish this content? Read the copyright notice first.. Like this, support this.
Thanks. I gave your post a plug here: http://forums.digitalpoint.com/showthread.php?t=1846977
I’m sure a lot of people will want to get up to speed on this soon.
Thank you Marketing Guy, I really appreciate it, I took a look, every plug helps :-)
Just a few additional points:
1, After each export file has downloaded, open it with a text editor (Kate, Gedit or Notepad), scroll to its bottom and ensure there isn’t an error message. If an error message exists, check the date of the last entry in the file then re-export your blog’s content from that date onwards. Check the new file too;
2, Sometimes the export/import will fail for other reasons. One likely candidate is the script execution time limit set in your server’s php.ini file. Try increasing it to 120 from whatever it is currently set to (prob. 30). The line in your php.ini file to edit is “max_execution_time = 120;”. Be sure to change it back after you have completed your blog transfer;
3, you can transfer your blog by importing the old blog’s database tables into your new blog. I will write instructions for this sometime soon.
I will add the above information into the main article when I next edit it.
hi,
i enjoyed reading your article, excellent information. i am running wp mu 2.6.5 and would like to upgrade directly to 3.0 but i’m worried that i will run into trouble.
do you think it is possible to do a one step upgrade (ommitting wpmu 2.7 2.8 and 2.9) to wp (mu) 3.0?
i’m only running 5 subdomain blogs on the mu installation, but it would be great if i don’t have to export and re-import databases manually.
thanks for help in advance
Hello Ralph, I honestly don’t know. I would install the WP Database Manager plugin, use it to repair and optimize the database before backing it up, copy the WP MU blog’s directory to a backup directory above /public_html/ (i.e create /backup), use PHPMyAdmin to create another database backup (just to be sure) then I would try the upgrade. If anything goes wrong you would thus be able to restore the copied files and restore your database.
The best place to find the answer to you question is the forum at wordpress.org. The support might be slow there but they do eventually answer.
Ralph, I’ll do some research for you and post another reply later.
Someone knows how to create again a virtual subdomain that I deleted due to a mistake?
as I know it is not possible to create again a subdomain in wordpress 3
please, some help
Thanks!
Does the deleted site’s database tables still exist? Do you have a backup of your Multi Site’s database? Many host providers automatically backup their customers’ databases, either get them to restore it or ask them for a copy of it. A restored database will not contain site updates since the backup was created. I’ll provide more assistance once you tell me what you’ve done to get the database back.
I have the database ok.
in wordpress 3 I created a virtual domain like barcelona.mydomain.com then I deleted it. and now I want to create it again but wordpress does not allow me unless I reinstall wordpress again.
Any solution?
Many thanks!
WordPress will usually let you re-create a domain as many times as you need provided it doesn’t already exist. It seems that the old domain name is still registered within your database. My suggestion is this (remember to backup/export the affected tables first). Access your database via PHPMyAdmin, click the Search tab, enter the subdomain name part of your deleted site (i.e. Barcelona), select all tables then run the search (click Go). You will then be presented with a list of tables; browse (use right-click, open new tab) the ones that contain your search string and manually remove references to the deleted subdomain. The data I would remove would be the result returned for wp_blogs and the one for wp_options. Most other tables will be the ones specifically created to for that particular blog’s use.
Thanks for your answer!.I created a real subdomain and then deleted it. Thats why now my virtual subdomain doesn’t work as you said (works dashboard but not the site)
It seems for me not easy as I don’t have experience in PHPMyAdmin, but I have to try it!
Thanks again
Searching tables but It seems ok for me, Nothing in wp-blogs or wp-options. only some tables in slimstat folder. maybe this is not the way but thanks for your answer!
I apologize for replying so late. I misunderstood your original problem. Recreate the real subdomain and the virtual subdomain will begin working again. I had similar issue with one o my domains. I wrote bout it here.
Oh!! thanks
I use google chrome and…
I try it with explorer and its working!
All this headache and was only a Chrome issue.
The other browsers are ok! I don’t know but with chrome I cannot see the site it redirects me to a plesk site…
thanks
I ran into an issue with steps 4 and 5 in your instructions. I am able to complete step 4 and create my new site as newblog.example.net, which is different from my previous site which I am migrating into as instructed.
The trouble is when I hover and click on “Backend” of the site I just created at newblog.example.net, it seems to be looking for the wp-admin file from a WP install that doesn’t exist yet. Where am I going wrong here? Did I miss a step or did you forget something in the instructions? Plz help!
Thanks
4. Go to Super Admin>Sites and create a new site. Use a name other than the name of the site being imported. For example, if you’re importing from old.domain.tld then you could create a Multi Site site called new.domain.tld but not old.domain.tld (we will change the Multi Site site’s name to the original subdomain site’s name in a later step).
5. Still in the Super Admin panel, hover your mouse cursor over the name of the site you just created and click “Backend”.
Hello RJ, does the subdomain site load when the frontend is browsed? Also, create another subdomain site and test whether you get the same reaction.
I was trying to move the theme from http://www.domain.com/wordpress to http://www.domain.com and deleted the “/wordpress” part from the backend “wordpress URL”. (all in wordpress) Now, I can not log back in to fix the problem. Do you have any suggestions?
Thank you in advance!
I’m not quite sure what you’ve done. I think you’re telling me you have deleted the files held in the domain.com/wordpress directory (the whole directory). If that is the case then you will need to either look in your deleted items folder to restore it or you will need to contact your web host and ask them to restore their most recent backup. Your web host might be able to restore that specific directory; if not you will lose any changes made to everything but your database unless the database is restored too. If you ask your host to restore the back up, be sure to ask what changes will be made so you can at least prepare for them. It is always a good idea to back up your database before a restore. Have emailed you as well.
An alternative would be to re-upload WordPress and edit the config.php file to configure the database username, password and location. Thought that would not restore any data uploaded to your WordPress installation.
WP’s import/export plugin doesn’t include settings, user data, plugin data, etc, so I worked out a different process that will migrate everything by tweaking and copying the database tables directly. I wrote up a detailed description if anyone is interested.
Ian, I read your process and I agree that it is a better (though much more complex) approach. I have read and used similar approaches in the past and intended to write an article about database migration not long after writing this one but I didn’t get around to it. Thanks for letting us all know about your article. I’m sure JournalXtra’s readers will find it interesting.
Thanks so much for a really thorough and helpful post. So useful.
Nice work!
::-)
Thanks Henry, it’s nice to be appreciated. I followed your website through to the Back to the Future games you worked on. The games were fun and the artwork good :-)
Thanks you… you are a real true contributor to the WordPress community.
WordPress Multi Site subdomain (and subdirectory) sites all use the same database as the parent (non-subdomain) site. It is possible to give them a database of their own and I will explain how to do that in a later article.
It is indeed possible but I don’t advise it.
The WordPress database table has record names that look something like this: wp_options, wp_posts, wp_comments… (I’ve not checked those names for accuracy). Additional sites on the network use the same database table but their records have names that look similar to these: wp_1_options, wp_1_posts, wp_1_comments… The number represents the numerical ID of the blog/site within the Network. Though it’s possible to use separate database tables, each with its own login details, not all plugins use separate records per site.
For example, The Multipress plugin installs one record as wp_multipress. That same record is used for all blogs/sites on the network. It uses a field within the record to store the site/blog’s ID.
wp_1_options => data, data, data
wp_1_comments => data, data, data
wp_1_posts => data, data, data
wp_options => data, data, data
wp_comments => data, data, data
wp_posts => data, data, data
wp_multipress => data, data, data
So, although it is possible to use separate database tables, it’s not necessarily advisable unless you can be sure that the plugins used by a particular site/blog in the network uses separate records for each site/blog that has its own database.