The first patch is similar to #703968: Add menu_tree_build() to allow reuse of tree building code in that it's just basically moving stuff around so the inner part of the function can be re-used outside of blocks, but for the block edit form function. (brings up may want to glump getting the variable_get values into a function also, since it's used twice now, but didn't do that this time).

The second adds in ctools 'content type' with configuration, shows up under add content => menus in panels for example. Some issue with the js not being relevant or included (didn't look into it), might just want to keep that in the original configuration form.

The third should be a both patches together.

Haven't tested too much, but both appear to be working.

Against today's tarbal.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hefox’s picture

FileSize
8.71 KB

I was a bit suspicious that the menu block ctools + admin patch was more than twice the size of the other two patches...

It included the other two patches diffed! XD

JohnAlbin’s picture

hefox++ Thanks for splitting this work into two patches!!! That totally makes this much easier to review and modify.

I've just committed the first part. The actual commit is attached as a patch. I went ahead and re-factored some additional pieces. The menu_block_configure_form() function is now a standard form building function expecting a $form_state and including a validation function for the "follow" element since its stored value is a combo of the "follow" and "follow_parent" widgets.

Now to look at the Panels bit. :-)

JohnAlbin’s picture

Status: Needs review » Fixed

Some issue with the js not being relevant or included (didn't look into it)

Right, that's caused because the config form is loaded via AJAX. So the css and js loaded inside the form definition don't end up doing anything. ctools has an option to load css/js in the content type definition, but there's no way to load the Drupal settings stuff which menu_block was using.

To fix that issue, I merged your patch with a patch from sdboyer. Instead of selecting the menu inside the config form, you select which menu you want first, then can select a sub-tree inside the config form. Since Panels allows you to use that same pane multiple times in a panel, you can still have multiple panes using the same menu. (Unlike the block admin page.)

I spent way too much time on this. But its committed!

markhalliwell’s picture

I really don't know if this is the appropriate place, but it seems like it. After this latest dev release, I noticed that menu_block is breaking my panels layout designer and AJAX saves. Firebug console:

Drupal.settings.menu_block is undefined
[Break on this error] .html(Drupal.settings.menu_block...l.settings.menu_block.menus_default])
menu-block.js?T (line 44)

JohnAlbin’s picture

Status: Fixed » Needs work

Really? Ugh. Yeah, I see the problem in menu-block.js now.

I do a toggle to do one thing on menu block's panel config form and another on menu block's block config form. But the if/else should be an if/elseif. :-p

JohnAlbin’s picture

Category: feature » bug
Status: Needs work » Postponed (maintainer needs more info)

Ok. I just refactored the jQuery to not use any IDs at the suggestion of sun. Hopefully that will also fix this issue as well since line 44 of the js will only match on .menu-block-parent and, therefore, won't try to load the non-existing Drupal.settings.menu_block on Panels pages.

Can you get the latest from CVS? Or wait 12 hours to get the latest -dev? And test again?

Thanks for reporting this Mark! :-)

markhalliwell’s picture

That did it :) Thank you so much, you're awesome!

JohnAlbin’s picture

Category: bug » feature
Status: Postponed (maintainer needs more info) » Fixed

Excellent!

Status: Fixed » Closed (fixed)

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