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


Version: 3.1.5 (development)
OS: Debian Linux, Apache2 webserver, PHP4
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)

Submenus don't expand when minus-sign is used in

Konqueror reports error on line 46 about a non-defined

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.


  • Marco Pratesi

    Marco Pratesi - 2004-07-05

    Logged In: YES

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

    Error: missing ; before statement
    Source File:
    Line: 97, Column: 8
    Source Code:
    var hor-menu1TOP = getOffsetTop('hor-menu1L1');

    It seems that the problem arises because, in JavaScript,
    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"
    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


    Marco Pratesi

  • Peter van der Meer

    Logged In: YES

    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). :-)

  • Peter van der Meer

    • priority: 5 --> 1
  • 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 .

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


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks