More flexibility for enabling/disabling DHTML effect

6.x-1.05 introduced a design change that made the module theme-independent, since 6.x-1.04 was the last version that used special DHTML blocks. We cannot do this anymore because it was completely impossible to uninstall or upgrade cleanly. Since then, it has been possible to switch off DHTML Menu for certain blocks, but not for themes.

If in that time somebody had asked for theme-based fine-tuning back, it might have been done. But the usability reports were instead indicating that it was already way too complicated to enable the module. And that's why the 3.0-alpha version that has now been released did away with it completely, making the behavior global.

As the module works on menus now, not on blocks, it is also basically unfeasible to configure it differently for different themes. The only solution I see in mind is to make it possible to enable or disable it for certain menu items (enabling it for "Administer" and "Create content", perhaps).

For Drupal 7, I could think of a few improvements for this setting - we can enable the effect for some menus, and perhaps even some menu items.

Features are for D7.

Bummer, I really need to disable DHTML menu on some blocks and themes... For D6 this wont be able ever?

If you need it urgently for Drupal 6, you will need to use the stable 6.x-2.2 branch. I may be able to add a features to the new version later, but it will take a month or more.

Please, could you explain how the DHTML effect is disabled in some Menus in D6? There is no visible option to configure it. There's issue regarding this in D6 http://drupal.org/node/243212 Please answer there. Thanks!

It seems that this feature is rather widely desired, so I will try to put it in for D6.

Nice to hear, would be greatly appreciated.

This is not a perfect solution, as it does not allow you to switch DHTML off for specific sub-items. However, it allows you to set it per menu, which is roughly equivalent to the previous per-block setting. That means at least there is no regression.

The system is also easier to use than previous versions, as it firstly has a list of checkboxes on the main DHTML settings page instead of a single checkbox on each block settings page (so less navigating), and it assumes DHTML behavior is desired by default (so the module will work immediately on installation without requiring further action).

---

It works for me, but I've tested this feature only superficially. I would like some reviews before I commit it...

subscribe

"Subscribing"? Nothing's gonna happen here. Unless you make it happen by testing the patch. ;)

Once I get two reviews on this, it will get in and become the final change for the release of 6.x-3.0.

Sorry about that. I didn't have the time to test then, but have had a check now.

The patch applies cleanly to a current CVS checkout which has yesterdays changes applied, so no changes needed there.

All works fantastically. I am using the Acquia Marina theme which has drop down primary links, which prior to this patch required a double click to open. They now behave correctly by removing the DHTML effect with this patch, as has the Book Navigation.

There will need to be documentation written i guess about enabling the "Go to the page on double-click" option, as if a user has a theme that uses drop down links (eg Acquia Marina) then the links with children will still expand on a hover, but need a double click unless the DHTML effect is removed from that menu.

I hope that last bit make sense!

On further testing, it seems that checking the box to remove the DHTML from the primary links has meant that only the active level of the primary links will expand on a theme with drop down primary menus. For example take this menu structure:

- Primary 1
  | Sub 1-1
    | Sub 1-1-1
    | Sub 1-1-2
  | Sub 1-2
  | Sub 1-3
- Primary 2

If you are outside this hierarchy, and Primary 1 and Primary 2 are linked in the primary links, then they will not expand. If I click on Primary 1, then the Primary 1 menu will show Sub 1-1, Sub 1-2 and Sub 1-3 but not either of Sub 1-1-1 or -2.

Question - if you disable DHTML Menu entirely, will that last problem disappear?

The intended result is that when you disable a menu, DHTML Menu leaves it alone entirely. So if the drop-down function is still affected, there's a bit of a problem.

Also, please try DHTML Menu again with #298720: DHTML effect does not work with i18nmenu applied.

I have just tested it and was able to mouse-over navigate through the Primary Links menu without DHTML Menu interfering in any way at all. You may not need to disable it.

False alarm I think - when I fully disable DHTML menu, then I get the same behaviour of the Primary Links not opening on mouse over.

I will file a bug with the Theme I think on this one.

BTW, when applying #298720: DHTML effect does not work with i18nmenu, Hunk #1 fails on a clean CVS with only this patch and #311248: Separating Menus.

Arancaytar: I will test later, no time atm.

Bit off-topic:
wretched sinner: Your dropdown probably doesn't work because the items aren't expanded. DHTML menu does that for you, so it would be logical that with DHTML on your dropdown works, but without it doesn't.
Go to: admin/build/menu/item/XXX/edit to expand the parent items.

Thanks for this. This saved our site completely. We were having a problem when we disabled the DHTML Menu module. Doing that ended up breaking all of our menu block menus, and brought forth the WOD. We've re-enabled the patched module and turned off the AJAXY stuff for those menu block menus and everything's good now.

Patch working!

Um... sorry? If disabling dhtml_menu causes a site to break critically, I think I should know more in case others have this problem. Can you report this as a separate bug please?

@Arancaytar - I enabled DHTML menu before using the theme, so didn't have it not working before. As dmsmidt mentioned, I didn't have the menu items set to expanded, so that explains why the drop down was not working.

The patch is all working well from this end.

Latest devel_themer fix conflicted with this. I've resolved that.

Committed, tagged, released!

Yay for version 3.0!

Course, I still need to port it to D7.

Testing this.

Works for me. Committed to HEAD.

(It's refreshingly easy to develop code that isn't yet used on live production sites.)