Following my previous post, and after getting some great reaction from the community via IRC and in Drupalcamp Toulouse, I’d like to share both my thoughts about the sponsoring and about the technical stuff.

The sponsoring, which already has FunnyMonkey committing to pay almost half the price, and providing on top of that developer hours, was something I’ve decided to do only after I was convinced there are some big players using OG7.
The thing is that _anyway I intend to do this change. The sponsoring is just giving it a boost, and making sure it will be _sooner than later!

I’m happy I was able to post that request and to get good reaction from the community.
I’m equally happy that Planet Drupal isn’t swamped with such requests. It’s not about Drupal App. It’s about harnessing the community towards a goal. Companies offering to assist by providing developer hours is exactly the proof of that.

Now here’s a quick overview of the planned changes. First the conceptual changes:

• Instead of OG having it's own field type, we easily hook into Entity reference field, as it allows registering our own handler using a CTools plugin
• Instead of saving the field values and the OG membership as we currently do, we save the OG membership, and use hookfieldload() to populate the Entity reference with the correct value. Yes, I know, the docs clearly say that we should not load fieldable entities in hookfield_load() as it might cause loading recursion, so we'll just make sure you can't attach group-audience fields to OG membership (which anyway doesn't make much sense). The benefit of doing that, after a long talk with the people form the community, notably fago (thanks again fago!), came out as the best solution for a problematic thing
• OG membership is now tightly coupled with the field that it belongs to. This means we can care about the field cardinality (i.e. how many OG membership can be created per field), and since we know the OG membership type we can provide smarter metadata
• We can have multiple fields, to allow subscribing users/ content to group with different membership type. No more hard-coding of the field name as-well

Sneak preview time...
As usual we can make a content type (Clubs in this example) a group, through the content type edit.

Continue reading…