Part Four: Deleting The Real DNS Record
This is the final, and most hazardous, part.
When both a real and virtual subdomain exist with the same name the real subdomain’s DNS record must be removed to enable the site hosted by the virtual subdomain to show when viewed with a web browser.
Typically (with cPanel, anyway), the deletion of a subdomain’s DNS record does not delete the files within the directory the DNS record is created against. If you want to be safe, back-up your real subdomain’s files before proceeding. I accept no responsibility for your actions!
As you likely created your original subdomain, I’ll leave you to work out how to remove it (this is not the one created within WordPress MS). Usually this involves clicking “Subdomains” in your web host control panel (e.g. cPanel), finding the relevant subdomain (e.g. old.domain.tld) and deleting it. Do not delete its directory, just its DNS record.
Once the real subdomain has been deleted, point your browser to the new version of the old site. The address will be the same as the old subdomain (e.g. old.domain.tld). If it doesn’t load it means something has gone wrong or you’re looking at the wrong URL – take corrective steps.
Check the URLs. Make sure the browser address bar shows the same URL for the posts viewed as would be displayed were you viewing the site at the original (real) subdomain, ensure links still point to their proper places, check that images load properly and link properly. Delete the real subdomain directory if you’re satisfied the new Multi Site site functions as it should and that you no longer need any of the files contained within it.
Recreate the subdomain DNS record if you want to revert to the original (real subdomain) site (backup the directory first). If you do revert back to the original version of the site, you can safely remove or deactivate the virtual WordPress subdomain site from your Super Admin control panel.
You have done incredibly well if you’ve come this far. You should be proud of yourself for successfully transferring your old subdomain installation to a new WordPress Multi Site controlled virtual subdomain installation.
And, now, after writing these 2731 words during most of today’s hours, I am going to get back to setting up my new website which advertises my WordPress Installation and Set Up business – yes, I can be hired to do this for you. Prices vary according to the size of each individual site and the number of individual sites to be relocated. Conversion of a main blog to WordPress Multi Site and the transfer of a small real subdomain site to a WordPress virtual subdomain site typically costs only £99.95. Use the contact form to learn more.
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.