• Ed Gray

    (@graynotgrey)


    Just prior to the 13805 revision, the new menus function pretty much worked with the exception of the child-menu hierarchy. Sub-menus would become the child menu of the sub-menu above it after you saved the menu layout. For example, if you had a category with a list of sub-categories indented once underneath it, when the layout was saved, the subcategories would displayed in a step pattern with each sub-category a child menu of the sub-category that preceded it.

    However, after revision 13805, I cannot create or edit any new menus. I cannot display any pages or categories. The following javascript error occurs when the page loads in Safari, Chrome and Firefox on a Mac:

    Error: a(".menu li").draggable is not a function
    Source File: https://mywebsite.com/wp-admin/load-scripts.php?c=1&load=jquery,jquery-ui-core,jquery-ui-tabs,jquery-ui-sortable,utils,nav-menu&ver=6b258d5b7154e050607e22b1cd5f0ec2
    Line: 193

    BTW, I’m running code from trunk via SVN with a variety or popular plugins on a 1&1 shared hosting account. Everything else appears to be working normally.

Viewing 7 replies - 16 through 22 (of 22 total)
  • Les Bessant

    (@lesbessant)

    And, replying to myself – in the case of the broken site, the “Page Options” button does not work.

    In any case, if it’s trying to load as much data as it appears to be, the menu page is likely to crash and burn on a lot of sites.

    Ptah.ai

    (@ptahdunbar)

    Thanks all for providing detailed feedback. We’re working on addressing these issues to make menu management more scalable.

    Thread Starter Ed Gray

    (@graynotgrey)

    I looked at the source of my current page. It not only includes the title of each page and post, but the full text of the article. I only have 120 posts on my site, but when I copied the source and saved it to a text file it was 1.1 MB is size. I do not think you want the full text of every article in the source of the menu page.

    The sub-menus also do not stay in the order I arranged them when I save the menu.

    pbassham

    (@pbassham)

    Im not doing lots of testing and searching, but it seems like that is a possibility. I have 4300 posts on mine.

    I just ran into this bug with WordPress 3.0a from trunk (r14008). I have not yet looked very deep, but my situation might help diagnose the problem for others:

    • I am running a custom theme based on twentyten.
    • I have only 337 posts and less than 40 tags.
    • I have only two active plugins: jlanguage-2.2 and sociable
    • The nav-menus screen works when there are no menus
    • If there is a menu, the screen breaks on the same error mentioned earlier (TypeError: Result of expression 'a(".menu li").draggable' [undefined] is not a function.) — after which all interactive JS-driven elements are broken.
    • The footer doesn’t load on the page either.
    • The offending script is located at https://mydomain/wordpress/wp-admin/load-scripts.php?c=0&load=jquery,utils,nav-menu&ver=0d17d2e2cfe267059361dddab4601bc5
    • Somehow the screen does work on my local installation, although I don’t yet understand why.

    The load-scripts.php output makes this issue quite hard to debug, but it looks like jquery-ui-draggable is not properly loaded (even though it is requested with a wp_enqueue_script( ‘jquery-ui-draggable’ ) line).

    I hope this is somehow helpful ??

    Looking more deeply at the problem, I think you guys are already way ahead of me. The page source is huge because it includes the whole body of all posts and simply gets cut off somewhere along the way with an error: <b>Fatal error</b>: Allowed memory size of 33554432 bytes exhausted (tried to allocate 209850 bytes) in <b>/srv/www/micheljansen.org-wordpress-staging/releases/20100405183138/wp-admin/includes/nav-menu.php</b> on line <b>217</b>. Because the script dependencies are not loaded until the footer (isn’t that a bad idea to begin with?), which gets truncated in this case, the page breaks.

    A temporary workaround is increasing PHP’s memory_limit so it fits, but obviously this will only work for small scale blogs like my own.

    Here is a really quick and dirty hack that reduces the output a little (but more can be removed safely presently):


    ---
    wp-includes/nav-menu-template.php | 4 ++--
    1 files changed, 2 insertions(+), 2 deletions(-)</p>
    <p>diff --git a/wp-includes/nav-menu-template.php b/wp-includes/nav-menu-template.php
    index ff1cccf..8b9372a 100644
    --- a/wp-includes/nav-menu-template.php
    +++ b/wp-includes/nav-menu-template.php
    @@ -188,7 +188,7 @@ function wp_get_nav_menu_item( $menu_item, $context = 'frontend', $args = array(
    $output .= '<input type="hidden" name="menu-item-type[]" value="'. esc_attr( $menu_item->type ) .'" />';
    $output .= '<input type="hidden" name="menu-item-title[]" value="'. esc_attr( $menu_item->title ) .'" />';
    $output .= '<input type="hidden" name="menu-item-url[]" value="'. esc_attr( $menu_item->url ) .'" />';
    - $output .= '<input type="hidden" name="menu-item-description[]" value="'. esc_attr( $menu_item->description ) .'" />';
    + $output .= '<input type="hidden" name="menu-item-description[]" value="" />';
    $output .= '<input type="hidden" name="menu-item-classes[]" value="'. esc_attr( $menu_item->classes ) .'" />';
    $output .= '<input type="hidden" name="menu-item-xfn[]" value="'. esc_attr( $menu_item->xfn ) .'" />';
    $output .= '<input type="hidden" name="menu-item-attr-title[]" value="'.esc_attr( $menu_item->post_excerpt ) .'" />';
    @@ -212,7 +212,7 @@ function wp_get_nav_menu_item( $menu_item, $context = 'frontend', $args = array(
    $output .= '<input type="hidden" class="menu-item-append" value="'. esc_attr( $menu_item->append ) .'" />';
    $output .= '<input type="hidden" class="menu-item-target" value="'. esc_attr( $menu_item->target ) .'" />';
    $output .= '<input type="hidden" class="menu-item-attr_title" value="'. esc_attr( $menu_item->attr_title ) .'" />';
    - $output .= '<input type="hidden" class="menu-item-description" value="'. esc_attr( $menu_item->description ) .'" />';
    + $output .= '<input type="hidden" class="menu-item-description" value="" />';
    $output .= '<input type="hidden" class="menu-item-classes" value="'. esc_attr( $menu_item->classes ) .'" />';
    $output .= '<input type="hidden" class="menu-item-xfn" value="'. esc_attr( $menu_item->xfn ) .'" />';
    break;
    --
    1.7.0.2

    My menu only has about 45 items, and the site is new and still quite small (<50 pages, <50 posts, <30 tags, <12 categories). The menu contains pages exclusively, or external links, no tags or categories. Yet when I try to save a menu change, my site crashes with a “500” error about 8 times out of 10. I am running the twenty-ten theme with WP 3.0, with a child theme. This menu problem has been ongoing before the child theme and before any plugins were activated. I’ve tried increasing the time-outs in php.ini without effect. This is quite frustrating. I see in the bug-tracker forum that this issue was discussed, and closed as resolved, but it isn’t resolved on my site and I would like to see it reopened. The site is https://lifering.org

Viewing 7 replies - 16 through 22 (of 22 total)
  • The topic ‘Menus completely broken in 13805 revision’ is closed to new replies.