The 2nd release candidate of OG7 is out, and it’s probably a good time to tell the (Drupal) planet about what’s new and about the things that I learned since the first official release (See OG’s home page to get the latest release candidate link).

Here are some things, mostly related to Drupal, I’ve learned since Og-7.x-1.0

Data migration

OG6 and OG7 have different tables and different data. OG7 has its tables, its fields and its related entities (group and group membership – I’ll soon go over those). At first I tried migrating it via hook_update_N(). I still feel the burns! “Your hook_update_N() shouldn’t assume anything about the state of a module or it’s API”, said fago, and I listened. Just like CCK has content-migrate module, OG7 has og-migrate. Whenever a module needs to migrate data, they can set a variable to TRUE, implement og-migrate plugins (a la CTools), and the job is done. This means design decisions (and oh boy I had a few) can be rectified without many struggles.

Fields and entities

OG7 has two important fields and an entity that acts as a meta-data related to that field. og-group field, which is a Boolean field that marks if a node is a group, when is set to TRUE creates a group entity that holds the group ID, entity ID, creation data, group label etc’. So far so good, no problems here.

The second field is group-audience that holds the the information about the relation a piece of content has with a group (i.e. membership). As of 7.x-1.1 whenever a user selects groups in this field, a group membership entity is created that holds the group ID, entity ID, membership state (i.e. active, pending, blocked) etc’. The group membership idea is awesome (thanks donquixote). The problem is actually the field. If we delete a group there is no field API bulk update, that will remove the deleted group from the member’s field. So, the group membership entities have the most up-to-date data, and the fields might not have. After 7.x-1.1 is out I intend to still use the field for it’s widget and formatter, but not as storage. I mean, after a user will select the groups in group-audience field, OG will create the group membership entities, but the fields its will not be written to the DB. I think it’s interesting that also other modules (Field-collection, Relation) decide to use a field but not for it’s storage which is probably the main purpose, but for it’s generic interaction with the entities’ form.

(Thinking of) module renaming

Don’t do it. Seriously, I’m now stuck with some hybrid of og / group in places I prefer not to change. It’s not horrible, but if your the Anal type it bothers a bit.

Group membership entity

This entity is a meta-entity that provides information about the relation of a piece of content to a group. Apart of indicating the state of the membership, this entity is fieldable and you can create as many group membership types as you wish. In fact the text request a member may enter to subscribe to a group, is in fact a field. So you get all the good stuff that come with it (e.g. Rules integration is responsible for emailing the group manager with the request, with zero lines of custom code needed for it to happen, apart of the Rule configuration). Another possible use-case. You can create a group-membership type called “expire”, with a date field, and whenever a user is added to a group, their group membership will have an expiration date. Hack, you can even download og-expire module from my sandbox, and see how group memberships expire on cron run. If you are a developer, do open the module and see how little code is needed to do it.

Entity metadata

OG7 implements Entity API’s metadata hooks, which means Rules, Tokens and Views are for free (free as in Entity API is taking care of it, and OG7 doesn’t need to bother about it. Sweet). If you like to hear more about this and OG checkout this Podcast.

Visa and American embassy renovation

You should have your visa valid if you want to go to the states. And you should try not to find out about it exactly when the American is closed for renovation. The fact you rewrote a module and you want to present it in Drupalcon Chicago means very little to them. Shocking! Anyway, no visa in needed for London, so you can bet I’ll be there presenting OG7 - This time it’s on! (your votes on the session will be appreciated of course).


There will always be bugs, question is how many and how bad. See next section.


I’d like to encourage people to test the RC releases so we can have a stable release soon. For those who haven’t played around with OG7, there are now several movies and tutorials on OG’s home page that show to set it up.