WordPress and its plugins store several references to the site's URL and path structure inside the database, either as text or as "serialised data". The latter is a special encoding format used by PHP to allow developers store structured data in a database text field. As you're painfully aware, this data is extremely difficult to modify when you are transferring your site to a new directory, subdomain or domain. Well, not any more. Our restoration script, ANGIE, includes our renowned technology to safely replace thes references in your database, be it text or serialised data. The replace data page is designed to do exactly that.
ANGIE for WordPress - The replace data page
The first section of the page is called Replacements to be made and lets you specify which data to replace and what to replace it with. It is automatically populated with the site's URL if ANGIE detects that you are restoring to a different directory, subdomain or domain than the one you backed up from. If you need to add more replacements (for example, change references to the title of the site) you can do so by using the From and To text boxes. Text of each line of the From box will be replaced with the corresponding line of the To box: first From line with first To line, second From line with second To line and so on.
The second section is called Database tables. By default ANGIE will only replace data in specific core WordPress tables where we know for sure there are data to be replaced. If you want to extend the data replacement to other tables, for example those used by third party plugins, select them from the list. You can use CTRL-click (Windows, Linux) or CMD-click (Mac OS X) to select individual tables. Clicking on a table name and then pressing CTRL-A (Windows, Linux) or CMD-A (Mac OS X) will select all tables.
![[Tip]](/media/com_docimport/admonition/tip.png) | Tip |
|---|---|
|
If you are not sure what to do here just leave all tables unselected and click on Next. If after the restoration is complete you see that some plugins reference data from the site you backed up from you can redo the restoration and select all tables here. |
Finally, click on the button to let ANGIE write your site's new configuration and display the final page.
Data replacement and WordPress multisites
WordPress allows you to create multisite installations. These fall under three broad categories:
-
Installed on the root of the domain, using subdomains for the multisites. For example: http://example.com (main site), http://child1.example.com, http://child2.example.com (child sites).
-
Installed on the root of the domain, using subdirectories for the multisites. For example: http://www.example.com (main site), http://www.example.com/child1, http://www.example.com/child2 (child sites).
-
Installed on a subdirectory of the domain, using subdirectories for the multisites. For example: http://www.example.com/myblogs (main site), http://www.example.com/myblogs/child1, http://www.example.com/myblogs/child2 (child sites).
The Replace Data page is aware of these kinds of sites, as well as non-multisite installations, and will automatically include the necessary replacements required to transfer your site to the new location. However, you cannot convert all types of multisite installation to another, or convert between a multisite and a single installation due to restrictions in how WordPress works.
You CAN NOT convert from a Type 1 site to a Type 2 or 3 site and vice versa. In other words, if you have a multisite with subdomains it has to remain a multisite with subdomains. If you have a multisite with subdirectories it has to remain a multisite with subdirectories (you can only move it between the root of the domain and a subdirectory).
You CAN NOT restore a multisite installation with sudomains to a subdirectory. WordPress only allows this type of multisite installation in the domain's root.
You CAN NOT extract a single "site" from a multisite installation. In fact, these "sites" are not real "sites". WordPress is merely employing some fine trickery to give you the illusion of multiple sites. All of the sites are weaved together. You can try to restore the full multisite installation, delete all sites except the one you want and use some instructions of dubious quality you can find on the Internet to kind-of-sort-of convert the multisite WordPress installation to a single site installation. According to client feedback this is a hit and miss operation. It's usually better to export the content and import it to a new site (and put a lot of work to rebuild the new, single site installation to resemble your old site).
Technical notes on data replacement
Unlike competitors we do not use fragile regular expressions with dubious results to modify serialised data. Our software does a full parsing/tokenisation of the serialised data, replaces the data and then reconstructs the serialised data format in a way which is absolutely compatible with the way PHP handles serialised data. Therefore, unlike our competitors, our solution works with any kind of serialised data without risking data corruption.
Furthermore, our data replace solution uses our renowned stepping algorithm to make sure that there is no PHP or server timeout while replacing data in your database. Competitive solutions try to handle an entire table or, worse, and entire database at once which only ever works with very small sites. Our solution can work with tables and sites of any size. If it can be backed up, it can be restored. The algorithm used is the same in both cases.
There are only three limiting factors outside our control.
The first limiting factor is a limit on the number of database queries per hour or per minute which may be imposed by your server. Replacing data requires reading your entire database contents in memory, replacing the data and then writing the changed contents back to the database. If you get an error while replacing data please contact your host and ask them to temporarily raise the queries per hour limit for your account. A limit of 100000 (one hundred thousand) queries per hour is enough on most servers. They can restore your much lower limit after the restoration is complete.
The other limiting factor is that data can only be replaced on tables having a primary key. In any other case it will be impossible for your database server to know how to write the modified data back to the database. We have applied a workaround which works in most such cases but be advised that there might be a very rare occasion where some data might not be replaced.
The final limit is the maximum execution time / maximum CPU time allowance. Parsing serialized data is an intensive process. We have taken all steps possible to minimize the amount of work your host's processor will need to perform during that step. However, if you have very large blocks of serialized data (around 1Mb or more) you may run into a situation where either the PHP execution time limit is reached or the host blocks your IP temporarily due to excessive CPU usage. There is not a whole lot we or you can do about it. Doing something difficult requires effort. If your host doesn't let their server expend that effort the work can be done, ergo the site cannot be restored. Sort of using a different host or a more expensive hosting package (with higher execution allowances) there is nothing you can do.
Finally please note that the data replacement only works for database data. Data stored in files cannot be replaced. Storing configuration in files is very rare in WordPress plugins since most developers use the WordPress API which stores configuration in the database. Therefore we consider this case to be extremely unlikely.