Deprecating "logo_url" in favor of new Image object (event.logo.id & event.logo.url)

[Mitch Colleran]

Hey everyone! 

If you're pulling information related to the Event object via API V3, then you should be using the "event.logo.id" and "event.logo.url" traits, rather than the "logo_url" trait. My assumption is that most applications are compliant with this because the "event.logo.id" and "event.logo.url" traits have been around for over 3 months. 

We have a situation where we need to quickly deprecate "logo_url" shortly due to an internal deprecation, so we'll be fast tracking this change.

I never like making the decision to make quick changes, but since (1) the other traits have been available for quite a while, (2) we're not removing any functionality, (3) the fix is relatively simple, and (4) non-compatible integrations should still work (just without a logo) -- I'm more comfortable making this change quickly. 

If you're still using "logo_url", please update your usage by April 7th. 

Apologies for the massively short turn around time between this announcement in the forum, and the change to the API. We've implemented a process around to changelog announcements to improve this in the future. 

Cheers!

Mitch

[Elliott Perry]

Hello Mitch, it looks like for whatever reason our integration was using the "logo_url" trait and not the "event.logo.url" trait and we're looking to rectify this as soon as possible.

Has anything else changed under the covers with regard to the actual image URLs? (Or alternatively has the URL for the "logo_url" trait always differed from the "event.logo.url" trait?)

I ask because simply changing our implementation to retrieve the URL from the "event.logo.url" trait is not enough, our image uploading libraries are having difficulties. Knowing any other differences will help speed the process up.

As as example, this event logo image URL is now returned via the Eventbrite API:

https://img.evbuc.com/http%3A%2F%2Fcdn.evbuc.com%2Fimages%2F11877541%2F65057074887%2F1%2Foriginal.jpg?h=200&w=450&s=1933e75337f4ec23caad70153e20a2ce

This is an endpoint followed by an encoded URL. Did the API previously return the encoded URL directly in the "logo_url" trait and now some sort of forwarding is taking place as a result of the recent changes?

The URL that is encoded and included in the URL string returns a response with content type 'binary/octet-stream' whilst the full URL above returns content type 'image/jpeg'. I'm wondering whether this is resulting in the issues we're experiencing.

Again, any info on this will help speed up the process of getting our extension back up to maximum usability for the EB users

[Tom Jordan]

Was there ever any update on this issue? It's causing me some serious problems in grabbing and displaying from the current event.logo.url :/

[cjl]

Seems this has been further changed to event.logo_id? But for the organizer it is still organizer.logo.id - is it going to stay this way?