Support

May 26, 2016 at 1:35 pm

Hi AJ,

You can check the server’s error logs to see if the actual fatal error was captured. Beyond that, the generally helpful things to do in this case are:

1) You deactivate all other plugins
2) You try bumping up the amount of memory available to WP

before re-starting the migration.

June 2, 2016 at 3:02 pm

Hi AJ,

I’ve had a look through your log files and unfortunately they don’t show anything useful.

Debug.log sometimes doesn’t catch all errors thrown so I would recommend checking within the servers error log. Usually within and error_log, error.log or a similar file within the root directory of your site.

Looking within your report it looks like your error log should be within /srv/log/php_errors.log but you may also have some form of error report within your hosts dashboard.

(Side note, I would recommend against posting logs such as these on the forum as its public. There’s nothing particularly sensitive in the logs, but it will reveal information about your server setup which is best kept hidden)

You could also try setting the migration step size to a low value to confirm if this is a memory issue. Add something like:

define( EE_MIGRATION_STEP_SIZE, 10 );

To your wp-config.php file and see if the migration causes a fatal error.

Note this will make the migration take a LOT longer as its stepping through smaller amounts of data each time. (You can change it back to 50 or remove the above after the first stage migration has completed and before you start the next)

June 7, 2016 at 6:38 am

Those errors were not included within the previous debug.log

I’ll check in with our developers on this and see what feedback they can provide.

Was this a clean migration or did you continue on from the previous attempt?

Has Event Espresso been modified at all on that site?

If you remove the current version of EE, download the latest version from your account page, install that through:

Event Espresso -> Plugins -> Add new -> Upload Plugin
(Do not use FTP to upload the plugin)

Then retry the migration and confirm if any errors are thrown.

June 7, 2016 at 2:43 pm

Hi AJ,

Did the customizations for EE3 alter any of the database tables used by EE3?

June 8, 2016 at 11:21 am

Just to confirm AJ, did you try tony’s suggestion? To add
> define( EE_MIGRATION_STEP_SIZE, 10 ); To your wp-config.php file and see if the migration causes a fatal error.

If so, could you please re-send the system status info (go to WP dashboard -> Event espresso -> maintenance -> System Status, and copy the textfield’s contents and send them to support@eventespresso.com again). It might now contain some more useful information in it.

(FYI looking at the code, the warning [06-Jun-2016 21:28:37 UTC] PHP Notice: Undefined variable: guid in /srv/www/xxxxxxx/htdocs/wp-content/plugins/event-espresso-core-reg/core/data_migration_scripts/4_1_0_stages/EE_DMS_4_1_0_events.dmsstage.php on line 215 comes up because we were unable to insert a new EE4 event.
When that happens, it should be recording that info to a wp option, which is part of the “System Status” info I asked you to re-send).

June 8, 2016 at 10:17 pm

Thanks got it AJ.

So it seems the migrations are somehow dying when migrating the 85 – 95th events from EE3. Also, the warning you mentioned earlier indicated it was somehow unable to insert some events.

Is there anything out of the ordinary with events 85-95? Do they have large images? Or are some columns’ values unusually large? If you were to instead set define( EE_MIGRATION_STEP_SIZE, 1 ); we will be able to know exactly which event is having trouble and causing the crash. (Pro Tip: you don’t need to actually restore to a backup, you can make this change, and then on the 2nd crash report page there is an option to reattempt migration/continue migrating.).
Could you try that, and then send us the details of that event from the db? Or provide us with server credentials and I can take a gander myself

June 9, 2016 at 2:29 pm

Hi AJ,

If you can send a dump of the database tables that have _events_ in their table names Mike can investigate further.

June 10, 2016 at 10:56 pm

Hey AJ I loaded the database you sent me into my localhost setup too and tried running the migrations. I haven’t finished the migrations yet, but I got well past where you were that had the fatal errors (you didn’t finish migrating events, I have).
I noticed you had a ton of addons active. I wonder if those might be interfering. I’d suggest trying to run the migrations with only Event Espresso core active.
If that doesn’t work, please re-send your crash report when you’re using a step size of 1. I’d like to know the exact event your isntall is choking on when running the migrations

June 15, 2016 at 12:36 pm

Ya sorry AJ, it’s tricky because it’s working fine for me. I did notice you have venues with an apostrophe in their name so maybe that’s exposed a bug. I’ll publish a branch with a fix related to that you can try soon

June 16, 2016 at 2:40 pm

aha- I think I found it. Somehow the events that aren’t getting saved to the DB have some unrecongized character (it appears as ? when I echo it out to the screen, but in adminer it doesn’t appear at all). When I manually removed it from the EE3 event, the event got inserted into EE4 format just fine (but then I had the same problem migrating the subsequent EE3 event)… trying to work out a more general fix…

June 16, 2016 at 3:33 pm

Anyways, you can change EE_MIGRATION_STEP_SIZE to something bigger now, like 100 or 200, because it does take a LONG time doing one at a time

Bah, I just temporarily hacked the code and got it to go faster. The migrations are done on that site so you can give it a whirl. We’re going to also internally test the fix and then put it in the next available release. (I may also open a WordPress core ticket about this too, because IMO if there are invalid characters when making an insertion, it should just remove the invalid characters and continue the insertion, not abandon the insertion and give no explanation).

You no don’t need to use this branch of EE4 anymore, you can use the normal master version from now on. And we no longer need FTP or WordPress Dashboard access.

Anything else needing to be resolved?

• This reply was modified 7 years, 10 months ago by  Michael Nelson.