|
David Pensato
|
February 17, 2015 at 4:39 pm
I’m having the same issue stated here: https://eventespresso.com/topic/event-espresso-4-6-migration-stuck-at-0/
The following PHP errors appear when I turn debug on:
Warning: Invalid argument supplied for foreach() in [path]/wp-content/plugins/event-espresso-core-reg/core/helpers/EEH_Autoloader.helper.php on line 183
Warning: Invalid argument supplied for foreach() in [path]/wp-content/plugins/event-espresso-core-reg/core/helpers/EEH_Autoloader.helper.php on line 183
Memory allocation is fine (as mentioned in this post: https://eventespresso.com/topic/ee4-migration-problem/).
I have the latest version of everything.
|
|
David Pensato
|
February 17, 2015 at 4:49 pm
addendum: I did not have the latest version of everything, apparently.
EE was not at the latest version. Upgraded to latest. So the PHP error is gone, but the issue remains.
|
|
Tony
|
February 18, 2015 at 4:44 am
Hi David,
Is there no error message at all when you run the migration now?
You could try adding this:
define( 'EE_MIGRATION_STEP_SIZE', 5);
to your wp-config.php file, the migration will take longer as it will run in smaller steps, but may show where the error is.
|
|
David Pensato
|
February 18, 2015 at 6:07 am
That is correct. No error message. I’ve added the line to wp-config.php and am running the script now. I’ll keep you posted.
|
|
David Pensato
|
February 18, 2015 at 7:12 am
It seems as though the migration doesn’t even really get started. That said, when I look at the system information tab within the maintenance section, I do see that in the “ee_migration_history” section, at the end of the”_org_options_we_know_how_to_migrate” block, we get:
_records_to_migrate 55
_records_migrated 55
The block right after that is where we get:
_records_to_migrate 724
_records_migrated 15
It is related to shortcodes, given:
“_old_table devpure_posts
class EE_DMS_4_1_0_shortcodes
Every block after that has:
_records_migrated 0
I’m guessing this means that its hanging at shortcode migration.
Note: I’ve left out all the other details from those blocks (stuff like “_pretty_name” and “class”). I’ve also left out “_errors” because they do not list anything at all.
Let me know if you need any more information in order to help me out.
In the mean time, I’m going to take a look at the database and see if there’s something silly in the ee tables like a reference to an incorrect URL (the site has been migrated to a dev url for this upgrade).
|
|
David Pensato
|
February 18, 2015 at 7:27 am
Nothing silly in the database.
|
|
Josh
|
February 18, 2015 at 8:58 am
Hi David,
Can you revert back to the backup of the database from before the first migration attempt? Then before running the migration, you:
1) Deactivate EE3.
2) Ensure you have the current version of EE4 installed.
3) Disable WP_DEBUG
4) Activate EE4 and run the migration.
|
|
David Pensato
|
February 18, 2015 at 10:01 am
Well that got me… somewhere. I did keep
`define( ‘EE_MIGRATION_STEP_SIZE’, 5);
in wp-config, so that helped in seeing the progress happening:”Migrated 5 records successfully during Shortcodes”. It got through to 2% (815/35081) during “Core Data Migration to version 4.1.0” and has once again stopped.
I guess this confirms the previous report: looks like it has something to do with the shortcodes.
I’ve left the window open for now, but should I attempt navigating away and resuming?
|
|
David Pensato
|
February 18, 2015 at 10:08 am
Actually, looking at the “ee_migration_history” now, it looks like we made it through Shortcodes:
_records_to_migrate 724
_records_migrated 724
and got stuck at gateways:
_records_to_migrate 38
_records_migrated 36
|
|
Josh
|
February 18, 2015 at 10:35 am
Hi David,
Does this site use a payment method/gateway that’s not included with Event Espresso 3?
|
|
David Pensato
|
February 18, 2015 at 11:15 am
Nope. It only uses Paypal Standard.
|
|
David Pensato
|
February 18, 2015 at 11:37 am
Also: the fact that it hung on Shortcodes previously would suggest that something else is at play.
|
|
Josh
|
February 18, 2015 at 12:08 pm
Hi David,
I discussed this with Mike, who built the migration tool, and he said that there may an issue sending the ajax requests to proceed. I can advise trying the migration with all other WordPress plugins deactivated, along with temporarily switching to the default WordPress theme. Along with that, you can add some additional insurance that errors during the migration requests don’t interfere with the AJAX by adding the following to your wp-config.php file:
@ini_set( 'display_errors', 0 );
|
|
David Pensato
|
February 18, 2015 at 1:39 pm
Seems to be working well now, though slowly, because I still have it processing 5 records at a time.
It was hanging again until I did one more thing:
I hunted through the options table (which I hadn’t done previously) and deleted all ee related rows. Then I exported only the rows that were relevant from the working ee3 site db to the new site db (e.g.: I didn’t copy rows for gateways I’m not using). There seemed to be a fair bit of cruft in there.
Thanks for your help in this. It would be nice to know what exactly went wrong in the first place (just because I like to know— I’m sure you’d rest easier knowing too), but clearing absolutely everything out of the db seems to have fixed whatever corruption crept in from the script on the first run.
I’ll confirm once the script finishes that everything worked out.
|
|
Josh
|
February 18, 2015 at 2:51 pm
Hi David,
Reverting back to the backup of the database from before the first migration attempt would also clear out the cruft too, right?
|
