Events Made Easy Forums Bug fixed or feature request implemented wp users, eme_bookings and eme_people out of sync.


Viewing 20 posts - 1 through 20 (of 20 total)
  • Author
  • #61899

    Hi, on my website I have allowed people to go through the event payment process before the registration.

    The event booking email as well as wordpress registration emails are sent fine. However, sometimes when a person creates a wordpress account after a booking was payed for (stripe), EME does not link the person with the wp_ID. It happens mostly when people generate the wp account after a few days after payment. Simply put: wp_id in wp_eme_bookings table and wp_eme_people is filled with 0 instead of person’s real wp_id. When a person goes to the list of bookings on the frontend, it says: “No records”.

    Even when I link the wp user through wp-admin/admin.php?page=eme-people&eme_admin_action=edit_person&person_id=XXX the bookings made by eme person are still not linked to the wp user.

    Checking integrity of wp_id linking on wp-admin/admin.php?page=eme-people doesn’t detect the problem and I have to go manually to the database to fix the bookings.

    Will you please have a look at wp user linking? I can manage linking people manually through backend. But would like to skip the step of going to database.

    P.S. Is it possible to include password generation link in EME booking email?




    if you can give me a small playbook on how to reproduce this, that would be very nice. I’ve several sites but most are without only payments …
    Even maybe a small db-dump etc … whatever can help (or access to your site?).


    Hi, I have tested it a lot. And now I have found a way how to do it.

    1. Let’s say the email address of a person is For an older event he registered and inputted this email and a name “Test”. The event was setup to automatically create a wordpress account for this user. It allows only one registration with unique email and only one registration with combination of names/email.
    2. There is another event (setup is same) now and the same person is going to register. He uses the same email address, but this time he writes the name “Queen Elisabeth”.
    3. In EME a new person is created in eme_people table. This new person cannot be linked with an original wp user, because that one is already occupied. The registration form didn’t ask the user to login first.

    This is just one of the ways of making the persons out of sync. But this one is certain to fail. It failed even with my admin account. I will look deeper to describe the other ways as well.


    Concerning your example: if a user is logged in, he’s not allowed to change his lastname/firstname/email in the rsvp form unless he’s an event editor or admin.
    But I see the point if trying to create a second wp account (which will fail since the email address is already in use). Maybe I should catch that and refuse the registration here.


    Ok, I thought about this further:
    – if a user has his account created in WP he should log in first
    – if he doesn’t and uses another name but an existing email, a WP user can’t be created. But: I can’t go ahead and use the existing WP account for that registration either, since anybody can use an existing email address.
    – in EME “people management”, you can delete a person and when selecting the action “delete”, you can transfer existing bookings to another user. That should solve your problem with manually trying to fix things in the db


    Thank you for the answer, but this is not how it works. In ideal world existing users would login first before attempting to buy tickets, but they simply don’t do that. EME should at least warn them if logged out user attempts to use the email address that’s already taken by a registered user. In my ideal world EME just checks email address and tells the person that the email address is already used and that they should login first before buying anything with that email address. Or at least asks whether they are sure to buy ticket for an existing user. But the booking should definitely be added to the user that has already been registered with that email address. Otherwise a buyer has no way how to get to the ticket. (My system is built around booking lists visible by logged in user)

    Just to mention – if user is already logged in and he buys the ticket as logged in user, everything is fine. The problems arouse only when the tickets are bought by not logged users.

    I don’t want to force people to first register the account and buy afterwards. I was there and most of the people just walked away when they found out they need to register first. It’s not an industry standard.


    See if this change helps:

    If it does, don’t forget to make a small donation to keep the plugin alive.


    Great, thanks. It works as intended. The message should probably be a bit more verbose: “The email address belongs to an existing user. Please log in first before continuing to register with this email address.” But when pushed to a new version, I will translate it anyway into my native.

    One part of the problem is solved. Another one is reservations for new users that are not correctly written in database (wp_id correctly in eme_people, but in eme_bookings there is 0). It happens for 1 in 10 reservations. I have to track down the culprit first. I will keep you informed.

    Thank you very much for your work and for the quick fixes. Merry Christmas Franky.

    * donation sent.


    Hi Franky. Have you been changing anything in the code. During last few days two people have somehow managed to buy tickets with email address that is already in use by another wordpress account (linked with another EME person). Each time I have to manually delete the new buyer and move his reservations to the original one.

    For both of this occurences I had to manually fix the database as well. Because in the eme_bookings table wp_id was set to 0 even after moving of the booking to the correct user.

    Will you please have a look at it?


    Argh … I generalized the code (see my post from Dec 26) but I think I made a typo in it …
    This one-liner should fix it:


    Thanks, it happens. It’s working now.


    But you made another point: moving a booking to another user, should it take over the wp_id of that user? That’s something I need to think about. Let me check the code too.


    Ok, since the wp_id is stored per person, I eliminated this info per booking.
    This is the changeset for that (rather big):
    followed by a small correction and removal of commented-out lines:

    Feel free to try it out 🙂
    This should also solve the issue when you move a booking to another person (where the wp_id was not always taken into account).


    Did you try out the latest dev-version? I’ll be releasing in the next day or so, but extra testing is always nice to have.



    I have tested it now and there is a small problem. I am using [eme_mybookings] to displayed paid bookings. Before, when there was wp_id set to 0 in eme_bookings, [eme_mybookings id=#_EVENTID] showed “No answer yet” instead of displaying the booking. (That’s why I had to manually edit the eme_bookings table each time).

    Unfortunately with the above changes it’s showing this information for all users. It’s probably necessary to change the code of [eme_mybookings] because it’s still looking for the wp_id in eme_bookings table.


    I have found the culprit. It’s in the function eme_get_bookings_for_event_wp_id()

    On line 1918 there is still bookings.wp_id.

    ` $sql = $wpdb->prepare(“SELECT bookings.* FROM $bookings_table as bookings LEFT JOIN $people_table as people ON bookings.person_id=people.person_id WHERE bookings.status=%d AND bookings.event_id = %d AND bookings.wp_id = %d ORDER BY people.lastname,people.firstname,bookings.booking_id”, EME_RSVP_STATUS_ACTIVE, $event_id,$wp_id);


    I fixed it by changing bookings.wp_id to people.wp_id in the query.


    I have tested booking a ticket, showing the tickets. Managing bookings. Now everything seems to work.


    Thanks, I fixed that sql statement. I verified all other statements and they seem correct (a bug avoided, thanks again).
    Btw: your linenumber didn’t correspond with the code anymore, so maybe you’re using an intermediate version (just so you know).

Viewing 20 posts - 1 through 20 (of 20 total)
  • You must be logged in to reply to this topic.