Menu does not "drop down" when clicked on.

I cannot reproduce this in the current core and module HEAD (Firefox 2.0.0.7, no other modules).

What browser have you noticed this problem in, and do you use any other Drupal modules that use Javascript?

I can verify.

Installation of this module on the latest D6-beta 3 has no apparent effect on menus with either Firefox or Safari on Mac OS X.

I'm not getting any cookies set by this module. If there should be any references to dhtml on the generated pages, they're not showing up.

In fact, I'm not getting ANY javascript on normal pages all. If I edit a node I get a bunch of script tags that are needed by the edit form, but nothing that enables dhtml_menu.

I am also having this problem when the "Theme developer" module is loaded. As soon as I disable "Theme Developer" module DHTML Menu works perfectly.

Using:
Drupal 6.0-rc1
DHTML Menu 6.x-1.x
devel 6.x-1.x
Firefox 2.0.0.11

I am having a similar problem where the module is not working. I have tried disabling/removing/uninstalling all the other modules and it still isn't working. I haven't tried using this module on a fresh install of drupal 6 RC 1 though. I have tried the following browsers: IE7 and firefox 2.0 and firefox 3.0 beta, and still no luck.

The drupal_add_js() supposedly gets called when the root menu item is generated.

yelvington, could you open the source of one of the pages where your dhtml menu is supposed to be displayed, and look for the initial

tag that opens the menu? It should look like this:

<ul class="menu dhtml_menu menu-root">

If it does, then something is wrong with our drupal_add_js call; otherwise, the problem is in the generation of the menu tree.

Edit: yelvington, not jrglasgow.

Guys,

probably the menu items that are not working have some forbidden characters, like () {} or []. Now the code eliminate such characters.

regards,

massa

From the symptoms currently described, it's equally likely that the Javascript file is missing from the module, or that the page in fact still uses the static block. There's a whole range of possible causes there.

In fact, if the script file isn't included at all, then I'd say your diagnosis is unlikely. That would be a Javascript problem, while the missing script tag is definitely a server-side issue.

What we have here are a variety of described issues:

- yelvington isn't getting any script file.
- jrglasgow is getting a conflict between DHTML Menu and Theme Developer
- Surprise is getting something else (which may be due to the invalid characters).

When a menu node name contains non ascii characters ie : "Dodaj zawartość" this node will not drop down on click. Is there a way to fix it?

Actually is not fixed. And is not working not even in the actual stable version. Please doo more testing for making your module compatible, or please specify on his project page his incompatibilities if someone report so.

- jrglasgow is getting a conflict between DHTML Menu and Theme Developer

Have you fixed this? Theme Developer is a very popular module. If they are not compatible, please specify this too

- Surprise is getting something else (which may be due to the invalid characters).

They are not "invalid" characters. They are international languages specific diacritics.
And that was a problem on my romanian language site too. Romanian language (Romania) contains those special characters : ă, â, î,ş and ţ , so i have to uninstall this module for now, as it's usseless for me at this moment.

Thank you for your work on this module and keep up the good work.
Marcel Cozma

Theme developer heavily modifies the dynamic behavior of the web page. I am unable to get it to work with any other number of other jQuery-reliant modules, including Fivestar and the new localization module. The bottom line is: Switch Theme Developer off while you are not actively developing a theme, and don't expect any other jQuery stuff to work normally while it is enabled. This is kind of obvious.

Javascript does not allow certain characters as internal identifiers (ID attributes), which means that in these identifiers, the characters have to be removed. It appears that the filter currently fails to remove certain characters, which breaks the behavior.

hi Arancaytar. Can you please google about i18n-ascii.txt and maybe you'l find a way to implement this in your module ? That will boost up your your module very much and will be possible to be used on international sites with languages that contain strange characters.

http://svn.textpattern.com/development/4.0/textpattern/lib/i18n-ascii.txt

See pathauto module, maybe will inspire you ... :

it has an option: Transliterate prior to creating alias
(When a pattern includes certain characters (such as those with accents) should Pathauto attempt to transliterate them into the ASCII-96 alphabet? Transliteration is determined by the i18n-ascii.txt file in the Pathauto directory.)

For the people that think that dhtml_menu does not work with non latin characters:

I just tried it with Greek language (Greek Characters in the menu) and a clean install of Drupal 6.1

If language is enabled later (after dhtml menu),
dhtml menu has to be disabled and re-enabled in order to work for the extra language
(that is what happened to me at least)

Guys,

the last version for D6 i fixed it. It was a jQuery problem.

regards,

massa

Not really fixed. Please see also #234849: DHTML does work only in the english language.
In Firefox DHTML Menu stops working for both Navigation and Primary Links when logged in as admin and after click on a menu item.
In IE DHTML Menu is collapsing after each click on a menu item.

Guys,

i think its "again" fixed. I strip all character except a-z A-Z and _. So no more non-english characters messing around ;)

regards,

massa