Support

May 22, 2023 at 2:53 am

Hi Brad,

Thank you for contacting us.

Can you please let me know what error you see while upgrading?

Also, please share a direct link to the event page so that we can check the issue for you.

Looking forward to helping you.

May 22, 2023 at 9:05 am

EE4 converts your shortcodes to the ‘new’ format during the migration.

[ESPRESSO_EVENTS] for an event list is the new format we use so now your running EE3 again it doesn’t know what those shortcodes are for.

Do you have the fatal error that was thrown during the migration?

May 22, 2023 at 9:34 am

OK, so I assume you still looking to switch to ee4?

If so reactivate it and continue on with the migration, without the fatal I can’t say what will have gone wrong but EE4 will give you the option to continue the migration and try to pick up where it left off.

May 23, 2023 at 4:50 am

Why is the plugin file version named Event Espresso 5.0.5.p – is that actually v4?

Yes, EE4 has had a new event editor add and a lot of the code updated for PHP8.

It’s a major version number bump but is still ‘Event Espresso 4’. We named EE4 the way we did in the beginning, to differentiate between EE3 and EE4, but eventually will likely just have ‘Event Espresso’ at whatever version number it may be at.

Not sure how to proceed with the choices we see – as follows:

Those options are within Event Espresso -> Maintenance -> Reset/Delete Data, thats not the migration options.

Is that the only section you can see?

Can you add a screenshot of what is available?

Just sent you the crash report with errors from the migration we attempted from v3 to v4 the other day.

Thank you, the migration report shows the ‘usual’ errors we expect (things like ‘Couldn’t find X so used Y’) and also a fatal error status, but it does not contain the fatal itself which likely means your server is set not to display errors.

Do you have FTP/File Manager access to the site?

May 23, 2023 at 6:40 am

What do you see on the maintenance tab (top left of that screenshot)

May 23, 2023 at 7:40 am

Does Event Espresso 4 require PHP 8?

No, the min PHP requirement is PHP7.4

Ok, so that last screenshot will allow you to continue with the migration.

However, before proceeding, I recommend enabling WP_DBEUG_LOG so if another fatal is thrown it’s logged and we know where to look.

Edit the sits wp-config.php file and look for:

define( 'WP_DEBUG', false );

Replace that single line with the snippet here:

https://eventespresso.com/wiki/troubleshooting-checklist/#wpdebug

That tells your site to store errors within /wp-content/debug.log

Then on that screenshot above, click the ‘Next Step’ link, which should take you to a page that allows you to continue the migration. If unsure of how to proceed add a screenshot fo what you see and I’ll walk you through it.

May 23, 2023 at 11:03 am

Attempted Reset of Event Espresso Tables from the Reset/Delete Data tab.

I didn’t say click to Reset/Delete Data, why did you chose that option?

May 23, 2023 at 11:34 am

You didn’t provide any other option and that seemed to be the best choice out of the ones that were there.

Sure I did, in the reply above HERE, clicking the ‘Next step’ link would allow you to continue the current migration.

This is your last screenshot with the ‘Next step’ link:
https://monosnap.com/file/vszf7nD8j5d4wc0ERGM62gvgYyBk2q

We need to migrate v3 data to v4 as was clearly explained early in this thread. Can you provide the fix for this?

I understand and the option I gave you above would have done exactly that but now that the tables have been reset there isn’t migration to allow you to continue with.

—

Ok, before moving forward, do you have a Database backup from before the migration and do you have one from ‘now’?

If you don’t, create at least the one for now. It’s important not to skip creating a backup as you’ll be manipulating the database a fair amount from here dropping tables, if something goes wrong the only way to get that data back is with a backup.

Once you have a backup, you’ll need to restart your migration from scratch again by completely dropping EE4 tables, if you have a backup from before you ran the migrations you can revert the site to that would be best, but if not…

Go to Event Espresso -> Maintenance -> Reset/Delete Data.

Click the ‘Permanently Delete ALL Event Espresso Data’ button.

This drops all EE4 tables.

Once complete, reactivate Event Espresso 4+ and you should be offered to restart the migration over again. Follow the steps to migrate over again and as you have WP_DEBUG_LOG enabled if it throws a fatal again we should be able to track down that error.

May 23, 2023 at 12:26 pm

I did click the next step link and it didn’t allow me to continue the migration.

Again, that’s why I said to let me know what you see in that same reply and I’d walk you through it, I guess I wasn’t clear.

The options you see depend on the migration step you are on so I needed to see the page to know what to click.

The link didn’t say that v3 tables would be reset, only v4.

Your documentation also said that v3 database data would still be available.

That’s correct, the EE3 tables have not been reset by the above.

EE3 tables use the events_ prefix.

EE4 tables use the esp_ prefix.

EE4 entities are also a custom post type so data is also stored within the wp_posts table.

None of your EE3 tables will have been lost, but the migration that was running pulling EE3 data into EE4 has now been lost because you’ve reset the tables. So the migration from EE3 -> EE4 needs to start again.

We have a site backup that we can restore from dating back to before all of these changes and I think we will restore from that point, and then you can address the issue with v3 that we have had for quite some time where event dates are not being set correctly,

EE3 is no longer updated, it receives security updates only and now that EE4 supports the majority of use cases that EE3 does it will likely be phased out over the next 12 months.

June 1, 2023 at 7:27 am

So generally when the date/time output is different from whatever is set within EE its because something is calling date_default_timezone_set() to change the servers timezone.

WordPress (and therefor Event Espresso) expect the server timezone to be set to UTC and then an offset is applied on display based on your sites settings. If something within the site changes that timezone it throws off the output.

Do you have any other plugins that work with dates?

First create a database backup, just to be safe.

Then what I would do is use the WP Health Check & Troubleshooting plugin to check the output with only Event Espresso running.

Install and activate the above, then go to Tools -> Site Health -> Troubleshooting -> Enable Troubleshooting Mode.

What that will do is disable all plugins and switch you back to a fault theme, but only for you, the logged in admin.

Then in the admin bar at the top go to Troubleshooting mode -> Manage Active Plugins.

Enable Event Espresso and check the output of the dates/times. Are they correct?

Try switching from the default theme to your sites normal theme (again within the troubleshooting menu bar items).

Check the output again.

Then work through your site’s active plugins, enabling them one by one in troubleshooting mode and refreshing the page with the event date on until it stops displaying correctly, you should then find which plugin is causing the timezone to shift.

Post that here.

When finished in Troubleshooting mode, click ‘Disable Troubleshooting Mode’ in the admin menu again to switch the site back to normal.