Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Over the past months, the upcoming Drupal 7 version of DHTML Menu has been improved significantly on several fronts. Even now, there is a bucketload of shiny features in the pipeline. One thing that unites all but one or two of these improvements (eg the refactoring) is that they have nothing to do with the API of D7. They could exist in the D6 version of the module as well. I have incorporated these changes in D7 because more than one unstable branch is just impossible to maintain alone, and it's always good to stay ahead of the game by reaching early compatibility with the next core release.
Well, at the rate 7.x-1.0 is approaching, the module will be almost too far ahead of the game for its own good: I expect a stable release before the end of June, and core doesn't even get frozen until September (hopefully there won't be too many fixes involved in chasing the still fluid API). Meanwhile, 6.x-3.x-dev is starting to look almost shabby by comparison, and 7.x is already too far removed to feasibly backport single features. From experience, D7 adoption will languish (a lot of sites are still on D5) so the 6.x version will be the de facto stable release of DHTML Menu fmore than a year from now.
Having the module effectively on bug-fix support for more than a year while nobody uses the shiny version would be sad. So in order to make today just as good as tomorrow ( :P ), I am toying with the thought of porting the entire 7.x-1.0 release back to D6 in one go. This would involve a 6.x-4.x branch that is entirely based on HEAD - with changes that restore compatibility with D6 core; mostly related to the code registry.
It's crazy and it will pose a bit of difficulty juggling the upgrade path ("Did you upgrade this module from 6.x-3. to 6.x-4.x to 7.x-1.x, or straight from 6.x-3.x to 7.x-1.x?"), but it's probably worth it.
Needless to say, this must be postponed until 7.x-1.x at least gets a release candidate, so the strings (and translations) are stable.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | dhtml_menu-backport-js-479716-4.patch | 1.28 KB | cburschka |
| #3 | dhtml_menu-backport-479716-2.patch | 4.68 KB | cburschka |
| #2 | dhtml_menu-backport-479716-2.patch | 4.68 KB | cburschka |
Comments
Comment #1
cburschkaDrupal 7's theme and rendering API has been changed so severely that before DHTML Menu 7.x-1.0 is even close to release, much of its theme layer interaction will have to be rewritten. It's not just the changes that are necessary - the rendering API also offers some opportunity to improve the existing concept.
With regard to that, I realize that if 6.x-4.x is going to be, it has to be branched now before the next core chase. So I did. The string changes and everything is already in, and the code-style is clean - it sucks branching a dirty code-base.
DRUPAL-6--4 will soon hold a version of DHTML Menu compatible with Drupal 6 and hopefully significantly better than 6.x-3.5.
Comment #2
cburschkaHere is a backport patch.
Necessary changes:
- change core declaration
- remove file[] declarations
- rename drupal_theme_rebuild() back to drupal_rebuild_theme_registry().
- replace drupal_static() with direct statics.
- add the second argument to variable_get(). I'm passing an empty array() as the default. This is because the module already sets its variables in installation - it's guaranteed to be there.
- Change Drupal.behaviors.dhtmlMenu = {attach:function} to Drupal.behaviors.dhtmlMenu = function.
The module's basic functionality works on my D6 test site.
Comment #3
cburschkaCommitted! :D
Creating a branch release now.
Comment #4
cburschkaI neglected the fact that mouseenter() and mouseleave() did not become proper functions until JQuery 1.3 and had to be added with bind() before then.
Comment #5
cburschkaFixed.