Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Drupal 5: Block twins
DHTML Menu has for all its existence been working with blocks, not menus. It had to do this in Drupal 5, because the output of the menu system was rigid and unextendable, while the block system had an API. We did this by generating a "DHTML: " equivalent of every menu block. This had the side effect of requiring the user to swap out the blocks (or later swapping them automatically) and breaking the site layout when disabled.
Drupal 6: Preprocessed blocks
Drupal 6 added the new concept of preprocessing to the theming layer. This made it possible for modules to interfere with theme functions, manipulating their input before they got it. But preprocessing was and is supported only for templates. Ordinary functions do not get it. Blocks have a template, and so DHTML Menu still had to work with blocks, not menus. The major improvement was that with preprocessing, DHTML Menu was able to swap out the whole content of the menu block for its own version, getting rid of the unsightly duplication.
Drupal 7: Preprocessed menus?
The limitation of the block API still remains. Since we deal with blocks, we can only work with the blocks we know: The navigation (user:0) and the other menus. Even those require tedious re-implementation of our own recursive menu builder.
Replacing something like the book navigation block (which has been desired for years now) is simply impossible unless that one is duplicated too. Before long, we end up with a big bloated module that reimplements every menu-containing block, and that needs to keep its copies of each of those functions updated. Not pretty.
The solution is to preprocess the menu, not the block. By doing that, we can add DHTML effects to every menu that is generated by menu_tree_output, including book navigation, and we get rid of half the module's code that deals with knowing what blocks to replace with what content.
The only remaining impediment to this new method is the fact that preprocessing is still only supported for template files. Once that is fixed, the path is clear!
--
The new generation of DHTML Menu will be added to the next branch - this can be either 7.x-dev or 6.x-3.x-dev. It depends on whether the non-tpl-preprocessing gets into Drupal 6 or is deemed too much of an API change.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | dhtml_menu-rewrite-277063-8.patch | 56.24 KB | cburschka |
| #6 | dhtml_menu-6.x-3.0.tar_.gz | 5.09 KB | cburschka |
| #2 | dhtml_menu-d7.tar_.gz | 3.8 KB | cburschka |
| #1 | dhtml_menu-barebone.tar_.gz | 3.13 KB | cburschka |
Comments
Comment #1
cburschkaAnd here we go.
Basically, I've torn everything but the .info file out and started from scratch. Of course, for the most part this was necessary for implementing the new method. But I've also discovered several sub-perfect ways of doing things in the Javascript code, which I think I'm not alone in having maintained in a "if it ain't broke, don't fix it" fashion.
It fixes a lot of little inconveniences. For example, the module now works with Theme Developer, because it no longer relies on the direct-descendant CSS selector. The module no longer requires installation-time actions.
I've done a lot of re-evaluation on the user-end too, and simplified it vastly:
- Menu cloning is now universal, and generated client-side. The "fake leaves" are also a bit smaller than the regular ones.
- All other effects are also universal and configurable: Sliding animation, Hide siblings, Clone menu items, Double click links.
- The module is completely bereft of individual settings for blocks and menus. You either enable it or you disable it. If there's sufficient demand for fine-tuning, I will make it available in a more simple way.
New features:
- As mentioned earlier, book navigation now uses DHTML. All menus that are generated by menu_tree_output do.
----------
Caveats: This version will not currently do anything on your site. You will need to fix the theming layer problem mentioned earlier.
Comment #2
cburschkaThis version is for Drupal 7 and requires the same theme.inc patch.
Other than D7 compatibility (registry files[] in .info), the comments have been extended, adding doxygen for all functions and explaining some of the more complicated stuff.
Comment #3
cburschkaOuch. Opera 9.5 has several problems with the Javascript. And here I thought jQuery solved the whole cross-browser mess. =(
Comment #4
cburschkaNo wait, partly false alarm. Caching trouble.
Issues in Opera 9.5:
font-size:80%does not shrink the text of the cloned leaf.Siblings work everywhere except the root level of book navigation. I'm willing to bet that the root level books are somehow wrapped in extra elements, and it doesn't work in Firefox either. No solution... for now.
Edit: Correct. The root level of book navigation is actually a string of fully generated separate menu trees. However, this will generate a steady stream of bug reports, so I'll change the way the siblings feature works.
Comment #5
cburschkachx has kindly told me how to use hook_theme_registry_alter to override the theme registry from modules. This rewrite no longer depends on patching Drupal core.
What that means is that the path is clear. 6.x-2.x-dev has already been branched off HEAD as DRUPAL-6--2.
I'm currently testing the update functions to make sure that whether people are upgrading from D5 or an earlier version of the D6 module, the updates will function correctly. When that's done, the module will be released like this:
- The current end of the DRUPAL-6--2 dev branch will be released as 6.x-2.2. That branch will only get critical bug-fixes after this fix.
- Next, the rewritten module will be committed to HEAD. It will immediately be branched to DRUPAL-6--3 and released as 6.x-3.x-dev.
- After that, HEAD will be updated for Drupal 7 compatibility, and released as 7.x-1.x-dev.
Comment #6
cburschkaFixed to work with current version of D6 core using the registry hook, code style, some text improvement. This is what I'm currently testing for the upgrade path.
If it works, this will become DHTML Menu 6.x-3.x-dev.
Comment #7
cburschkaI have been able to upgrade from Drupal 5 straight to the new version with this, which was really the biggest challenge. Just for paranoia, I'll also upgrade from the newer 6.x-2.x, but I'm not really expecting problems with that.
Comment #8
cburschkaAs a patch, this one is a bit out of proportion, but I'm in favor of patches. Looking them over reveals many problems that replacing the files blindly would not catch.
Comment #9
cburschkaThis has now been committed to HEAD and released as 6.x-3.x-dev.
There will be a brief delay for testing and localization before the module is released for production as 6.x-3.0. When it is, it will also be branched, leaving HEAD free to be updated for D7 compatibility.
Comment #10
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.