Support

July 24, 2024 at 8:07 pm

Thread marked resolved so re-opened here.

What thread is that? can you paste the link here?

There has been a critical error on this website. Please check your site admin email inbox for instructions.
Do you have the log for this?

It looks like there was some corruption during the migration process.
Are you moving from EE3 to EE5? Can you give us the EE3 backup you have, ill try to update that on my Local machine and try to catch the error you experience.

thanks

July 29, 2024 at 3:56 pm

I deactivated all plugins before the migration and it appeared to work but the resultant data was bad.

In this situation, this part doesn’t really make sense, well, more so this:

When I took a peek in the database, recent registrations that may have been unsuccessful created a attendee ID of 0. Several older registrations were changed to id of 0. When I looked at the attendees through EE, it said critical error on each and address card does not match. They also were not attached to the event they were scheduled for.

The reason this part doesn’t make sense is because the migration that runs between version 4.10.45.p and 5.0.XX is purely based on the venue date, it doesn’t touch the registration data at all.

Here is the migration query running:

protected function _migrate_old_row($old_row): ?bool
{
    $EVT_ID =
        isset($old_row['EVT_ID'])
            ? absint($old_row['EVT_ID'])
            : 0;
    $VNU_ID =
        isset($old_row['VNU_ID'])
            ? absint($old_row['VNU_ID'])
            : 0;
    if ($EVT_ID && $VNU_ID) {
        global $wpdb;
        // If the question group was also for primary attendees, we should just update that row.
        // And we delete this row.
        $result = $wpdb->update(
            $this->_event_meta,
            ['VNU_ID' => $VNU_ID],  // data
            ['EVT_ID' => $EVT_ID],  // where
            ['%d'],                 // data format
            ['%d']                  // where format
        );
        return filter_var($result, FILTER_VALIDATE_BOOLEAN);
    }
    return false;
}

In English, grab the EVT_ID and VNU_ID from esp_event_venue (a separate database table for storing venue relations) and add that to to esp_event_meta (a ‘meta’ table for EE data).

So it reads from a table completely unrelated to registrations and writes to table completely unrelated to registrations.

—

Now, I’m not sitting here saying that you are mistaken and it didn’t happen (it obviously did) but something else is going on there other than the migration as the query is completely unrelated to registrations.

I’ve downloaded the backup from Updraft for the 22nd, then created a new database backup and imported that database locally…. then ran the migration. Initially, I got a fatal error but that is from the custom PayJunction payment method active on the site as it needs to be updated to be compatible with the latest versions of Event Espresso.

But on checking the data within the database, those incomplete registrations (the ones with ATT_ID = 0) are already present within the database before the migration run from Jul 2nd.

So right now, I think the error you were getting when loading the Transactions was either from the PayJunction payment method fatals I mentioned above, or PayJunction wasn’t active and the transaction was looking for it to display details about it.