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.
Comment | File | Size | Author |
---|---|---|---|
#2 | menu-block-admin-form-separation-741284-2.patch | 9.34 KB | JohnAlbin |
#1 | Combination patch try 2 | 8.71 KB | hefox |
Combination Patch | 21.83 KB | hefox | |
Content type plugin | 3.54 KB | hefox | |
Admin form seperation | 5.34 KB | hefox | |
Comments
Comment #1
hefox CreditAttribution: hefox commentedI 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
Comment #2
JohnAlbinhefox++ 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. :-)
Comment #3
JohnAlbinRight, 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!
Comment #4
markhalliwellI 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)
Comment #5
JohnAlbinReally? 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
Comment #6
JohnAlbinOk. 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! :-)
Comment #7
markhalliwellThat did it :) Thank you so much, you're awesome!
Comment #8
JohnAlbinExcellent!