Support

Joomla never stores absolute URLs. All of the URLs it stores are relative to the home page. Furthermore, Joomla never stores absolute filesystem paths. It always stores paths relative to the site's root. This lets Joomla be transferred to subdirectories, subdomains, new domains and different servers without a problem.

WordPress, on the other hand, still lives in 1998. They store absolute URLs and filesystem paths. Even worse, these absolute references are inside data serialized with PHP's serialize function. Due to its nature you can't simply unserialize this data and replace the references. Unserializing the data requires running inside WordPress and, in fact, having loaded the exact plugin which has generated the data. However you can neither run WordPress before you replace the absolute URLs and file system paths (therefore creating a chicken and egg issue!), nor do you have any programmaticaly useful indication of which plugin generated which data. Therefore WordPress, as it stands, cannot be transferred to a new directory, subdomain, domain or server without external help.

The WordPress Plugin Directory has several tools which purportedly help with that. However, they really don't. They all use regular expressions which work in some cases but not all. All of them invariably end up with corrupting some data in your database, losing you some functionality of your site, or worse. We solved this problem by writing our own tokenizer for serialized PHP data, allowing us to perform an accurate data replacement in serialized data. That's what is being used in the data replacement step. This is what we're doing to help you transfer a WordPress site just like you would with a Joomla site, a feature not present in any of the other backup software for WordPress.

However, a site is NOT just files and database data. It runs through a web server (Apache). WordPress, like Joomla, needs to use SEF (fancy) URLs like /foo/bar instead of unsightly non-SEF URLs like index.php?some=1&thing=2&or=another. But PHP only works with the latter. Therefore you need to have a transformation of the former to the latter. This is where the .htaccess file comes into play. It tells Apache how to handle URLs that it would otherwise not be able to figure out how to route through the index.php file of the site.

WordPress being an unnecessarily complicated beast it stores the relative folder path of its installation inside the .htaccess file. We do try to replace that too during the data replacement step, but there are a few limitations. The .htaccess file is not so much of a configuration file as a programming language. As you understand, it's not possible for a computer to accurately figure out the intent of free form text -be it prose, verse or programming language- and perform operations based on intent. Therefore we have to resort to making assumptions and educated guesses. All of that goes out of the window when you try to transfer a site from the subdomain's or domain's root to a subdirectory for two reasons:

• The subdomain's or domain's root relative path is denoted with a forward slash: / This is just as a non-specific target for data replacement in the .htaccess as anything you may find.
• .htaccess files cascade. Therefore the main site's .htaccess is parsed BEFORE the one in the "temp" directory and they are both merged and executed. This ALWAYS causes problems with SEF URLs. This is not specific to WordPress, it also happens to Joomla and we do warn you to never do that.

TL;DR. There is an easy way out

As we've been saying to our Joomla clients for a decade, do not use subdirectories of your main site to create temporary / dev sites. Instead, create a subdomain.

Danger, Will Robinson! When you are creating a subdomain the default behavior of cPanel is to create a subdirectory inside public_html. You do not want that! The correct approach is to go to cPanel's File Manager first and create a new directory temp_html next to (not inside of) public_html. Then go ahead and create the subdomain. cPanel will ask you where to store the subdomain's files. Choose the temp_html directory you had created.

Now you can restore your site in the subdomain you created and you will no longer have any pesky .htaccess problems causing the directory to appear twice in the URLs :)

You're welcome and thank you very much for your kind words :)