|
Thomas
|
July 10, 2018 at 11:04 am
Hello,
I am using WP4.9.7 and I upgraded EE from 3.1.37.6.P to 4.9.63.p.
After the data migration process has ended without problems, the attendee info (name, address, etc) of registrations done with EE3 are not showing up anymore in the backend. It looks like that:
http://solusio.com/MissingAttendeeNames.png
http://solusio.com/MissingAttendeeNames2.png
New registrations done with EE4 are correct.
The DB tables after the upgrade contain the ones from EE3 and EE4:
=> wpNath_esp_attendee_meta shows my new EE4 registrations
=> wpNath_events_attendee shows my old EE3 registrations
All of the DB entries seem to have the correct attendee data, but the attendee data of the old registrations does not show up in the EE4 admin backend anymore.
Any help is highly appreciated.
Thanks, Thomas
|
|
Josh
|
July 10, 2018 at 11:25 am
Hi Thomas,
Was the wpNath_posts table reverted to a backup after running the migration? Normally the EE3 to EE4 migration will migrate the data from events_attendee into WP posts of the post type espresso_attendee.
|
|
Thomas
|
July 11, 2018 at 1:01 am
Hi Josh,
Thanks for your prompt feedback, your support is outstanding!
How would I see that the wpNath_posts table has been reverted to a backup after running the migration?
In any case I see that its table structure has changed after the migration.
Any other data or info I can provide to analyze this issue?
Thanks, Thomas
|
|
Thomas
|
July 11, 2018 at 1:55 am
…and yes, I see that the attendee names from “wpNath_events_attendee” are available in “wpNath_posts”, defined as post type espresso_attendees.
Though I don’t see the emails or address data in wpNath_posts, not sure if this should have also been migrated from events_attendee.
|
|
Josh
|
July 11, 2018 at 7:36 am
Email and address data isn’t actually stored in wpNath_posts. Those are stored in wpNath_esp_attendee_meta. The two tables are related by a match of the meta table’s ATT_ID value to the wpNath_posts table’s ID value.
So for example post ID 1348 should have a related entry in wpNath_esp_attendee_meta where the ATT_ID value is 1348.
|
|
Thomas
|
July 11, 2018 at 8:00 am
Yes, Josh, post ID 1348 has a related entry in wpNath_esp_attendee_meta where the ATT_ID value is 1348. This is an entry which has been entered after the upgrade.
An old entry from before the upgrade, e.g. ID 1343, can be found in wpNath_posts, but it does not show up in wpNath_esp_attendee_meta (not sure if it should).
So, the problem persists:
The attendee info from before the upgrade does not appear in the backend, just an asterisk is shown where the attendee name should appear.
Desktop backend screenshot 1
Desktop backend screenshot 2
Additional info: the attendees appear correctly in the app (iPad).
Thanks, Thomas
|
|
Josh
|
July 11, 2018 at 8:48 am
It sounds like the migration did not finish or the EE3 data had some missing rows because there should be an entry in wpNath_esp_attendee_meta for every attendee that was migrated from EE3.
Do you have another site, like a staging site, where you can re-run the migration?
|
|
Thomas
|
July 11, 2018 at 9:35 am
I ran the migration already two times, same result. I can re-ran it, but what should I am looking for? Any special output or logs which I can provide? Any trace levels,…?
|
|
Josh
|
July 11, 2018 at 11:36 am
If your web server logs PHP errors, you’ll look for an error that looks like this:
WordPress database error: [Index column size too large. The maximum column size is 767 bytes.]
CREATE TABLE wp_esp_attendee_meta [...]
In this case, before you try to run the migration again, you can contact your web host and ask them to change the MySQL installation to enable larger index columns by enabling the innodb_large_prefix setting.
After that’s done, you can go to Event Espresso > Maintenance > Reset, then use the option to delete all EE4 data. Then you can reactivate EE4 and re-run the migration.
|
|
Thomas
|
July 12, 2018 at 9:01 am
Unfortunately, there are no such PHP errors. I’ll try to adapt the provider’s webserver log settings. The provider already told me that as a shared hosting there’s no possibility to customize the MySQL settings. So, even if I can get down to and detect the logs’ error message you mentioned, I wouldn’t be able to amend the index column size…
If there’s no other solution or workaround, it seems that I have to tell the customer that legacy attendee data is only viewable via the iPad, but not in the admin backend. Or do you have any more ideas?
Thanks, Thomas
|
|
Josh
|
July 12, 2018 at 9:13 am
You’re likely going to run into other database issues with that host. Can you upgrade to one of the recommended hosts listed here?
https://eventespresso.com/requirements/
re: adapt the provider’s webserver log settings, you don’t actually need to do that. Instead, you can enable WP_DEBUG mode, with logging only (no display). We have an example code snippet here that shows the code to edit into the wp-config.php file:
https://eventespresso.com/wiki/troubleshooting-checklist/#wpdebug
You add that code in place of where WP_DEBUG is set to false, then check the debug.log file located in the wp-content folder after re-running the migration.
|
|
Thomas
|
July 14, 2018 at 2:14 am
Hi Josh,
I activated the WP_DEBUG mode, reran the migration and I can confirm that the DB errors occur as you mentioned above:
[13-Jul-2018 21:11:47 UTC] WordPress-Datenbank-Fehler Index column size too large. The maximum column size is 767 bytes. für Abfrage CREATE TABLE wpNath_esp_attendee_meta....
So far I have been very satisfied with this premium hosting company (df.eu). But if this migration problem is not resolvable from EE side, I will have to switch to another provider (which is not a minor hazzle…).
Regards, Thomas
|
|
Josh
|
July 14, 2018 at 7:34 am
The column size cannot be made smaller. Maybe your host has a plan you could upgrade to that can support innodb_large_prefix?
|
|
Thomas
|
July 16, 2018 at 7:19 am
Updated feedback from my provider:
“innodb_large_präfix = on” is set on all their servers.
So there’s another root cause to the DB error messages in the context of the EE3->EE4 migration?
Thanks, Thomas
|
|
Josh
|
July 16, 2018 at 7:48 am
The error message is fairly clear what the cause is. Can you pass on the database error message to the host so they can investigate further?
|
|
Thomas
|
July 16, 2018 at 2:15 pm
Hi Josh,
Do you mean that if innodb_large_prefix is supported, then this error message
[13-Jul-2018 21:11:47 UTC] WordPress-Datenbank-Fehler Index column size too large. The maximum column size is 767 bytes. für Abfrage CREATE TABLE wpNath_esp_attendee_meta....
cannot occur at all?
|
|
Josh
|
July 16, 2018 at 2:17 pm
No I did not write that, but your host may be able to configure the server to avoid the error.
|
|
Thomas
|
July 16, 2018 at 2:41 pm
I have passed the logs to the hosting provider.
Here is a log excerpt from the EE3->EE4 upgrade. I did the migration process several times on different servers of different hosting providers, always the same result. You advised to ensure the EE pre-requisites are met, which is the case, also for the innodb_large_prefix.
There is another article on the forum with a very similar issue.
[13-Jul-2018 21:11:47 UTC] PHP Deprecated: Non-static method HeadwayUtilityBlock::init_action() should not be called statically in /kunden/70339_2340/webseiten/solusio.com/nathal-sarti.de/wp-content/themes/headway/library/blocks/blocks.php on line 308
[13-Jul-2018 21:11:47 UTC] PHP Deprecated: Non-static method HeadwayUtilityBlock::has_menu() should not be called statically in /kunden/70339_2340/webseiten/solusio.com/nathal-sarti.de/wp-content/plugins/headway-utility-block.tmp/block.php on line 85
[13-Jul-2018 21:11:47 UTC] PHP Deprecated: Non-static method HeadwayUtilityBlock::has_shortcode() should not be called statically in /kunden/70339_2340/webseiten/solusio.com/nathal-sarti.de/wp-content/plugins/headway-utility-block.tmp/block.php on line 440
[13-Jul-2018 21:11:47 UTC] PHP Notice: Undefined variable: tags_array in /kunden/70339_2340/webseiten/solusio.com/nathal-sarti.de/wp-content/plugins/headway-sliderplus/pzsp-functions.php on line 31
[13-Jul-2018 21:11:47 UTC] WordPress-Datenbank-Fehler Index column size too large. The maximum column size is 767 bytes. für Abfrage CREATE TABLE wpNath_esp_attendee_meta ( ATTM_ID INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
ATT_ID BIGINT(20) UNSIGNED NOT NULL,
ATT_fname VARCHAR(45) NOT NULL,
ATT_lname VARCHAR(45) NOT NULL,
ATT_address VARCHAR(255) DEFAULT NULL,
ATT_address2 VARCHAR(255) DEFAULT NULL,
ATT_city VARCHAR(45) DEFAULT NULL,
STA_ID INT(10) DEFAULT NULL,
CNT_ISO VARCHAR(45) DEFAULT NULL,
ATT_zip VARCHAR(12) DEFAULT NULL,
ATT_email VARCHAR(255) NOT NULL,
ATT_phone VARCHAR(45) DEFAULT NULL,
PRIMARY KEY (ATTM_ID),
KEY ATT_fname (ATT_fname),
KEY ATT_lname (ATT_lname),
KEY ATT_email (ATT_email) ) ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci von do_action('wp_ajax_migration_step'), WP_Hook->do_action, WP_Hook->apply_filters, Maintenance_Admin_Page->migration_step, EE_Data_Migration_Manager->response_to_migration_ajax_request, EE_Data_Migration_Manager->migration_step, EE_Data_Migration_Script_Base->migration_step, EE_Data_Migration_Script_Base->_maybe_do_schema_changes, EE_DMS_Core_4_1_0->schema_changes_before_migration, EE_Data_Migration_Script_Base->_table_is_new_in_this_version, EE_Data_Migration_Script_Base->_create_table_and_catch_errors, EEH_Activation::create_table, EventEspresso\core\services\database\TableManager->createTable, dbDelta
[13-Jul-2018 21:11:49 UTC] PHP Notice: Undefined index: post_type in /kunden/70339_2340/webseiten/solusio.com/nathal-sarti.de/wp-content/plugins/headway-sliderplus/pzsp-functions.php on line 362
[13-Jul-2018 21:11:49 UTC] PHP Notice: Undefined index: post_type in /kunden/70339_2340/webseiten/solusio.com/nathal-sarti.de/wp-content/plugins/headway-sliderplus/pzsp-functions.php on line 362
[13-Jul-2018 21:11:49 UTC] PHP Notice: Undefined index: post_type in /kunden/70339_2340/webseiten/solusio.com/nathal-sarti.de/wp-content/plugins/headway-sliderplus/pzsp-functions.php on line 362
[13-Jul-2018 21:11:49 UTC] PHP Notice: Undefined index: post_type in /kunden/70339_2340/webseiten/solusio.com/nathal-sarti.de/wp-content/plugins/headway-sliderplus/pzsp-functions.php on line 362
[13-Jul-2018 21:11:50 UTC] PHP Deprecated: Non-static method SliderPlusBlock::init_action() should not be called statically in /kunden/70339_2340/webseiten/solusio.com/nathal-sarti.de/wp-content/themes/headway/library/blocks/blocks.php on line 308
Thanks
Thomas
|
|
Josh
|
July 16, 2018 at 4:07 pm
The issue in the other topic was resolved in Event Espresso 4.9.30. The main difference being in that other topic they were not migrating data from EE3, they were starting from scratch with new data. Which, as you’ve noted, your site works with new data going forward with EE4.
That said, you could try enabling compression for the row formats like what they did.
|
|
Thomas
|
July 22, 2018 at 2:28 pm
Hello Josh,
The hosting provider cannot tell me more than ensuring that “innodb_large_präfix = on” is set on all their servers.
Reg. ROW_FORMAT=COMPRESSED I am able to operate DB imports/exports via phpmyAdmin, but I am no DB expert. That said, could you provide a bit more details what could be done to avoid these errors after migrating from EE3 to EE4?
It is not clear for me when/how ROW_FORMAT=COMPRESSED should be set…before/after the EE4 migration? For which tables, etc?
Please advise. Thanks, Thomas
|
|
Josh
|
July 23, 2018 at 9:23 am
It would be set before the EE4 migration, for any new tables before they’re created. The other thread mentioned that as a solution, but I am no db expert either.
Another approach you could take is clone the site’s EE3 data onto another server (from another host) and quite likely that other server will already be configured to allow the tables to be created before doing the migration from EE3. Then once that’s migrated, you can copy over the database to your other host.
|
