At the moment, if you disable the menu entry for the homebox page, the homebox module still adds a hook_menu() entry with a MENU_CALLBACK type defined. The problem is that I define the menu entry myself, and do no want the homebox module meddling with it.
Attached is a patch to rectify this
| Comment | File | Size | Author |
|---|---|---|---|
| homebox-no-menu-entry.patch | 1.65 KB | wiifm |
Comments
Comment #1
bulldozer2003The problem is that by removing the page hook_menu entry, the homebox will be inaccessible unless you have defined it elsewhere.
I suggest you use hook_menu_alter in the same module you are defining your own menu entry.
Comment #2
wiifmSurely if you have not defined the menu entry in code (with hook_menu), then you tick the box "create a menu item" in the homebox configuration in which case it functions as it should.
Also when the path to your homebox path is "
node/%node" (like mine is) you can see the complications that could arise from that (now all nodes are homebox pages).I feel my patch at least keeps the intentions of the "create a menu item" checkbox inline with what it actually does.
Comment #3
bulldozer2003Without the MENU_CALLBACK, the homebox would not be called at all unless the user defined it in code. Since it is an option in the user interface, requiring that people configure things in code if it is disabled is confusing to new users.
You seem to be an advanced user; defining site structures in code. I think in that case, using hook_menu_alter() to change $items[$page->settings['path']]['type'] is your best option.
Comment #5
drummbulldozer2003 is correct, it is best to use
hook_menu_alter()to make the menu items work in the case of conflicts. Homebox pages should have a menu callback so they can be delivered in the usual, non-conflicting case without custom code. I committed a clarification to the UI.Comment #6
drummMore-accurate status.