OG 2.x no longer creates a group entity type, instead using the group entity itself. We will need to store the group entity type and gid (entity/node id) in og_menu schema.

This will also include finding and removing code where the 'node' entity type has been hard-coded.
elseif (!og_is_group_type('node', $node->type))

Comments

bulldozer2003’s picture

@rv0
With changing the schema, should we include an update script, or is that not necessary since this is a dev branch without a stable release?

zipymonkey’s picture

I say please include an update script.

rv0’s picture

both hook_update_N and hook_schema are needed in .install file
its not that much work though

already a lot of people are using the dev branch, we cant just ask them to update their db's manually

bulldozer2003’s picture

Status: Active » Needs review
bulldozer2003’s picture

This patch takes care of updating the schema with group_type and storing the new data as well. I also rewrote some of the code to handle storing and processing group_type data.

Still, though, a lot of work remains to move this module entirely to entity from node including switching hook_node_* to hook_entity_*

I tested out most module functions and everything seems to be working.

bulldozer2003’s picture

I wanted to use db_change_field, but it doesn't allow moving columns (the FIRST syntax). Looking back on it, this code might be too mysql specific.

db_query('ALTER TABLE {og_menu} MODIFY COLUMN menu_name varchar(32) NOT NULL DEFAULT \'\' FIRST');

Column order doesn't matter in the modules code currently, but I wanted to put menu_name first cosmetically, since it is the primary key. Perhaps I should have simply added group_type onto the end and called it a day. Thoughts?

Schema before:
gid (key) | menu_name (key)

Schema after:
menu_name (key) | gid | group_type

Or just tack group_type onto the end and change the primary key:
gid | menu_name (key) | group_type

bulldozer2003’s picture

Any eyes on my patch in comment #5?

I know it is a big update with a lot of changes. One big change is in og_get_group_menus():

* @param gids
- *    An optional array of group gids.
+ *    An optional array of groups as returned by og_get_entity_groups().

I chose to alter the parameter in this way because 1) we need to get the bundle type and 2) it allows using the result of og_get_entity_groups without alteration.

I know the rest of the module doesn't support using non-node entity types, but anything we can do to slowly bring us toward that goal is good I think.

zipymonkey’s picture

Finally got a chance to test this out. I found the following:

  1. When adding a new menu to a group (group/node/[nid]/admin/menus/add) I get an error message (Notice: Undefined index: og_imenu_gid in og_menu_edit_menu_form_submit() (line 866). Looks to be a typo.
  2. When I attempt to save a menu (/admin/structure/menu/manage/[menu-name]/edit) I get an error message (Notice: Undefined index: og_menu_group_type in og_menu_edit_menu_form_submit() (line 865). Looks like this form is missing the group_type.
  3. _og_menu_autocomplete() is only return groups with an entity type of 'node'.
bulldozer2003’s picture

Status: Needs review » Needs work

Thanks for the testing. I'll check 1 and 2 out. Number 3 is one of the many things that still need to be fixed to support group_type, this patch is just a stop along the way IMHO.

rv0’s picture

As for 3)
Maybe we should integrate with Better Automcomplete (BAC) like linkit does.
http://drupal.org/project/linkit
https://github.com/betamos/Better-Autocomplete
http://drupal.org/sandbox/sven.lauer/1777988

bulldozer2003’s picture

Status: Needs work » Needs review
StatusFileSize
new17.24 KB

RE: @zipymonkey
Fixed the typo, I could not replicate point 2, the group_type is defined in the form and I was able to add and edit menus without any issue.

zipymonkey’s picture

Status: Needs review » Reviewed & tested by the community

Tested out the new patch. 1 is solved, and I also could not duplicate 2.

bulldozer2003’s picture

Issue tags: +Needs committer feedback

Just wondering if anyone is thinking about commiting this or if there are concerns.

rv0’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for the heads up
been too busy with other things and forgot about this.
Committed. Let's see where this goes :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

tom robert’s picture

Status: Closed (fixed) » Active
StatusFileSize
new1.08 KB

I'm having the same problem as in #8 issue 2 :
When I attempt to save a menu (/admin/structure/menu/manage/[menu-name]/edit) I get an error message (Notice: Undefined index: og_menu_group_type in og_menu_edit_menu_form_submit() (line 865). Looks like this form is missing the group_type.

This happens when I create a new menu by the normal drupal way of adding menus (/admin/structure/menu/add).

When i looked at the code. The form is altered and og_menu_edit_menu_form_submit handler is added.
But the gid is not required and when provided it is of format "groupname [gid:XX]". The group_type is not provided.

The other form (og_menu_edit_menu_form) that also uses this submit handler provides the correct values for this submit handler.

The function og_menu_update_menu in og_menu_edit_menu_form_submit is always executed even when not in a og context.

function og_menu_edit_menu_form_submit($form, &$form_state) {
  $group_type = $form['og_menu_group_type']['#value'];
  $gid = $form['og_menu_gid']['#value'];
  $menu_name = $form['#insert'] ? $menu_name = 'menu-' . $form['menu_name']['#value'] : $form['og_menu_name']['#value'];
  og_menu_update_menu($menu_name, $gid, $group_type);
}

I made a workaround patch that handles the extra checks, but maybe this should be reevaluated, so that the gid is always provided in the same format, the group type is always present and only executed when needed.

function og_menu_edit_menu_form_submit($form, &$form_state) {
  if (!empty($form_state['values']['og_menu_gid'])) {
    $matches = array();
    // This submit handler is called from two different forms which encode the gid differently.
    preg_match('/\[gid:(\d+)\]/', $form_state['values']['og_menu_gid'], $matches);
    $gid = (!empty($matches[1])) ? $matches[1] : $form_state['values']['og_menu_gid'];
    $menu_name = $form['#insert'] ? $menu_name = 'menu-' . $form['menu_name']['#value'] : $form['menu_name']['#value'];
    og_menu_update_menu($menu_name, $gid, 'node');
  }
}
rv0’s picture

Status: Active » Fixed

@Tom Robert
Thanks for that patch.
I restored part of the code from 7.x-2.x which also seems to be working.
It's a similar approach, but a different regex. Too tired now to look into it but it worked and it still does.

You are right that it should be reevaluated.
The autocomplete and select "widgets" there should be made $group_type aware so that non-node entities can be used.
This turned out to be not so simple in the current og, hence this change is postponed in favor of just fixing this bug.

Fix has been committed:
http://drupalcode.org/project/og_menu.git/blobdiff/8ea2a6c8627a32725851a...

bulldozer2003’s picture

Priority: Normal » Major

Woah, creating new menus is failing miserably for me now. Menus added for a group are being added as standard menus, but the og_menu is still being written to the database. It looks like maybe they're just being named incorrectly.

Editing them via admin/menus and adding an OG re-associates them, but I still have the zombie entires in the group>menu list.

bulldozer2003’s picture

I think we should keep a 'menu-og-' . $menu_name convention for menu machine names.

rv0’s picture

@bulldozer2003
What happens if someone affiliates an existing menu with og? We wont change the machine name there, so we cant just assume all og menus follow this naming convention.
If you look at the diff, I actually restored the og-menu naming convention: http://drupalcode.org/project/og_menu.git/blobdiff/8ea2a6c8627a32725851a...

EDIT:

Woah, creating new menus is failing miserably for me now. Menus added for a group are being added as standard menus, but the og_menu is still being written to the database. It looks like maybe they're just being named incorrectly.

Can you please provide the exact steps to replicate this?

bulldozer2003’s picture

Adding menus from group/%/%/admin/menus/%/add created the menu but the entry in og_menu database table did not match the menu table menu_name. The og_menu menu_name was menu-og- the menu table menu_name is menu-

bulldozer2003’s picture

Automatically closed -- issue fixed for 2 weeks with no activity.

azinck’s picture

Issue summary: View changes

I opened a new issue to move towards supporting arbitrary entity types as groups: #2270725: Make OG Menu work with any type of group entity

xjm’s picture

Issue tags: -Needs committer feedback