Download & Extend

Provide cTools content type for OG Menu

Project:OG Menu
Version:7.x-2.x-dev
Component:Code
Category:feature request
Priority:normal
Assigned:pontus_nilsson
Status:needs review

Issue Summary

Since OG 7 makes heavy use of Panels I think a cTools content type would be very handy to use for rendering the menu in a pane.

By having this functionality as a cTools content type the settings for the pane is exportable. The setting for OG Menu that is link menu title to group node is now optional per pane. By having the group context configurable it makes the settings very flexible.

After a IRC chat with rv0 this functionality should be added as a submodule so that OG Menu does not add more dependencies than it has to. The supplied submodule adds a cTools content type that has settings for

  • Provided context "Organic groups membership: Group gid"
  • Link the pane title to the group node
  • Override title text (standard)
AttachmentSize
Node template | organicgroups_1315576261826.png18.17 KB
og_menu_pane.tar_.gz1.39 KB

Comments

#1

Supplied file provides the submodule as a patch instead of the archive in the post above.

AttachmentSize
0001-Adds-submodule-that-provides-cTools-content-type-for.patch 4.25 KB

#2

haven't tested yet and won't have the time to do so soon, but if people want this they should help out by testing it and posting feedback in here!

just did a quick read of the patch, some minor comments:
- isn't panels needed as a dependency?
- please try to follow the coding standards a bit more.. Like place a "dot" after a comment.
- empty lines should be empty, i spotted at least one which has spaces
- when placing comments in array definition, please place them after the relevant key=>val unless it's really long
- i've never seen ctools spelled like cTools before. be consistent.

it seems like a nice addition to OG Menu, hope to get some feedback from users.

#3

I tested the patch using og_menu from 11/10/26.

It works fine, as long you have only one single menu in the group.
og_menu allows multiple menus per group. As soon you add a second menu, the menu pane disappears.

Thanks!

#4

New patch with fixes from comments in #2.
Regarding #3. I guess it will be hard to determine which menu should be rendered. Should we have a setting render the n:th menu in the group or should it be render first found menu or render all menus?

AttachmentSize
ctoolsintegration-1274250-4.patch 4 KB

#5

Nice to see this is still going on.
About the multi menu feature:
I really dont get the point of the legacy OG Multi menu thing, I don't like how it currently works.
It seems to merge the links and places the title of the current node on top. Seems "weird" to me.
Haven't used it myself until I got a patch for it recently. Don't really know what to do with it.

#6

Why not make the plugin add multiple content types, one for each menu in each group? that way, you will be able to select the appropriate menu based on the current context.

Edit: Hmm... I guess we still would have to have a "N:th menu in group" kind of pane if we want to be able to create new menus without changing panels though.

#7

New patch renders through menu_block with settings for depth.

AttachmentSize
ctoolsintegration-1274250-7.patch 6.86 KB

#8

A quick look at the patch, I see $form['depth'] setting for max depth of the menu tree
afaik, drupal limits menu depth to 9: http://api.drupal.org/api/drupal/includes%21menu.inc/constant/MENU_MAX_D...
maybe best to use that constant and the range function to create the array: http://www.php.net/manual/en/function.range.php

Why the menu_block dependency? what does it do?

#9

I was thinking menu_block does some pretty cool stuff. For example only render first level of the menu in the first pane, render the second level starting at the active menu trail etc.

#10

Screwed up the last uploaded patch, new file comes here.

AttachmentSize
ctoolsintegration-1274250-10.patch 5.67 KB

#11

New patch provides some sane defaults if they are not set in the pane.

AttachmentSize
ctoolsintegration-1274250-11.patch 5.87 KB

#12

Thanks for the patch! Two minor suggestions on the comments:

+/**
+ * Implementation of hook_ctools_plugin_dierctory() to let the system know
+ * where our content_type plugins are.
+ */

1) "dierctory" should be "directory"
2) As I understand them, the current comment style guidelines suggest that the first, and probably only, line in the comment block should be:

/**
* Implements hook_ctools_plugin_directory().
*/

I can't comment on how well the code works, however, since I haven't actually tested it.

Cheers,
-G