Import Error: "The organizer name already exists. Please enter a different…"

[Jesse]

This thread:

Eventbrite plugin Error : The organizer name already exists

and this thread:

BUG / FEATURE: Cannot use an existing organizer name???

already document my issue pretty well.

However, those threads conclude that this issue only happens when using Events Calendar (Free) + Eventbrite Add-on. I am using Events Calendar Pro + Eventbrite Addon and get the same behavior.

They also conclude that an “upcoming 3.0 release” will resolve this… though I’m not so sure because those threads indicated the bug occurs only whilst using the Free version.

It seems that the API can pull in the organizer, but then won’t let you use that organizer to publish. If I create a new organizer in WordPress and publish, that works. But if it’s one the API pulled in then no-go.

More specifically:

Events > Import > (fill in Event ID from Eventbrite) > Publish
=> Event publishes to my calendar fine, but gets the big red box: “The following Eventbrite error has occurred: The organizer name already exists. Please enter a different organizer name and try again. Note that your event was not registered with Eventbrite as a result.”

and

Events > Add New > (use an existing Organizer that the API pulled in) > Publish
=> Event publishes to my calendar fine, but gets the big red box: “The following Eventbrite error has occurred: The organizer name already exists. Please enter a different organizer name and try again. Note that your event was not registered with Eventbrite as a result.”

I guess it’s worth noting that when the error occurs as a result of creating a new event, that event does show up in Eventbrite. Which is great, except for the big scary red error box that says it wasn’t registered.

One of the previous posters indicated that letting WordPress create a new organizer that Eventbrite then stores, then copying over the organizer data and deleting the previous one is a viable workaround. I’ve checked and subsequent events published by this second organizer are indeed taken in by Eventbrite. But this is a client’s EB account and I just don’t think that’s a good enough solution. At the very least, the organizer page URL would change and I don’t have a good reason to tell them their link is no good anymore, other than “the plugin doesn’t work as advertised so this is what we gotta do”.

So I offer up this vanilla environment:
– WordPress 3.5.1
– The Events Calendar PRO Version 2.0.11
– The Events Calendar: Eventbrite Tickets Version 1.0.5
– No other plugins
– Unmodified Twenty Twelve theme or Twenty Eleven (occurs in both)
– No other post data
with WP admin login credentials to anyone there at tri.be who might want to take a closer look. I literally threw that clean WP+ plugins up on a clean subdomain/database and attached the licenses to it, just to check, rather than mucking around with my dev site.

Of course if v3.0 comes out tomorrow and it addresses this, I guess it’s a pretty moot point.

[Jesse]

This reply is private.

[Barry]

Hi Jesse,

They also conclude that an “upcoming 3.0 release” will resolve this… though I’m not so sure because those threads indicated the bug occurs only whilst using the Free version.

By virtue of the detail in your post I think this may be an angle we hadn’t considered previously; please bear with me as I want to test out what you are describing.

I’ll update you as soon as I can.

[Barry]

So we can’t actually replicate this issue; though I appreciate you annotated that you ran through our basic troubleshooting steps when you opened this thread can I just confirm those steps and that they made no difference to this problem?

• Please ensure that your Modern Tribe plugins are up-to-date and in-synch … for instance if you are using The Events Calendar 2.0.11 you must also use Events Calendar PRO 2.0.11 (and, in your case, Eventbrite Tickets 1.0.5)
• Deactivate all other plugins and change your theme to a default, unmodified one such as Twenty Eleven or Twenty Twelve
• Now test to see if the problem still exists
• If the problem has been solved by these steps, start reactivating everything one-at-a-time, testing at each point to see if the issue has returned
• If the issue does return, take note of whichever plugin (or theme) you reactivated immediately before it started again – it’s likely there is a conflict with this item

[Barry]

… Or, rather, can you confirm that on the plain vanilla site you created this is also a problem?

[Jesse]

Yep, up-to-date and nothing beyond a clean WP 3.5.1 install and Twenty Eleven/Twelve.

I also believe you that you can’t recreate the conditions to make it happen.

I’ve tried to isolate it a bit, and now believe it is related to *this organizer* specifically:
– create a new organizer, make an event, import => Works as expected
– add event w/that new organizer => works as expected
– try to import an event with the original problematic organizer, change the date/description => see the red error box/event not updated
– try to add new event using that original problematic organizer => see red error box/event not published

So then I created a whole new Eventbrite account, started another clean vanilla WP 3.5.1 install with the up-to-date plugins (all manually using fresh downloads, not an import tool like BackupBuddy), gave this environment the new EB API key, make/import Event => works as expected

Only thing I can think of now is that is that there is some edge case that my client’s EB account/organizer falls into, maybe the date the account was created, or the way their profile is filled out or something obscure, causing the API and the plugin to not “shake hands” as expected. So I don’t think it’s Pro vs Free anymore, but something that may only rear it’s head for some small percentage of EB users, perhaps accounts created before a specific date or something else on EB’s end.

Not sure there’s much more to do then for tri.be unless you’re interested in looking into this specific EB account for more triage. But I can reliably demonstrate it, and could even screencast the process of going from clean install to the undesirable effort (indeed I’ve done it 3 times now) if you wanted to see.

The upside of this experience is that I now know Eventbrite’s service and your plugin really, really well.

What do you think?

[Jesse]

Yes I can confirm. The problem first occurred in the site I’m developing (built on iThemes Builder). Rather than troubleshoot that site w/all the other plugins and Builder customizations, I just created the vanilla install for this purpose. Yes, the issue occurred in both environments.

[Barry]

Well, if nothing else you can count yourself a member of a small and elite group who know both systems intimately 🙂

More seriously, because it’s looking like a fringe case and (if I’m not mistaken) one you can work around without too much effort I’m not really sure if we will take this forward … but, if you could bear with me a little longer I’d just like to check in once more with the team to collect their thoughts on this.

One question I have is this: is it at all possible that the problematic organizer record was created before Events Calendar PRO was activated? I get the impression it was not, but I’d just like to be sure.

[Jesse]

I had considered that and though it the culprit.
I am 100% certain that the problematic organizer record was indeed created before I activated PRO.

But that is also the case for the new Eventbrite account I created, working in a *second* vanilla environment (identical to the first), and the issue didn’t present there.

I wanted to be able to say “You can reproduce it in situations where the Eventbrite Organizer existed prior to installing/activating the plugin(s).”

Now it’s more like “I can reproduce it in *this situation* where the Eventbrite Organizer existed prior to installing/activating the plugin(s).”

The only thing I can see that is different is that the EB account in which the issue presents was created in May, 2012 and my test account was created today. Maybe the date there is significant, or maybe there’s dust on the memory module on which this record lives in EB’s data farm, I dunno. But I wouldn’t waste this much of my time and yours if weren’t a real thing that I can reliably reproduce.

As for workaround… yeah, kind of. I’ll have to tell the client to continue creating the events in Eventbrite, then log in to WP and import it. And if they need to change anything about the event’s details, they need to do that on Eventbrite and then re-import as syncing back up to EB from WP is not reliable, *for their account*. Or maybe talk them into nuking the problematic organizer and rebuilding the profile. That’s probably not such a big deal, but that is precisely what I was hoping to avoid.

[Jesse]

… Now seems the path of least resistance, unless someone does want to take a closer look. But I get it that it might not be a prolific enough bug to want to chase down.

If there’s a v3.0 alpha/beta the developers might want to test in my case, I’d be willing to spend a few more minutes on this. It’d be interesting to know if it occurs in the new release as well.

[Barry]

Definitely, if you could email me ([email protected] FAO Barry) then I’ll happily send you our beta code – your help is very much appreciated here 🙂

[Jesse]

RE:”One question I have is this: is it at all possible that the problematic organizer record was created before Events Calendar PRO was activated? I get the impression it was not, but I’d just like to be sure.”

I took that to mean “did the organizer record exist on Eventbrite’s service, not WordPress/Events Calendar”. I had no organizers set up in the plugin prior to activating PRO in either environment.

Just realized you might be looking for something else.

Email sent.

[Barry]

Thanks for the clarification – yep I was thinking of something else. I’ll reply to you with a copy of the beta code in just a few minutes 🙂

[Jesse]

OK, I spent some time this afternoon testing for in the beta code you sent. Again, I set up a fresh vanilla 3.5.1 on Twenty Twelve and no additional plugins.

Here’s what I saw.

Client’s Eventbrite account:

– import event, publish using the organizer that is populated on import (my desired organizer profile)
==> “organizer already exists” error

– Event > Add New, using the desired saved organizer
==> “organizer already exists” error

– Event > Add New, type in the name of the organizer (that does not already exist on Eventbrite)
==> expected behavior (published w/no error)

– create new event on Eventbrite w/new organizer, then Import Event
==> expected behavior (published w/no error)

– Event > Add New w/new organizer
==> expected behavior (published w/no error)

Delete all organizers from WP, then
– Event > Add New, type in the name of the organizer (that already exists on Eventbrite)
==> “organizer already exists” error (as it should; this is the the use case for which this error exists, right?)

OK, same tests now in a new Eventbrite account and API ID:
– import event, publish using the organizer that is populated on import (my desired organizer profile)
==> expected behavior (published w/no error)

– Event > Add New, using the desired saved organizer
==> expected behavior (published w/no error)

Summary: what happens in the beta code is exactly what happens in the currently shipping code.

My workaround and resolution:

Quoting this entry by Frederick:

BUG / FEATURE: Cannot use an existing organizer name???

“P.S. After I created a new Eventbrite organizer from the WordPress side, I transferred all of the profile information from the old organizer to the new one, deleted the old organizer, and renamed the new organizer with the old name. I get to use my carefully crafted profile, and no more error message! All’s well that ends well, but can we agree that I shouldn’t have to jump through these silly hoops?”

This appears to be what is necessary to achieve what Frederick and I were both after: *getting to publish an event to Eventbrite from the WP backend using the existing Eventbrite profile*. I can publish events using the second organizer for my client, and while I haven’t yet done the “organizer shuffle” (copy the profile info over, assign all upcoming events to the new organizer, delete main organizer, rename new organizer to the old organizer’s name), I think that will work.

The only casualty (besides time spent on this issue) will be the “Your Organizer URL” link that Eventbrite provides users that displays the organizer profile and upcoming events. That will change as a result of the shuffle. I was hoping not to lose that link as it is already out there in people’s bookmarks, on social profiles, etc, but that appears to be the cost of having the Modern Tribe suite of plugins here do what I want them to do (and indeed, what they do quite well for I’m sure the vast majority of your users).

I’m left wondering what is so special about my client’s (and Frederick’s client’s, per above) Eventbrite profiles that necessitates this “organizer shuffle”. If that is something your developers want to explore we can go further with this in the spirit of making the plugins work as intended for a wider audience of users. I can screen-capture the behavior and send a private link their way if they like. But if Frederick and I really are the only two users to actually get trumped up by this, well I can see why that exploration might not be priority.

Thanks for a peak at the upcoming code and your time and energy working through this with me.

[Barry]

Hi Jesse – thank you first of all for your commitment to working through this and your support for our plugin.

We’re just discussing the best course of action here – so please bear with us a little longer – but I wanted to acknowledge that we’d read your above post and are actively looking into this. I (or possibly another team member) will get back to you as soon as possible.

[Author]

Posts