#9 Menu not functioning when minus-sign used in name.

[Peter van der Meer]

Version: 3.1.5 (development)
OS: Debian Linux, Apache2 webserver, PHP4
Browsers:
Konqueror 3.2.2 (Using KDE 3.2.3)
Mozilla Firefox 0.8 (Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.6) Gecko/20040614 Firefox/0.8)

Problem:
Submenus don't expand when minus-sign is used in
menu-names.

Konqueror reports error on line 46 about a non-defined
variable.

Attached file is equal to file example-hormenu.php from
version 3.1.5. , except for the menu name. This file
gave the error in my system, so it should give the same
error when tested against 3.1.5 elsewhere.

[Peter van der Meer]

Hormenu, with only menu-name changed to one with minus sign.

[Marco Pratesi]

Logged In: YES
user_id=65709

The problem reported by the JavaScript Console of Mozilla
1.7 is:

Error: missing ; before statement
Source File:
http://localhost/~pratesi/phplayersmenu-3.1.5/example-hormenu-with-error.php
Line: 97, Column: 8
Source Code:
var hor-menu1TOP = getOffsetTop('hor-menu1L1');

It seems that the problem arises because, in JavaScript,
hor-menu
has the same meaning of
hor - menu
i.e. it indicates the difference between two variables.
Actually, the menu name is used here and there
in the JS resulting code, for JS var names.

Maybe this problem can be corrected, as an example,
using JS vectors ( foobar['hor-menu'] ) instead of such vars,
but I ask for your opinion: is it really worth the effort
just now[*]?
Such changes would affect some JS code that has passed
some *months*/*years* of testing... probably the change
would not add bugs/problems, but... sometimes theory
and practice do not agree :-)
After all, this sound more like a limitation in the "legal"
syntax
of the menu names, rather than like a true bug.
And probably, removal of this syntax limitation could be
postponed to the 3.3/3.4 branch, when a lot of old browsers
will be no more supported and the amount of needed tests
will be significantly smaller.

[*] in my plans, the next release, ASAP, would be 3.2beta

Ideas?

Marco Pratesi

[Peter van der Meer]

Logged In: YES
user_id=1047440

When you describe the problem, it indeed sounds logical. I
somehow just never thought about the idea that the menu name
would be used as a javascript-variable-name. I think this
means that menu names like: "My Supermenu", "J&JMenu",
"12moveMenu", "MENU", "public", "default" and "new" would
also be forbidden.

Since the work-around for the problem is simple (just don't
use any menu-names which would be invalid
Javascript-variable-names), I think it's ok not to make too
much trouble about this problem for now. Since most of the
users would be web-developpers anyway (otherwise they would
not be including a menu in a website) they should be able to
find and solve this kind of problems by themselves.

But on the other hand, the two main reasons for
web-developpers to use a menu from internet instead of
creating one by themselves would be insufficient knowledge
or time-savings compared to creating a menu by themselves.
And I think solving a (naming-)problem even before it
occeurs (by allowing more characters in menu-names) would be
a great service for both of these groups. So maybe we could
move this bug-report to the section "feature requests", so
that it's not forgotten and so that you can look at it when
you see fit (probably near the 3.3/3.4 branch). :-)

[Nobody/Anonymous]

Logged In: NO

The following change in menu/lib/layersmenu.inc.php

$this->tree[$cnt]['parsed_href'] =
(trim($this->tree[$cnt]['href']) == '') ? '#' :
$this->prependedUrl .
str_replace("#","%23",$this->tree[$cnt]['href']);

Enables phplm to display menu with "#" in their name and
link. Maybe something similar will help out.