In the meantime I have found a way around it by extending the max var limit setting on the server level (many thanks to Shawn for all the legwork in first finding the cause of the issue and then steering me towards the solution).
By the looks of it, it basically depends on the sever API used (which you can find out with a PHP info file, it will be the 4th entry in the list) if you can solve it by adding the code in a htacess file (in most cases by the looks of it) or by using a .user.ini file (in the case of the server using CGI/FastCGI, which was my scenario).
In the htaccess file you add:
In the case of suhosin being used you'd also add:
That should do the trick. Be sure to check with a php info file if the values were indeed changed.
In the case of CGI/FastCGI using the htaccess route for this will result in a 500 internal server error.
Here you can solve it by pasting the following into notepad:
And for suhosin:
save as .user.ini and upload to the root of the website
Once again be sure to check with a php info file if the values were indeed changed.
Scenario 2 worked for me (though I didn't need the suhosin bit).
However your mileage may vary as it really depends on the settings of your hosting party if they allow these scenario's (or have disabled the functionality). By the looks of it quite a few hosts will, but I've also read stories of people still hitting a brick wall.
In any case, using the solution above i18n navigation will once again save the navigation structure when using page numbers bigger than 166.
Hope this is of help to somebody
By the looks of it, it basically depends on the sever API used (which you can find out with a PHP info file, it will be the 4th entry in the list) if you can solve it by adding the code in a htacess file (in most cases by the looks of it) or by using a .user.ini file (in the case of the server using CGI/FastCGI, which was my scenario).
In the htaccess file you add:
Code:
php_value max_input_vars 2000 (or whatever value you want to use)
In the case of suhosin being used you'd also add:
Code:
php_value suhosin.get.max_vars 2000
php_value suhosin.post.max_vars 2000
php_value suhosin.request.max_vars 2000
That should do the trick. Be sure to check with a php info file if the values were indeed changed.
In the case of CGI/FastCGI using the htaccess route for this will result in a 500 internal server error.
Here you can solve it by pasting the following into notepad:
Code:
max_input_vars 2000 (or whatever value you want to use)
And for suhosin:
Code:
suhosin.get.max_vars 2000
suhosin.post.max_vars 2000
suhosin.request.max_vars 2000
save as .user.ini and upload to the root of the website
Once again be sure to check with a php info file if the values were indeed changed.
Scenario 2 worked for me (though I didn't need the suhosin bit).
However your mileage may vary as it really depends on the settings of your hosting party if they allow these scenario's (or have disabled the functionality). By the looks of it quite a few hosts will, but I've also read stories of people still hitting a brick wall.
In any case, using the solution above i18n navigation will once again save the navigation structure when using page numbers bigger than 166.
Hope this is of help to somebody
(2014-02-22, 05:58:08)shawn_a Wrote: @mvlcek
Found the issue, new versions of php have a default max limit of post items.
http://php.net/manual/en/info.configurat...input-varsCode:max_input_vars 1000
As well as susohin
Code:php_value max_input_vars 1000
php_value suhosin.get.max_vars 1000
php_value suhosin.post.max_vars 1000
php_value suhosin.request.max_vars 1000
You are sending 6 fields per menu item leaving a max of 166 items in menu.
You can probably convert these to post arrays for each item to increase this, or serialize of course.
ref .
http://stackoverflow.com/questions/10303...input-vars