[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.

[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.

[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.

[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]

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.

[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]

This reply is private.

[Author]

Posts