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 hookupdateN(). I still feel the burns! "Your hookupdateN() 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.

Continue reading…