Posted by alb on August 16, 2010 at 3:29pm
6 followers
| Project: | Jump |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
Issue Summary
the module create for every menu a block;
ok they are in the section disabled so one can activate or not the block that would like to use;
but if one (I think many users) would like use jump only for a menu, in the list of the blocks there will be always all the menu's block, also if never will be used;
think better to have a page for to choiche which menu use with jump and to see in the block's list
Comments
#1
#2
We like the module very much and use it ourselves. Always grateful for contributed code. But, I'd like to second the motion above...
As a case in point, we use it for a menu, but it's auto-created 73 different blocks between our menus and taxonomies. We can certainly modify the code, but just wanted to agree with alb that the module would be much improved without all of the extra blocks. Auto-creating blocks in this context is problematic, especially for large sites. The result is that it takes the blocks page an eternity to load. You're by no means alone, some other modules do (or did) this as well, Tagadelic comes to mind.
My guess would be that a little checkbox in the admin/build/menu-customize/menu-admin/edit section asking if one would like to create a jump menu block would be great... or perhaps better still, adding a list of checkboxes to the Jump admin page. I would suggest the best default would be to create no blocks until the user makes the first move.
Just a couple suggestions from the user community...
Thanks again
#3
Good point -- I haven't used Jump lately on a site with loads of menus and taxonomies.
If anyone can supply a patch I'd gladly review and commit it.
#4
Moving to 6.x-2.x.
#5
Is there any way to remove some of the unused blocks as it its really cumbersome if you only need it for one or two menus.
Thanks
#6
rolled against 2.x-dev. you can now select which menus and vocabs appear as jump blocks.
#7
changing status. please review.
#8
@madmatter23 can we apply this patch to the stable release? as we are using 6x1.1 since it is a production site.
Thanks for the work and the help. Happy to test and let you know.
Cheers
#9
I think that the patch should work against any 6.x-2.x. It's quite easy to apply it to the 6.x-1.x branch as well, the main difference being that hook_block now uses a 'switch' rather than 'if else.'
#10
I just rolled the patch against 1.x. Please try it out and let me know if it works -- I don't have 1.x installed on my site.
#11
you should also replace jump_uninstall with this in your jump.install file
<?phpfunction jump_uninstall() {
db_query("DELETE from {variable} WHERE name LIKE 'jump_activepageinmenu%'");
db_query("DELETE from {variable} WHERE name LIKE 'jump_menu%'");
}
?>
This will ensure that stray variables aren't left in your database after uninstalling the module.
#12
@madmatter23 I applied patch all works well so far. Please ignore screenshot. I was patching manually and missed something, went back and got it fixed.
#13
SWEET! Works awesome! Thanks so much what a great enhancement. BTW the module admin mentions the current page setting but how would one add text that says select category or whatever to a dropdown?
#14
That feature, along with a few others, has been implemented in the 2.x branch. I'd suggest upgrading rather than manually patching the 1.x branch.
#15
@madhatter23 we will keep stable version that we patched until 2 is stable as it is a production site. Thanks.
#16
This is a nifty little module that "just works." Thanks. It solved my exact problem.
#17
changing status after a number of people in community have reported successful patches. rtbc.
anything holding this back?