Sync failing with large number of pages

[benplum]

The sync silently fails when the page tree is very large (1700+ pages). The ajax request returns a "success" message, however the menu is not actually updated.

[benplum]

I think it may have to do with how the data is being submitted. PHP has a limit set on the number of GET and POST vars (usually around 1000). Can the data be JSON encoded and submitted as a single param instead of nested GET arrays? I can keep upping the param limits, but this can introduce a security risk if the server accepts too many at once.

[kylephillips]

The menu sync doesn't actually submit any data that relates to pages. The ordering of pages does (triggered when dragging/dropping pages), but that submits a single POST request with an array of page IDs.

I'm guessing it's failing due to a large number of queries and possibly timing out. I'm actually in the process of optimizing the listing page, and am planning on applying some of the same logic to the menu sync. So far, it's down to around 4x fewer queries, at least in my tests.

If that fails to solve the problem, I'll most likely at some point add a "sync manually" feature for sites with very large numbers of pages. Rather than update every time a page is reordered, it'd be triggered with a button.

[benplum]

I see that it's a single "array", but the way the browser posts arrays is to split each item into an individual param, which you can see in the network panel of the dev tools. PHP defaults to 1000 params and simply strips the remainder. You can always up this number with a server param, but people on a shared host probably won't have that option (and it defeats the original purpose of the limit). I ended up getting the JSON edit to work, which did speed up the sync (however the server's memory limit needed to be updated to avoid a true timeout error). I can submit a pull request for your review.

Faster queries would certainly help, any idea on a timeline for that release? And a manual sync button would be great, especially when initially populating large amounts of content. For now we've been disabling sync while adding pages, then re-enabling once the positioning looks good.

[benplum]

A little more info. Turns out running PHP as a FastCGI was causing many of the 500 errors. Switching to an Apache module fixed the problem. Might be worth noting in the docs if others experience the same issues.

[wgroenewold]

Sync to menu fails if the number of items > amount wp_nav_menu() can handle. This is usually limited by the max_input_vars setting.

We circumvented this problem by generating a menu while not using wp_nav_menu()

function gho_menu(){
    $args = array(
        'posts_per_page' => -1,
        'post_status' => 'publish',
        'orderby' => 'menu_order',
        'order' => 'ASC',
        'post_type' => array('page', 'np-redirect')
    );

    $data = get_posts($args);

    $walker_page = new gho_unlimited_walker();
    $genmenu = $walker_page->walk($data, 0);

    return '<ul class="menu">' . $genmenu . '</ul>';    
}

The walker is just a normal walker-template with the values set right which extends to Walker_Page instead of Walker_Nav_Menu. Is it an option to integrate this in Nested Pages if the page-amount > amount max_input_vars can handle?

[drewbaker]

I think I'm seeing this with 1432 pages trying to sort in the page list view. I don't use menu sync. Using version 3.1.11 of the plugin.

The UI will respect the drag-drop of the page, and I get a success message back, but if I reload the page the order is back to what it was.

Here is a GIST of the HTTP request:
https://gist.github.com/drewbaker/0084d74de0d9c37ec99ecd0d8ebc0bfe

I suspect you're right that the server is capping the request param/request length.

[PLUS-RobertEhrenleitner]

Not when synchronizing the menus, but at least when reordering the pages, the same problem occurs. This is fixed with PR #337.