Support

Support Staff

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 2:45 pm

Hey Josh, I’ve followed you recommendations, made sure other plugins are disabled and allocated additional memory to WP and I am still getting the same result. I’ve emailed (support@eventespresso.com) the resulting “report” generated by EE from a different email address referencing this ticket. Did you get it? It was sent on May 27th. I also tried pasting it here but I guess it’s too large and wouldn’t submit.

In addition I am not seeing any errors that are related to the migration in the debug.log.

Thanks,
AJ

Tony

Support Staff

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 6, 2016 at 3:43 pm

Thanks Tony for the reply, I’m seeing the following in my debug.log file now:

[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
[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

I do not see any entries in php_errors.log.

Thanks,
AJ

Tony

Support Staff

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 11:09 am

Hey Tony, the EE4 files on this install have not been modified. It was a clean migration started from a backup taken prior to the install of EE4. The EE3 version that this site is being migrated from does have some customizations. Those customizations are in a custom plugin which was disabled prior to starting the migration.

Thanks,
AJ

Support Staff

June 7, 2016 at 2:43 pm

Hi AJ,

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

June 7, 2016 at 3:13 pm

Hey Josh,

I don’t believe so. The customizations on this site are all dealing with promo codes so shouldn’t get involved with the event data.

Thanks for looking into this,
AJ

Support Staff

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 5:23 pm

Hello Michael,

Thanks for taking a look at this. I’ve emailed the Crash Report as requested. I did try Tony’s suggestions and have also set the migration size to 10 as requested.

Thanks,
AJ

Support Staff

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 10:29 am

Hey Michael,

I set the EE_MIGRATION_STEP_SIZE to 1 and re-ran the migration via the method you recommended It fails pretty much right away. I don’t see an event number to reference and have emailed the crash report to the support address again.

Looking at the events_detail table I don’t see any events with ids 85 to 95. it skips from 77 to 188 but maybe you mean the 85th – 95th event and not revering to the event id?

Unfortunately this site is on my local system and not accessible to the outside world. I could do a screen share. I’m on Pacific Time.

Thanks,
AJ

Support Staff

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 9, 2016 at 2:36 pm

Hey Josh,

I’ve exported and sent in the requested tables to the support address.

–AJ

June 10, 2016 at 10:56 pm

Support Staff

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 13, 2016 at 5:04 pm

Hey Michael thanks for your efforts here. I have stopped all EE plugins except for core and retried the migration. I’m still getting the Unknown fatal error. I’ve sent in the latest crash report.

I will try migrating in another environment and see what happens there.

Thanks,
AJ

June 13, 2016 at 5:20 pm

Hello Michael,

I continue to get the error in the other environment as well.

Thanks,
AJ

June 15, 2016 at 12:13 pm

Just following up on this I’m still unable to complete this migration… I would like to get this resolved.

Thanks,
AJ

June 15, 2016 at 12:36 pm

Support Staff

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

Support Staff

June 15, 2016 at 1:52 pm

Hey AJ here’s a branch that resolves two of the errors I saw while running a migraiton on the dataset you provided: https://github.com/eventespresso/event-espresso-core/tree/BUG-9839-fatal-error-and-other-errors-migrating-from-ee3.

Unfortunately I’m not reproducing the fatal error so I’m not too confident it resolves it for you. But could you re-attempt your migration using this branch?

(If it still fails, do you have a public test site you can try running the migrations on too? Maybe try the migrations there too. If it fails on that other server, then you can grant us access to help debug it; if it works on that other server, then it must be an issue with your particular setup)

June 15, 2016 at 5:45 pm

Hi Michael,

I understand the challenges of not being able to reproduce the issue. I’ve tried with the branch you suggested and I’m still getting the same results. I do have a public site you can have access to and have emailed in the address and creds to the support address. Unfortunately I can’t give you access to cpanel or MySQL so it maybe a little limiting.

Thanks,
AJ

Support Staff

June 15, 2016 at 6:01 pm

It is fairly limiting to only have admin access to the site. Is there a way you can send temporary FTP access to the plugins directory for that site?

June 16, 2016 at 10:47 am

Hey Josh,

I have forwarded some additional creds to the support address that grants FTP access to the root of the install.

–AJ

Support Staff

June 16, 2016 at 2:18 pm

Hey AJ the FTP user you sent us only has permission to read a file named “.ftpquota” and that’s it. Is it an easy fix to grant it more permissions (specifically to view and edit the WordPress files for the site in question)?

–update: nevermind, I think I’ve found the problem, and using ye old barbaric WP plugin editor is ok

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

Support Staff

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…

Support Staff

June 16, 2016 at 2:59 pm

ok I got the problem fixed and migrations running ok. It seems we need to run the data through $wpdb->strip_invalid_text_for_column() before trying to insert it (so far I only adjusted the code to do it when inserting EE4 events during the migration; but I suppose we should really be doing that before any insertions… I’m a little surprised WordPress doesn’t just do that automatically).

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

Support Staff

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 8 years, 7 months ago by Michael Nelson.

June 21, 2016 at 12:16 pm

Hey Michael,

Thanks for getting to the bottom of this. I think the unrecognized characters came about during the transfer and migration of the database onto the testing platform. I’ll see if I can sort this out as I’ll need to make sure I’m not going to run into this issue when I migrate the live site data. And will want to run the migration myself to make sure there aren’t unexpected issues.

Thank you for all of you assistance.
–AJ