Port to Drupal 7

Of course. Since this module is still under active development, we are focusing on getting a stable D6 release. Once that is complete and we working out any lingering bugs, we will start the port process.

When that time comes, we can repoen this or open a new issue to track the progress.

Thanks for the interest!

No problem. The credit goes to dtarc for leading the new 2.x branch of development.

+1

+1 Eventbrite port to D7

Hi guys,

Could I add a +1 for this please?

Thanks.

We are getting closer to a release for D6. I'm planning to have the last beta release up this weekend. After that we can identify any further needs for a D6 release.

I don't imagine there will be a D7 port until the Sep/Oct, unless others are willing to port. Hopefully the D6 version could be stable enough to start porting in about a month.

Really, really could use a D7 version soon. Sooner than that, if possible.

Checking in to see if the plans to update Eventbrite module to D7 are still on the table. I have a D7 client that could really use this module. Thanks

+1

Are eventbrite really sponsoring this? Development seems very slow given there is still not a D7 release a year later. Would be interesting to know what progress has been made and what the roadmap is for anything usable. We no longer develop sites in D6.

When I talked to Eventbrite customer support last month (Dec 2011) they did not know what I was talking about. So I don't think they are currently sponsoring development, which is probably why there hasn't been any visible progress. BTW, this is not a criticism of the module developer; I don't think the developer has a sponsor now. Just a guess.

Thanks h2pm - Its a shame if its the case, given that the description clearly states there is sponsorship. I wish we had the space to do this ourselves but not at the moment anyway.

Hi all:

I spoke with a company a few days ago and they write a plugin for Eventbrite. Though this is second hand knowledge, they were under the impression that:

...EventBrite was trying to eventually steer away from platform specific modules and go with this widget approach as well as the simple ticket embed copy/paste code web parts.

.

I believe some of the developers of this module were previously exploring the idea of an event_api module that services such as Eventbrite could hook into. Something where developers wouldn't have to keep rewriting similar code might also make it easier for event management websites/apis to join the drupal bandwagon.

Possibly this could still be a good option?

I'm the developer for the 6.x-2.x branch.

In terms of sponsorship there was some sponsorship from Eventbrite. However the module was a much bigger undertaking than expected--and we've put a lot of our own time into building it out. At this point there is no more funding for the Eventbrite module going forward.

Now, it seems like there is a fair amount of interest in getting a D7 port out. So perhaps there is enough interested to collectively generate funding for a D7 port. I know there are people using the D6 version and a group who are planning to build a bit more on to the D6 version.

As far as the D7 version goes, there are a couple ways to approach this that I can see. A proper D7 release would be entity based, and there would be a lot of changes required to get this working. I see the following two possibilities:

• Get a simple, minimal 7.x-1.x release out. Just do a straight port and support a small feature set. Build interest in using the module in D7, and then start on a 7.x-2.x entity-based released
• Skip the intermediate step and go for the proper release right off the bat

I'm leaning towards the 2nd.

An Event API has been mentioned, and I have also heard from Brown Paper Tickets about that kind of approach. The idea here would be to have an API that handles event management within Drupal, and then different event services (Eventbrite, Brown Paper Tickets, etc.) could have plugins to pull and push content.

I think this is not the right approach. An event is actually a pretty complicated data object, with venues, tickets, attendees, etc., and I'm not convinced that the effort to abstract this complexity across event services will be worth the effort. Working on Eventbrite alone there were a lot of peculiarities that came up with their business logic and remote api. I would imagine this is par for the course for many of these event services--they've been developing their sites for quite a while but the APIs are lagging.

While I don't see the Event API as the way to go, I think another way is possible. Creating an Event entity (maybe taking over the Event namespace) and a Venue entity which the Eventbrite module could depend on would allow us to move some common event handling over to these modules. For example, the Event entity module could handle all the views display, etc. This would also allow for the possibility of using Display Suite to customize Event display.

As it stands now there is no funding in place for a D7 port. I'd be happy to keep working on the module, but I don't really have a business case for it. The client we built the module for will be sticking with D6 for quite a while. I'm happy to contribute code to drupal.org but this module is a bit of a niche use case, supporting a proprietary service.

If somebody wants to take on a D7 port I'd be happy to assist, or add someone as a maintainer. If a D7 port appeals to you enough to offer some funding, now's the time to speak up.

I'm not sure how much work is involved in porting, I think that would depend on the approach taken as well as the needs of funders.

dtarc, thanks for the detailed update, much appreciated. My situation is that we have a multi-site setup using Domain Access for Drupal 6. (innovationnights.com) Right now we are doing RSVPs for events using nodes / Views / Rules but I'm not in love with it, more of a stop gap solution. I'd like to use Eventbrite instead so there may be some funding from us if need-be for Drupal 6 as that's what our site is built on. I need to test the module and determine if it's something that's viable for us. Thanks again! -- danny

I would be willing to pitch in some $$ if others will join in. How about it?

n/a

We're currently building out the Eventbrite 2.0/3.0 module for drupal 7 .. its fairly simple, basically api integration with venues, organizers, and an eventbritefield that allows a user to put in an eventbrite ID to create a link or iFrame (depending on what the user needs)

Besides the field, its a direct port from drupal6 version. You can see the code here:
http://drupal.org/sandbox/japerry/1821544

This is great news, just recently started using eventbrite and would love to see a D7 module. Keep up the good work.

+1

Are there any updates?

Subscribing! Would love to see this in D7

japerry, would you be interested in taking on maintainership of this module for D7?

We are still looking for a clear explanation of exactly what the Eventbrite module...

(a) Is supposed to do
(b) Actually does

We have been somewhat successful in testing certain admin features, but have NO CLUE how to actually integrate Eventbrite event management into our Drupal events. Is this even possible? WHERE IS THIS DOCUMENTED?!?

Thanks...

I would also like to know if there is an ETA on development or a release for Drupal 7.

Hey dtarc
What if we leveraged a rapid prototype leveraging several modules. If I were tasked with this effort I'd focus on one of two ways to build the Drupal artifacts.

Stage One: Drupal Objects
I'd chose one of the following methods to build out everything.

1) Rapid Prototype (preferred)
It would include the modeling of objects, building controllers and integrating with views and rules. The objects would be packaged within the features module for the initial module release. Making the objects, events, and displays native to Drupal; built using highly used contrib modules.

2) Custom Entities
In this case I would register the hooks to define the entities, fields, etc by hand. Writing out all of the definitions, install code, ect.

Stage Two: Integration
1) SOAP/REST Bridge
I'd look at using this: https://drupal.org/project/wsclient

2) Controller/Settings
Build a secondary support module that bridges both the drupal entities and the soap client. The controller would include event hooks to integrate user driven events to trigger connecting to the Event Bright API methods.

Granted the module would have community dependencies but is that such a bad thing?

I'm going to mark this issue as fixed, as we've gotten the initial 2.0 port from my sandbox into the main 7.x tree for eventbrite.

Please make new issues (and there are quite a few!) in this queue and tag them appropriately. I'll roll a first release, which is very alpha, but at least gets the ball rolling.

Also, xenophyle has offered up a few patches and is doing work on the 7.x release, I've added her to be able to make commits -- hopefully this will speed up the process in which a good 7.x release will be done.

Thanks to 10gen for helping sponsor some of the 7.x work!

Hi, I've made a few commits to get this very basically working. Here's what's accomplished so far:

- You can install the base eventbrite module and enter your keys.
- You can install the eventbritefield module. If you add an eventbrite field to a node type (or presumably any entity type), you will be able to enter the event ID in that field on a node and then when viewing the node a link to the event on Eventbrite will appear.

I'm not sure what the other modules in the package do or if they are needed in D7. I will be looking over them to try to figure it out.