• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Plesk Migrator won't migrate sites made with Plesk Wordpress Toolkit

Dynamic Hosting

New Pleskian
We are using Plesk Migrator to merge a small older server together with a newer one. Both are running the most recent version of 12.5. The sites that were created with Wordpress Toolkit (using APS app) have fixed DB names that conflict with each other so that we can't effectively merge those sites.

For example when Plesk Wordpress Toolkit makes it's DB names they are very similar like: 'wordpress_b' then 'wordpress_c' and so for each server there are many with the same DB names as they are not random. As far as we are aware there is no way to change those names (you can recreate a new WP instance and then dump and load the DB to a new unique names DB but that doesn't solve the issue as the original DB is still there and can't be deleted without deleting WP totally and can't be migrated as a result.

So is it true that with no way to rename or disconnect the DB there is effectively no way for Plesk Migrator to migrate sites that Plesk made by way of the Plesk Wordpress toolkit ?
 
Hello!

Thank you for feedback! We have a plan to implement a feature PMT-1098 which will allow to rename database and database users during migration and automatically fix configuration files of the most popular web applications, like WordPress, Joomla, etc., but it will be implemented approximately at the end of July. If you can wait so long, you can perform migration without any manual operations, like renaming or dumping/restoring.
 
@Dynamic Hosting (and to @Aleksey Filatev for notification)

You already posted more or less the same on this topic thread and, luckily, your first post above does contain the quintessential details necessary for a proper answer.

It has nothing do to with Plesk Migrator, the problem arises from your desire to merge WP instances.

In essence, Plesk Migrator is intended to merge data (i.e. subscriptions) as a whole, not to "merge data", implying that you more or less use the wrong tool for the job.

Sure, I agree personally that Plesk Migrator should be a tool with more functionality, certainly when taking into consideration that it is rsync based.

But let´s have a look at your question:

So is it true that with no way to rename or disconnect the DB there is effectively no way for Plesk Migrator to migrate sites that Plesk made by way of the Plesk Wordpress toolkit ?

The answer is twofold, mainly because your question is not entirely adequate. Let me explain.

Yes, it is true that databases cannot be renamed: this is "proper practice", data is to be migrated as a whole.

This "nasty inconvenience" follows from the fact that data is being migrated as a "sort of backup file", which fact is quite odd if one uses rsync to actually transfer data.

Nevertheless, any other migration approach would not be able to change database names, unless the target server (for migration) has a script to execute tasks on migrated data.

No, it is not true that "there does not exist a way to migrate WP Toolkit based sites with the Plesk Migrator".

In fact, you can migrate data from a WP instance on the source server to the target server: the only thing is that all data remains the same.

This implies that merging data by means of the Plesk Migrator is not a task that can be done, Plesk Migrator is intended to migrate data, not merge data.


Having stated the above, one relevant misperception should be taken away by now, implying that we can focus on the actual root cause of the problem.


Your issue actually concerns merging data from the source server to the target server.

As such, this case implies two things:

1 - you have existing WP instances on the source server
2 - you have existing WP instances on the target server

and, actually, point 2 is where the problem originates.

In fact, the root cause of the problem has nothing to do with Plesk Migrator, it is only related to the method used for creating the WP instances on any Plesk server.

Let me explain by giving you two cases.

Case A: if you use Plesk Migrator to a target server, on which a particular WP instance does not exist (at all), no problem will arise. Everything works fine.

Case B: if you use Plesk Migrator to a target server, on which a WP instance exists, problems will arise, if the WP instance on the target server is equivalent to that of the source server.

Why the result in case B?

Well, that is the root cause of the problem: whenever using the APS catalog to create a WP instance, a new database prefix is being used.

The bug is actually that database prefix, including custom database prefixes, are not being used and replaced by some random string of characters as a prefix.

In your case, the presence of an existing WP instance on the source and target server implies that both WP instances have a random database prefix, not being equal to each other.

That is a result of the before mentioned bug (read: custom database prefixes are not being implemented).

You can replicate this bug by creating a test WP instance and specify a custom database prefix at creation time, which prefix will not be used in the wp-config.php file (check that).


And that is simply all there is, even though it should be noted that many cases are possible: for the sake of simplicity, I left almost all cases out of my response, but in every way and in every case the before mentioned bug will be an issue.

Finally note I reported or mentioned the bug many times to Plesk Team, to no avail.

I certainly hope that this bug will be tackled, before Plesk Migrator gets revised (otherwise, it would not make any sense at all).


Anyway, hope the above helps and explains a bit.

Regards......
 
Thanks Aleksey, you seem to understand the issue at hand well and I appreciate that it's something that is in the queue to be fixed up soon. Our migration can't wait until the end of July as it's on the critical path of a project that has important milestones before then. Are there any other options?
 
Hi trialotto, I do appreciate your taking the time to comment but I'm not sure you understand what I am trying to say. This is a very normal type of thing that a customer would want to do (migrate WP sites from more than one server to a target) so I am glad it's something that has been identified as an issue and is on the backlog to be resolved in the near term.
 
@Dynamic Hosting

I do understand what you are saying.

Problem is that

- feature PMT-1098 is planned for multiple months now (without any result)
- the bug (database prefix) is not resolved, even though Aleksey Filatev (and other Plesk Team members) are aware of it

and the two problems will be interrelated.

In fact, Aleksey Filatev gives you an answer to a question that you didn´t ask. And this answer is a promise that has been made for many months, without becoming concrete.

As long as you are not understanding the above, it does not make any sense to provide you with solutions that currently are available.

Anyway, one "partial solution" can be provided:

1 - just use rsync in a script, to merge (not migrate) WP instance related files,
2 - just use the "Export Dump" function to move databases to the new server,

and with point 2, I do mean the "dump function" in the phpmyadmin panel (since you should export all databases applying to WP instances).

Really, instead of waiting for a new Plesk Migrator OR using Plesk Migrator, the steps in point 1 and 2 are much faster (and more reliable in many dimensions).

Regards........
 
trialotto, I've worked at large and small companies, i understand how deadlines can often be pushed, it's a reality that sometimes can't be avoided. The fact that the Plesk team is aware of the issue and is working toward a resolution is what is important in my view (it could be worse, some software companies don't understand or admit issues and they never get resolved as a result).

I also appreciate your effort to help but in our case we have many hundreds of sites, with many having being made via created via the Plesk Apps / WP tool so it's unrealistic to consider a manual process / fix for each one.
 
@Dynamic Hosting

Strange, given your experience, you should know that the whole process requires nothing more than 1 rsync command (with appropriate flags) and some time to transfer and merge all new files (from source server into target server) and one export script for MySql, which should take a couple of minutes.

It surely is not a manual site-per-site process that I proposed, that would be time consuming indeed.

By the way, I am not sure why you would want to merge data since the endresult would still be that you obtain an exact copy of the source server on the target server.

You can migrate all data from the current source server(s) to the target server, Plesk Migrator works like a charm for that specific purpose.

Just delete "old domains" (read: those that you wanted to merge, but actually should be migrated) on the target server and run Plesk Migrator for those domains: it will be fine.

The above process becomes a little bit different if you already made some changes to the WP instances on the target server.

If the changes are only file related: just create a dummy directory and move all existing files to that directory, migrate from source to target server and use rsync to "merge" data of the dummy directory and the actual directory (that contains the migrated data).

If the changes are database related: just create a dummy domain, the most practical way is to rename domains (possible, when changing some settings), migrate from source to target server (migrated data is in the original domain, changed data is in the renamed domain) and, again, use rsync to "merge" data (from the dummy and original domain) AND point the WP instance to the database of your choice.

Note that it is not good practice to first change data and the migrate, one should first migrate to create a non-production copy, which can be changed to your desires (and Plesk Migrator can be used to sync other data like files or mail).

Nevertheless, I am not sure why you have a problem with Plesk Migrator, while I and many others do not have the same problem.

And really, I migrated a lot of WP instances in order to test the WPT AND the Plesk Migrator for bugs. In essence, "a lot" is the understatement of the century.

I do know that some of your problems resemble problems that were actually bugs in the (far) past, so please verify your packages.

Regards......
 
I do wholeheartedly vote for database rename feature in Plesk, where do I sign-up?
As for merging the migrated data, the new Plesk migrator is a really nifty tool and a great improvement from the old pleskbackup/pleskrestore era, however it's not suited for large migrations where you're dealing with large numbers of customers. What drives me nuts when running copy-content is the excessive time spent with all sorts of redundant checks and other operations, when in theory you just need to rsync the increments and dump/restore the databases. One of the problems with merging is that, most of the times, the Unix uid/gid isn't similar on both source and destination server, hence why simple 'rsync -avz --delete --numeric-ids [...]' doesn't cut it. After merging you need to adjust the ownership on the destination server and this is what plesk-migrator is supposed to do. Only, it does it at a snail pace :)
I'll detail my recent experience with Plesk migrator on a different thread, though. I think there's room for improvement here.
 
Back
Top