Support

November 10, 2016 at 7:25 am

Hi Nigel,

The version running is 3.1.32.P

This is most likely the cause of the problem if you are using the latest version of WordPress.

WP 4.2+ introduced some security fixes that caused problems when creating tickets if the ticket name was too long (basically the row was created but nothing actually saved in that row)

If you create a new event and look at the pricing within that event do you have multiple ‘default’ prices?

(You should only have 1 price when you create a new event, any more shows the issue above)

November 10, 2016 at 9:27 am

Hi Nigel,

The change that was made to WP 4.2 is present in WP 4.6. You’ll need to update to current version of EE3.

November 14, 2016 at 1:29 pm

Hi Nigel,

Here are the steps to get back on track:

1) Backup your WordPress site

2) Pull a copy of the live site into staging. As you are upgrading from an old version of Event Espresso that is several years old, I recommend testing the migration on the staging site first

3) Get a copy of Event Espresso 3 here: https://github.com/eventespresso/event-espresso-legacy/archive/3.1.37.10.zip

4) On the staging site, deactivate the old version of Event Espresso 3 and upload and activate the new version above

5) Check the events on the staging site to ensure that things appear to be in order. You should see your events and the pricing should work

6) If things look good, then deactivate Event Espresso 3 and then upload and activate a current version of Event Espresso 4 and then run the migrations and then Event Espresso will move itself out of maintenance mode

Caching does not run on the staging site but it does on the live site.

You should exclude your Event Espresso pages from caching:

https://eventespresso.com/wiki/setup-nocache-exclusion-rules-event-espresso/

For Event Espresso 3, they can be found in Event Espresso –> General Settings –> Pages.

For Event Espresso 4, they can be found in Event Espresso –> General Settings –> Critical pages

—
Lorenzo

November 30, 2016 at 6:28 am

Notice the number of events in EE3 is only 81 –> http://prnt.sc/ddfyvx

That’s a total of 81 Active and Ongoing events.

After migration to EE4, the total number of events went up to 267 –> http://prnt.sc/ddfze6

That’s a total of 267 Active, Ongoing, and Expired events.

2. Our site is composed of several (perhaps around a hundred) pages that is linked to a particular event in EE3. We found that each link after migrating to EE4 were un-usable since the particular ID of the event has changed. Compare two screenshots above. An example of the link to EE3 is http://pillowmain.staging.wpengine.com/the-tours/events/?ee=236

You can either change the links and update them to point to the migrated events or set up redirects. The Redirection plugin is recommended as an easy way to set up redirects.

December 2, 2016 at 8:53 am

1.All events have been made “inactive” after the migration. Do we need to re-publish each and every event we have?

No, active EE3 events should be active in EE4.

2. It seems that all Events’ start dates have all been set to 29 November 2016 which is the date when we migrated from EE3 to EE4. The original start date were not carried over!

This will likely be linked with 1 as the dates should migrate over.

Something is tripping up the migration on your site which is breaking the datetimes and likely the cause of a lot of the problems you listed after the migration.

3. With regards to the redirection, this doesn’t makes much sense as it’s like manually changing all old EE3 urls to the new EE4 urls. However, the only thing I can see if we do the redirection is that, it won’t hurt our current seo standing. So do you prefer to do a redirection instead of changing links?

EE4 uses a completely different URL structure to EE3 as the Events are now custom post types, its not that the ID’s are different (although they certainly will be) but EE4 events are not pulled in the same way EE3 were.

So you can either alter each of the pages that have the URL hardcoded into them, or setup a redirect for that URL to point to the EE4 event. The latter would be the quickest option.

4. Attendees seem to have been saved but see the difference in these screenshots (are there any difference with regards to the quota of tickets being sold from EE3 vs EE4)?

Tickets do work differently in EE4 but again as something is breaking during the migration its hard to say if those values are correct. EE4 does not show a sold/available column like EE3 did, it just shows the total of Approved registrations for the event.

Migrated registration take this into consideration and should be assigned correctly within the EE4 event… when the migration worked as expected.

1. Take note of the event and registration date. The correct dates is in EE3 screenshot. You’ll notice that in EE4 the event and registration date changed to the date when we did the migration of EE3 to EE4.

That should not be happening.

2. There are 4 number of tickets in EE3, while in EE4 has only 1.
3. The ticket migrated on EE4 (only one) is not the same or does not belong to any of the tickets being reflected in the originals from EE3. Where does this came from? If you open up other events, you will also see ticket price is incorrect.

I’ve linked these 2 together as it sounds like there is an issue with the migration, you should have all tickets from EE3. Where the other comes from I’m not sure as something is obviously breaking during the migration.

4. Email confirmation on EE3, has this been changed to Notifications in EE4?

Yes.

EE4 uses a completely different ‘messages’ system to EE3. The notifications section allows you to change which message templates are used on specific events.

5. In EE4, events have “Inactive” status. Though sometimes when publishing/updating makes it active, sometimes not

It should depend on the dates/times set within the datetimes for the event, again as there seems to be an issue with the migration this may do strange things.

6. The layout of EE4 is something similar to a blog post, with post metas and comments section. Can this be changed something to what we have in EE3? Refer to screenshot above.

As EE4 events are custom post types they uses your sites theme to output the details. The screenshot you posted is likely from your themes single.php template. It can be edited yes but you will need to create a custom template for EE events however you can not currently have the registration form on the single event page. Which leads onto…

7. The purchase logic is kind of different in EE4, can we have this changed to something similar to EE3 without a need to be redirected to another page for personal information input form and checkout?

EE4 was designed to allow you to select events and then checkout, without the Multi Event Registration Add-on the checkout is always for a single event, but with it it your events site in a ‘cart’ like system and then pass over to the checkout page (we call it Single Page CheckOut – SPCO)

Changing this to include all of the registration step within the single event will take considerable customization to the EE4 checkout process, so whilst possible it is not something we currently support.

8. On EE4 front-end, it shows event has expired or sales has ended even though date has been adjusted to future date.

Again this seems to be an issue with the migration, whatever is happening is breaking the datetimes/tickets and will cause some strange behaviour until fixed.

Let me know if you are keen to take a look on our website with an install of EE3 and our staging site where we did a test migrating EE3 to EE4 so you can compare.

I would like to take a look at this if possible, you can send temporary login details using this form:

https://eventespresso.com/send-login-details/

Note I will need to view both EE3 and EE4 on that site, your EE3 data is still there so I can de-activate EE4 and activate EE3 again to view it I just want to make you aware beforehand.

December 6, 2016 at 4:54 am

If we sent you the login for the staging environment, would you still need access to the live site?

No, I do not need access to live site at all, staging is fine as long as I can see your event data.

If so, should we make a copy for you to work on just to make sure no changes are made to the live site?

Make a backup anyway 🙂

In my opinion you can never have to many backups.

So, to be really clear I only need access to staging or even just a temporary site that created from a current backup I do not want to make any changes to the live site at all.

December 8, 2016 at 10:23 am

Hi Nigel,

I spent some time going over your events and setting up similar events locally to test.

The problem with your migration is due to no Reg start/end times and no Event start/end times set in the EE3 events – http://take.ms/2NKlV

Can I ask why you blank those values?

All of your events need those values set for the migration to work correctly, as nothing is currently set within them the events fail to create a datetime which then causes most of the problems your seeing with the current migrations. (No datetimes within the EE4 event means the tickets can no be associated to the event and so are not created)

So the first step to setting up your events to be suitable for migration is to update each EE3 event with a relevant start/end time for both of the above sections. Note this needs to be done within EE3 and then the migration to EE4 re-run as the events in EE4 are currently incorrect.

As you mentioned the site is live and still taking booking you’ll likely need to pull the latest changes from live to staging before running the migrations correct?

You could update the times on staging to confirm the events then work correctly, however when the time comes to migrate live you’ll need to re-do all of those updates to the events for migrations to work. So it would likely be best to update the times on live and repull live down to staging again, that way live remains updated with the changes but can continue taking the registrations and you can test (and possibly re-test if needed) migrations on staging without repeatidly updating the times on the events.

December 14, 2016 at 7:29 am

Many thanks for this. We’re going to need to do a lot of testing on this so is it ok to keep this thread open?

No problem at all. Threads automatically close after 2 weeks of no activity, it that happens open a new thread to let us know and we’ll re-open it for you.

I have no idea why the client didn’t put the start/end times in. I guess because they found it worked without – they’ve been using EE for years before we got involved!

EE3 automatically adds those times event if you set them blank when creating the events, however it does not prevent the user from removing them again and saving them with no values so is likely intentional but those values needed to be added back for EE4 to work.

If I simply re-activate EE4 will it revert to the version we had when we attempted migration or will it reflect the changes ie: start/end times (I’m guessing we’d need to re-run the migration)? I want to show a version of EE4 to the client before we do the work on updating the live site just to make sure they can work with it as there are some other fundamental differences.

EE4 migrations run once when EE4 is instially activated and it detects EE3 tables, after that it will not run migrations again without resetting EE4 back to defaults. We have functions within EE4 to do this for you within:

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

The options there will wipe the EE4 tables and allow you to run the migration scrip again when you re-activate EE4 again (any events etc within EE4 will be lost to allow migrations)

Also, I notice now that the event pages are not showing eg: staging: http://pillowmain.staging.wpengine.com/the-tours/events/?ee=376
Live: http://www.pillow.co.uk/the-tours/events/?ee=376

That’s happening because EE4 changes the shortcodes used for the critical pages during the migration. So the /events/ page would use [ESPRESSO_EVENTS] for EE3, its now using [ESPRESSO_CHECKOUT] which is an EE4 shortcode.

If you go to Event Espresso -> General Settings -> Page settings.

You’ll see a list of critical pages within EE3 – http://take.ms/HdHoK

That section shows what shortcode needs to be used on each of the 4 critical pages. You’ll need to confirm each of those pages has the shortcode for the curent version of EE you are using (note EE4 migrations will change these each time you migrate).