Okay... In this case, I'm going to have to say I ROCK!!!

You do not want to know how I did what I did to get this to work. It's a total nightmare.

The great news is I was able to create an exact copy of your LIVE website with it's own database, source files, and images. Any changes you make on either the LIVE site or the NEW site are completely independent of one another.

I posted the new website information in the Hidden Information section of the Question. Basically, it's http://web.domain.com. Just replace domain.com with your real domain name.

For the benefit of other readers desperate enough for a solution, I'll post the detailed steps in a follow up answer.

Thanks,

David Carroll

DISCLAIMER: Proceed AT YOUR OWN RISK!!!

The following details are meant to help people who are in desperate need of creating a staging WordPress website or migrating to a new location and the WordPress Import and Export feature isn't working for them. I've done this many times myself and make use of special scripting tools and custom built utilities to aid in this process. There aren't a lot of online resources that walk you through this process and for those guides that do exist, most are just wrong or leave out critical steps.

For those who review these steps and cannot complete them as presented, these notes may be useful for a developer to reference. Best of luck!!!

Always Backup MySQL Database and Website Files if you proceed. Again, Proceed At Your Own Risk!!!

Advanced Steps to Create a Mirror Copy of an Existing WordPress Website

Objective Notes:

The steps in this guide apply to what I did for the website on this thread. The actual domain name has been replaced with domain.com. The objective of this technical walk through is to create a staging copy of the LIVE WordPress website to apply a complete redesign which is schedule to be released at a future date. Once completed, the LIVE website will be taken down and replaced with the updated Staging Website. The challenge is WordPress Export / Import utility doesn't work well as presented in this thread. Hopefully this guide will provide people great assistance in this process as a LAST RESORT.

Prepare New Subdomain: web.domain.com

Step 1: Go To CPanel (or the website management tool your host provides) and create a new subdomain called "web". Set the Document Root to /public_html/web/, where /public_html/ is the name of your root web folder with public access. Some servers name this /htdocs/ and so on.

Copy Files from Live Site to New Sub Domain Folder: /web/

Step 1: From CPanel (or other admin app) open your File Manager app and highlight all essential folders and files in the /public_html/ folder used by your LIVE website.

Example of File and Folder Names:
- /public_html/wp-admin/
- /public_html/wp-includes/
- /public_html/wp-content/
- /public_html/wp-config.php

...and so on and so forth.

Step 2: From the web based File Manager app, click the "Copy" button and specify destination to be:
- /public_html/web/

This will move all essential files to the new Document Root created in Step 1.

Setup new MySQL Database:

Step 1: From CPanel (or other admin app), open MySQL Database Manager to create a new database and take note of the name. Assign the same MySQL username used by LIVE WordPress Database. In this setup, I also assigned the MySQL User all privileges to the new database.

Step 2: From CPanel, open phpMyAdmin, select the LIVE WordPress Database, select Export, and run the Export to File.

Modify SQL Export File:

Step 1: Apply Search and Replace on SQL Export File to add "web" to "domain.com" and "public_html"
This step is quite involved and requires a great deal of Regular Expressions guarantee you do not apply the "web" to domain.com where domain.com is used as an email address or in a sentence.

The gist of this step is to complete the following Find and Replace steps in the following order with the rules listed:

• Replace: public_html with public_html/web ( 21 Replacements )

• Replace: public_html/ with public_html/web/ ( 11 Replacements )

• Replace domain.com with web.domain.com ( 3,055 Replacements )

  • Where domain.com is not any of the following:
    
    • "www.domain.com" (prefixed with "www.")
    • " domain.com" (preceded by a space indicating it is used in a sentence)
    • "@domain.com" (preceded by an @ sign indicating it is used in an email address)

• Replace www.domain.com with web.domain.com: ( 4,153 Replacements )

  • Where www.domain.com is not preceded with a space indicating it is in a sentence.

The result is 7,245 replacements of 7,378 possible matches. What makes this tedious without regular expressions is not applying "web" to (domain.com or public_html) to the 133 instances where domain.com is used an email address or in a sentence, not a link.

Step 2: Fix Serialized String References in SQL Export File.
What a nightmare... This is the part where life starts to get painful. WordPress makes use of what is called serialized strings. This single concept is what makes migrating WordPress or any PHP platform that utilizes serialized strings so painful.

For instance, many plugins and WordPress itself saves many settings in a single database field using a pattern similar to the following simple example:
Setting Owner: Dashboard Widget Options:
- Setting: 'home' => 'http://domain.com'
- Serialized in Database and in SQL Export file as:

a:4:{s:24:"dashboard_incoming_links";a:5:{s:4:"home";s:17:"http://domain.com"; ... and so on for a total 917 characters.  

Specifically, when making the change to:

s:17:"http://domain.com";  

By adding "web.":

s:17:"http://web.domain.com";  

Will make all settings in this database record impossible to read / load in PHP. The reason is the s:17 means PHP expects 17 characters between the quotes that follow. By adding 4 new characters with "web.", the new string value has 21 characters and needs to be updated accordingly:

s:21:"http://web.domain.com";  

In the case of this website, there were 201 instances in serialized strings that had to be updated. In some cases, http://web.domain.com might be in a longer string, multiple times, looking something like:

s:2432:"Insert a bunch of text <a href="domain.com/somepage/">Some Link</a> continue with a bunch of text and other links.";  

If s:2432 is not updated to reflect the exact number of characters between the quotes that follow, the entire string cannot be loaded.

Now imagine having to review this for 201 instances in a SQL Export File with 11,260 lines. Although I presented what needs to be done, this is a daunting task for anyone to overcome and do it accurately.

I have faced this issue before and have written utility scripts that gets this done in seconds. However, the script isn't something that is user friendly and requires tweaking on a site by site basis. So it only took me a few minutes to complete.

Importing SQL File into New Database:

Now that the SQL File is fully prepped for the new sub domain all paths and images are pointing to the proper new locations, you can import the modified SQL scripts into the new database.

Step 1: From CPanel, open phpMyAdmin, select the NEW WordPress Database, select Import, select the modified file on your computer, click "Go".

Step 2: Update wp-config.php file via FTP Client or CPanel File Manager code editor so the following database names are updated properly:

// ** MySQL settings - You can get this info from your web host ** //  
/** The name of the database for WordPress */  
define('DB_NAME', 'your-db-name');

/** MySQL database username */  
define('DB_USER', 'your-db-username');

/** MySQL database password */  
define('DB_PASSWORD', 'your-password');  

Only other file to consider updating is the .htaccess file. However, based on what I saw, nothing needed to be modified for the staging setup of this new website.

Converting Staging Site to LIVE Site:

After applying the redesign via WordPress interface, the final step is to modify the web.domain.com to become www.domain.com.

Without going into every possible detail, follow the summary steps below:

Step 1: Repeat the steps above that involve exporting the new database to a file.

Step 2: Open the New SQL Export file, search for "web.domain.com" and replace with "www.domain.com".

Since the number of characters are the same, no need to revisit the serialized string issue.

Step 3: Import Modified SQL File into a New Database. See note above on how to do this.

Step 4: Copy all new images from /public_html/web/wp-content/uploads/ folder into /public_html/wp-content/uploads/.

Step 5: Copy any new plugins from:
- From: /public_html/web/wp-content/plugins/plugin_name/
- To: /public_html/wp-content/plugins/plugin_name/

Step 6: Copy any new themes from:
- From: /public_html/web/wp-content/themes/theme_name/
- To: /public_html/wp-content/themes/theme_name/

Step 7: Update wp-config.php file with new database values.

Hi Natalie,

I'm one of the volunteer WordPress Support Moderators and just saw your question.

Please provide a link to your website so we can review this more closely.

If you are comfortable providing us admin access to both the new and old websites, I would be happy to attempt the steps and see what might be going on.

You can privately send us any information by Editing your Question, clicking the link starting with "Add hidden information" and then provide the access information.

Best Regards,

David Carroll

Hi David!

Thanks for your speedy answer. I have updated the question per your instructions. If you need anything else, please let me know. I very much appreciate you looking into this for me.

Thanks a million!

Nat

Natalie,

Sorry about the delay. I took on quite a bit of support tickets and all seem to be quite involved. I'm going to do a quick review of your issue now and let you know if I anything stands out.

Specifically, I'm going to export the content from your first site and import into your development site.

Let me know if you are up and available for questions.

Thanks,

David Carroll

Natalie,

I meant to send this last night. However, I have been so busy today. Here are my notes from late last night:

Tested Imports using Default WordPress Theme:

I also attempted to complete these imports using Twenty-Ten, one of the default WordPress themes. This was to eliminate any concern that YOOtheme was causing an issue with the import process.

Possible Issue with Custom Post Types from third party Plugins:

I spent quite a bit of time on your site last night. Ultimately, the issue is due to the various "Custom Post Types" created by various different Plugins. I saw failed import notes referencing Custom Post Types from the WP E-Commerce and Next Gen Gallery Plugins.

I noticed those error messages disappeared during an import attempt when I activated WP E-Commerce and installed Next Gen Gallery on the new site. However, not a single post was successfully imported into the new website.

Possible Issue with Custom Meta Fields from third party Plugins:

I tried running the imports by extracting only the Posts or the Pages from WordPress. In both cases, no import errors were reported. However, no new Posts / Pages were imported either. My guess with this is there are several other plugins that have added additional custom Post Meta Fields that appear on Posts and / or Pages. Examples are HeadSpace, Disquss, All In One SEO Pack, Post Expirator, Related Posts and YARPP.

Typically, these custom Post Meta Fields should not cause issues. However, I can't rule that out since these Posts / Pages are still not getting imported.

Import via Custom Database Scripts:

I spent a couple of hours starting on a custom SQL Import script from the main website to import into the new website. I was able to import this into a new database on your server via CPanel and updated the the wp-config.php file on the new site to use this new database.

Working with SQL Scripts from WordPress is tricky for several reasons I'll spare you in this response. Ultimately, the goal is to change references to your first site and replace with your new site. However, it's more complicated determining which references in the database scripts to apply the update to. For example, in your case, your update requires changing link references from the root domain to the root domain plus a sub folder: Your currentsite.com changes to currentsite.com/testsite/. This also applies to records in the database scripts
referencing your server paths where you need to change /public_html to /public_html/testsite/. The public_html change is straight forward. However, adding /testsite/ requires reviewing each line this is being added to. For example, you cannot add /testsite/ to yourname@currentsite.com, which ends up as yourname@currentsite.com/testsite/. Hence, the case by case review of replacing this. Now apply this to the 8,000 instances to review in your DB SQL scripts.

This is actually not as complicated as several other challenges with this conversion. Ultimately, I stopped allowing myself to go down the "Rabbit Hole" in fear I would spend several more hours on this.

Possible Solutions To Review:

Having established the great deal of effort I've applied thus far, I do have some options you could attempt to test and report back on.

Possible Solution 1:
Install all the plugins on the new site exactly as you have them on the current site. The new site only has a handful of plugins, while the current site has many. Then export Pages Only and attempt to import. If this works, you will see the page count increase from 15 to 51 pages. Current site has 36 pages.

If that works, then attempt to export Posts Only and import those into the new site. If that works, you'll see an increase from 5 to 83 posts. Current site has 78 posts.

Finally, attempt to import the Products, and the last Custom Type generically named as Posts.

Let me know how successful you were with this. One thing to note is your imported content will not update any links that reference the current site in links and image references. This could be a mess to fix and may require a plugin to assist with this.

Possible Solution 2:
WARNING: Following Explanation is quite Technical
I'm not a fan of the WordPress Export / Import process at all. Rather, I think the absolutely best way to do this is to setup a second domain that points to the same /public_html/ folder as your current website. This second domain needs to have the exact same number of characters as your current site. If you have currentsite.net, that would be perfect for a live domain like currentsite.com. Otherwise, you may change it to currentsit4.com or currenttest.com or something like that. This will only be used for staging purposes.

Then, we can export your current SQL Database, do a quick search and replace and upload the new SQL Scripts to a new database. I would then update your wp-config.php file so that requests coming in for currenttest.com will use the new database and requests coming in for currentsite.com will point to the original database. The net result of this is you can configure your new website without affecting the live site database. When you are ready to do the switch over from current site to new site, I can export the SQL scripts from your newly configured database, change all references back to the primary domain, and setup a third database.

We can then make a one line update to the wp-config.php file to begin using the new database where all image references and links will automagically work.

Whew... that was a lot to explain. As you can see, moving a website or creating a staging website is simply not easy and requires a developer to assist. If you want to proceed with this option, let me know if you have a domain we can work with and I'll help you with next steps.

Possible Solution 3:
Setup a mirror copy of your website and have it run locally on your computer. This requires downloading all folders, files, and images of your current website. You'll also want to export the SQL Database and import it locally. The local installation would run on either MAMP (for Mac) or XAMPP (my personal choice). You'll then need to update your computer host files so that any request to currentsite.com is pointing to your local installation. Make all changes to your staging site until it's where you want it. Then, upload the files and database to a new website account and repoint your domain to the new website.

This is actually my preferred method. However, setting up a local running instance of a web server on your computer is not simple for most people. Updating HOST files are not something people are comfortable doing either. Therefore, Possible Solution 2 is a hybrid option where you leverage working with a running website.

In Closing:
I don't think any of the options are good or simple. I have a deployment process that works well with Solution 3. I only listed all these options because you are targeting a release date of the new site in about a week. I wanted you have some options to allow you to move forward. If I completely lost you... you can shoot me

Let me know your thoughts.

Thanks,

David Carroll

WARNING: DO NOT INSTALL THE PLUGIN BELOW

I was going to mention another option that allows you to test your new theme where the new theme only loads for Admins logged in. Therefore, general visitors will continue to see your current site.

The problem is I've never used this plugin and it has not been updated since 2010. Several people have reported this plugin has killed their site running WordPress 3.2.1 and up.

If you are curious about the plugin I'm referring to, you can check out Theme Test Drive on WordPress.org and view the author site: Theme Test Drive on Prelovac.com. Just don't install it.

Yuck... the options are just not that great.

Thanks,

David

David! Wow, first of all thank you for spending so much time on this! It seems to be a royal pain due to all the plugins I have!

As I had mentioned the release is happening shortly and i honestly don't think I have time to try a lot of stuff before the release date.

So I'm wondering if I can do a mini nuclear option here...

What if I:

• set up the new BigEasy theme as best I can with just some basic pages (i would copy and paste the bare minimum of what I need from current site) and not import anything from the current site in the import fashion I tried earlier
• somehow move the old site to a subfolder and keep it there to then try to work on some of the tactics above to get the posts out. The pages I can lose and all the gallery images and products as I can rebuild those.

Do you think it's possible to _essentially save the current site by moving it into a folder and then porting the BigEasy theme build to root and then work from that?

Essentially tho, if this is not easily doable, I can just nuke and start from scratch. I could manually copy over the text and images when I have more time as long as the current site is somewhere where I can access it.

If so, let me know what steps to take to move the current site down into a new folder.

I don't want to port the newsite/ BigEasy build into root until the 16th as I have blasts going out about the pre-order and I need the front page to remain as is until the 16th.

Hopefully this makes sense, if not let me know.

Again, I can't thank you enough for the time you have spent!

Thanks,
Nat

I like how creative you are with your suggestions. However, moving the current site to another folder changes the path of your root site from currentsite.com to currentsite.com/newfolder/ which inherits all the same problems previously described.

Since you need to keep your current site active until the release date, I think Option 2 is still the best option. It will still require my assistance.

Only thing you need to do is get a staging domain that has the exact number of characters as your current domain. I will update your CPanel to support this new Domain and setup the staging database for you.

You can then work backwards and start to remove what you don't want on the new site.

What do you think about that?

Hi David,

Unfortunately I don't have a staging domain name I can use. Also I would feel soooooo bad taking up your time. I know you are not being compensated for such a huge task as this. You have already been way kind with your time and to impose more I feel just would not be right. If I had a proper budget in place to do this and could pay you, I would, but I just don't feel it's fair or right to ask you to spend your time and resources.

Maybe I should just take this as a sign and rebuild the site from the beginning (using fewer plugins clearly!) It's not going to be the end of the world and it seems like whatever way we go to save the current content it's gonna be a royal pain.

I think this might be my best option... just nuke it and start again.

It's Ok... new beginnings are a good thing!

Thanks for recognizing the challenge of this effort and for being so considerate of my time. I also understand how stressful it can be when challenges in technology get in the way of running your business. It's the reason I launched a fully managed platform for hosting websites on WordPress. We basically take care of these kinds of challenges and try to make things much easier. We're still working on getting it launched to the public.

Anyway, I completely understand your concerns. If you are going to start rebuilding from scratch, let me review two other options that will allow you to keep your current site online just before switching over to the new site. However, these options require you to rebuild the new site.

Please, don't blow anything away anything just yet.

Thanks,

David Carroll

David,

I have a glimpse of how hard website tech is just from building and running a few small sites, so I really appreciate your time and understand that it is valuable.

I have until the 16th to save my data, images and any really important pages, so I will begin doing that. Right now I'm in the thick of mailing out preorder CDs so I have my head stuck in mailing labels, CDs, sharpies and mailing envelopes! I will start to focus on the rebuild tomorrow. I'm going to grab important content from the old site and build the new one on that subfolder for now.

You've really been a gem and I appreciate your time. If you like pop music let me know and I I'll send a few digital album packages your way if you like as a small token of my thanks!

Thanks,
Nat

Okay so... I just had an epiphany. Before I get to that... Let me warn you that if you build your new content on yoursite.com/folder/, you'll still need to migrate this to the new site path when you go live on yoursite.com (without /folder/). One fix for this is to create something called a redirect in a file called .htaccess so all requests to yoursite.com automatically goes to yoursite.com/folder/. However, the _/folder/ will be visible in the new site. I'm not a fan of this for a long term marketing strategy.

Since you are buried with your preorder stuff, I'll test something on the server and see if it can be ready by morning. If not, proceed as planned.

Also, the digital album would be awesome!!! I have a wide range of music preferences. Is it kid friendly? I have young daughters who love pop music .

Thanks,

David Carroll

Hi David,

Usually when I do this I port to root and it works. I've done it a few times and it's been OK If I keep the initial build stupid simple, it should be OK I'm guessing, right? Usually I just have to change a few things in the config file and then go back over the site to check to make sure there are no broken links. I can actually add the store on after the site is live, it's only a few products.

Let me know how your tests go.

Yes, all my music is kid friendly! I'll put an album bundle together for you and send that over hopefully later tonight to the email address I had from last night.

Thanks,
Nat

OK, wow! YOU DO ROCK!

Hey David,

How about exporting posts & pages from a site.wordpress.com site to a self-hosted, yootheme Wordpress site where the import function seems to work, but actually does not import any posts, pages nor media?

Ailie,

Technically, you should be able to export your posts and pages from the hosted WordPress.com site and import into a self hosted site. However, any number of issues can cause problems for you on the import.

You said:

the import function seems to work, but actually does not import any posts, pages nor media

What sort of messages did you receive leading you to believe the import should have worked? After uploading the XML import file, did you come to a screen asking if you wanted to download the images from the remote server to your new website? I can't recall the exact phrase, but it's something to that effect.

Before we continue this dialog, I recommend you open a new question and post a link here so I can be notified.

The current question has been answered and your issue is very different.

Thanks,

David Carroll