Thanks for the feedback and the log. We’ve checked it and it seems you are using the old version of the hotfix plugin script that will process only 10 orders with incomplete logs.
Can you please make sure you are using Version 4.0 of the script? You can download the latest version here.
To re-test – please restore to the original dB backup state first. Delete old versions of the hotfix plugin script and install version 4.0. Clear the debug.log. Once it’s sure it’s version 4.0 – activate the hotfix plugin script.
Version 4.0 processes all orders with complete logs. Please let me know if you still need assistance. Cheers.
Thread Starter
dev
(@devksec)
Unfortunately this is with version 4. The previous versions log output was different, so you can tell it’s the version 4 of the script.
I’ve taken an exact clone of the broken site and reran the latest each time.
Thread Starter
dev
(@devksec)
Just to confirm, the cloned sites are new each time so as is needed above to perform a new test.
Thread Starter
dev
(@devksec)
Having the same list of 10x order loops in a single debug.log is new and something isn’t working in the V4 of the script.
V4 appears to fix the first 10 orders (then loops back and breaks) but v3 runs for all of the orders.
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.
Thread Starter
dev
(@devksec)
Apologies, it seems debug.log didn’t enable so the old logs were sent over by mistake. This was an issue our end.
I’ve manually checked and I can see changes on older than 30+ orders. V4 was run however no updated logs.
I’ll rebuild a test site and rerun again.
It’s OK, no problem 🙂 I’ve also updated the hotfix script to version 5.0 with minor changes from v4 – run the code on plugin activation hook. This is to make sure it will run once only then deactivate the plugin automatically after processing. Also append hotfix version number on the log so we will know what version is running.
So when you run version 5.0 – it will show the version number like this in the log:
[10-Feb-2022 10:51:41 UTC] RUNNING VERSION 5.0 OF THE SCRIPT!
You can download version 5.0 here. Thanks!
Thread Starter
dev
(@devksec)
Works perfectly !
[10-Feb-2022 11:33:58 UTC] NO MORE ORDERS TO PROCESSED.
[10-Feb-2022 11:33:58 UTC] DONE PROCESSING ALL WOOCOMMERCE ORDERS.
[10-Feb-2022 11:33:58 UTC] THERE ARE AROUND 1621 ORDERS PROCESSED.
[10-Feb-2022 11:33:58 UTC] DEACTIVATING HOTFIX PLUGIN SCRIPT…
We’ve got more woocommerce stores to migrate. Are we ok to use this script as part of the restoration checks (original issue list? We can wait until fixed in the prime version depending on time frames etc.
Also, are there any recommends for the other issues we had? We’re going to trial these steps next:
1. Reactivating/deactivating all plugins
2. Remove/reinstall the core problematic issues
3. Reimport existing plugin configs for any missing configs or known issue ones
4. Clean re setup for the core problematic plugins
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!
Thread Starter
dev
(@devksec)
Awesome, thanks for all of your help.
I’ll feedback any other core issues when we do our next migration, otherwise will fix adhoc
Thread Starter
dev
(@devksec)
Hello,
We’ve ended up migrating the standalone back to a multisite installation due to too many issues with the site.
Using prime mover export from standalone to subsite, we have the same issue.
Can we get a plugin to fix this for the reverse (E.G standalone > Multisite) instead of the Multisite > Subsite thats temp fixed via the plugin.
Hi Dev – we have now the latest Prime Mover beta version that will automatically adjust these data during migration. We recommend using the beta version instead of the hotfix script.
To fix this in any of your sites (whether from standalone to multisite or vice versa) – please take note of the following procedures:
At origin (source site):
- Download the latest beta version here.
- Deactivate Prime Mover 1.4.7.
- Delete Prime Mover 1.4.7
- Install and activate Prime Mover 1.4.8-beta version
- Double check that the WC order – customer data is correct before migration to another site. This will ensure source site data is already correct.
- Generate export using Prime Mover.
- You should have now the updated exported package.
At target site:
- Download the latest beta version here.
- Deactivate Prime Mover 1.4.7.
- Delete Prime Mover 1.4.7
- Install and activate Prime Mover 1.4.8-beta version
- Restore the latest exported package using Prime Mover 1.4.8-beta
- Wait until the restoration is completed.
- Once completed – all WC orders data should be correctly adjusted.
This should fix issues relating to WC orders/customers after migration as long as the source site data is already correct.
We will be releasing an official Prime Mover 1.4.8 version hopefully this week. But for now – please use our latest beta version in your projects. For your update. Thanks!
Thread Starter
dev
(@devksec)
Hello,
Thanks for sending that over, however we’re not able to remigrate the stand-alone to subside.
We weren’t unaware that this bug was a two-way issue before migrating from stand-alone to multisite.
Could we get a multisite version of the patch plugin please? We can use the beta version for the upcoming migrations which is great but one store has already been migrated back.
Sure no problem 🙂 Please give us time to review the latest hotfix script again and modify it for multisite compatibility. I will update here once this is ready. Thanks for the update.
Thread Starter
dev
(@devksec)
Awesome ! Thank you again.
