Handling of absolute path during migration

For some reason that makes little sense to me, WordPress and/or some plugins use absolute paths in the database or in files.

Unlike the relative paths that are replaced by updraft plus during a restore thanks to the search/replace option when enabled, these are left untouched.

This is an issue because these can crash the migrated site, or worse cause unknown problems.

For example, Wordfence creates a user.ini file in the root directory that points to the original server. When copied as is, because the absolute path refers to the original server, it crashes the migrated site.

This file, by the way, should be automatically excluded during the migration and/or renamed, as with the WP-Config. I can’t think of a good reason to copy it as it is to a different site with a wrong absolute path in it.

So it would be great to add an option during restore to search/replace hard-coded absolute paths, both in the database and files, and ideally provide a report so that the user can see what has been replaced. This would saved the user from identifying the root of the absolute path in both the original and migrated server, and do a manual search/replace in the database. Doing so in files is a lot more difficult to automate, so it would still leave instances such as the user.ini file created by Wordfence invalid.

By the way I second the request to offer a way to exclude plugins from a restore. If you change hosting, you might not want the security or cache plugin to be restored as there might be conflicting equivalent already installed in the new host. Other might cause issues when restored, such as Wordfence. Others might have a licensed that is unique to the production site and could lead to license invalidation if enabled on another site, which could also cause issues on the production site.

Keep up the good work, Updraft Plus is great!