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

open
nobody
None
1
2004-07-06
2004-07-05
No

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.

Discussion

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

     
  • Marco Pratesi
    Marco Pratesi
    2004-07-05

    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

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

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