Codexonics

Thanks, that’s great to hear! 🙂 Yes the hotfix script is usable as long as it is on the standalone/single-site and run by administrator with WC activated.

We are now currently finalizing the changes on Prime Mover 1.4.8 (next release) and this includes the fix for WooCommerce orders adjustment. We will release this as early as next week. So if you happen to migrate WC sites before Prime Mover 1.4.8 you can use the script to adjust/fix the orders. However using version 1.4.8 is recommended than using the hotfix script because it saves time and you don’t need to run any scripts/monitor logs/etc. But hotfix script can be used as last resort in case you need it.

Regarding other issues you’ve mentioned – sometimes those are necessary because there are plugins that are not migration friendly. This means that they are storing data that not easily transportable from one WP platform or another (e.g. from multisite to single site, vice versa).

A good example is when plugins hard code specific data (e.g. IDs, hashes, signatures, license keys, etc.) in their dB setting which might change when it gets migrated to another site. Or if they have multisite-specific setting and the plugin don’t have auto-adjust when migrated to stadnalone. It’s why re-activating/reconfiguration is needed for some plugins after migration.

Prime Mover plugin does it’s best when migrating things like this. It does search and replace (domain names, etc.), adjust vital important data (e.g. users), etc. However, it cannot handle all specialized migration scenarios introduced by all WP plugins. And this is where custom configuration after migration might still be necessary.

Moving on, I have marked this ticket as resolved since the main issue is solved. And then if you can provide us with reproducible steps (or WPRIME packages) for other problematic plugins during migration- please open another ticket so we can have a detailed look. We will handle it on our future releases if we could also reproduce it on our end and fix it inside Prime Mover. Thanks again!

Thanks, that is strange because in the log you’ve sent. It starts with

[08-Feb-2022 14:54:28 UTC] Retrieving all orders

This log output is only present before version 3.0 and version 4.0. If you’ve checked the version 4.0 code – the log string Retrieving all orders is not there.

Anyway I’ll review this again today and try to reproduce the issue that you’ve reported. Thanks.

OK just in case you want to test. The hotfix plugin script is modified to version 4.0. It’s now very simple – it simply checks for billing email and if user account exists. If it does – get the migrated user ID and set it to customer ID meta key for that order. For guest checkouts where customer ID is already 0 – it’s skipped.

To re-test – please restore to the original dB backup state first. Clear the debug.log. You can then install and activate hotfix plugin version 4.0.

Thanks and let me know if you still need assistance.

OK, the hotfix plugin script is now updated. To re-test:

• Backup your existing standalone site database.
• Download the latest hotfix plugin script.
• Install the hotfix plugin script to your standalone site.
• Make sure the hotfix plugin script is version 3.0.
• Make sure WooCommerce plugin is activated.
• Delete old /wp-content/debug.log so that the log file contains the latest logs only.
• Make sure WordPress debugging is enabled in wp-config.php.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true);

• Activate the hotfix plugin Migrate customer ID WC Orders
• Wait until the plugin is fully activated. When it does – check the logs for details and results. The log shows the total number of orders processed and all other details. It should process more than 10 orders now.
• Backup your debug.log so you will see the progress of the orders updating just in case you need to re-run it again if it hits timeout. This way we can tweak where to resume.
• Once done, check the customer accounts – orders should be connected.

That’s it 🙂 Hope this fix resolves your issue. Thanks!

Thanks, that is strange indeed. It would be hard to debug/reproduce this without looking at your WPRIME package. Can you please share the original WPRIME package in Gdrive or any file share host and then send me the link to download it? We will check your package in our local to reproduce this issue.

Once we got your package – please give us time to analyze. Thanks again.

Hi Dev,
I’ve modified the hotfix to write some logs. Please re-download it here. It’s version 2.0 so make sure you install this.

And then please enable WordPress debug first in your standalone site before activating this hotfix:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true);

Once debugging is enabled, activate the hotfix plugin. Once done – it will automatically deactivate. The log should be written to /wp-content/debug.log contains sensitive information and don’t post it publicly.

Please send it to us by logging into the standalone site and go to Prime Mover – Contact Us or you can send us via our contact form here.

The hotfix relies on customer billing email. If this is not set or not associated with a WP user , then the hotfix will not work.

Alternatively (if hot fix does not work) – during the time when you migrate the site to standalone. Prime Mover writes migration logs to ‘/wp-content/uploads/prime-mover-export-files/’ , search for file name with something like XXXXXX_migration.log as the filename. Only check the latest restore log. You don’t need to restore the site again to your standalone as this migration log should already exist there.

Download and open the log and look for the user equivalence log. It should look something like this:

`
[user_equivalence] => SplFixedArray Object
(
[0] =>
[1] => 3
[2] => 4
)
‘

This log is important because it shows the user ID before (in your multisite source site) and after (in your target standalone) migration. For example in the above sample log. User ID 1 becomes User ID 3 at target site. User ID 2 becomes User ID 4 at target site. You can use this information to manually adjust the _customer_user meta_key associated with that WC order.

We are now well aware of this issue and will be working on a permanent fix so they will automatically adjusted when migrating WC sites.

Our support timezone is GMT + 8 so in case you have follow-up questions. We will check on it with details on the next day. Thank you!

• This reply was modified 4 years, 4 months ago by Codexonics. Reason: Some typo

Hello Jack,
Thanks for giving us 5 stars and for sharing your experience with Prime Mover plugin. Cheers 🙂

Hello John,
Usually if you have this error – your server might be under powered with the current traffic you are experiencing or number of plugins/connections open at the same time. Upgrading to a more stable hosting platform is usually the best solution in this case.
Other quick solutions includes – deactivating resource hungry plugins and see if it helps. You mentioned in your original posts that the site has lots of unnecessary plugins. Maybe it’s time to review them one by one and deactivate those that are not needed. This way – you will drastically reduce the CPU and memory footprint of your site by using only plugins that you need.