Support

Account

Register Login

Home › Forums › Search › Search Results for 'max_input_vars'

Search Results for 'max_input_vars'

reply

  • Hi,

    You’re probably hitting your servers limits.. try asking your serverprovider to increase your max_input_vars

  • If you’re on a shared host its possible that your changes to max_input_vars does not apply.

    Try contacting your server supplier and ask them if they can bump it up for you 🙂 I believe 1000 is the default value which you need to increase

  • Brilliant, that did the job perfectly.

    For reference, i added:

    php_value max_input_vars 7000

    into my .htaccess file and all works now.

    thanks, Leon

  • There’s some similiar types of issues on the forum here:

    http://support.advancedcustomfields.com/forums/search/?bbp_search=max_input_vars+%3D+3000

    What solved my issue was dropping the following into the top of my WP site’s .htaccess file:

    php_value max_input_vars 7000

  • Adding php_value max_input_vars 1000 to 5000 in .htaccess helped me.
    Before that I had trouble saving fields and I could only add 7 of them.
    I too have a lot of nested fields: flexible -> repeater -> repeater.

  • After much research and much reading… I found the answer via another post on this website. I had to increase my php settings to allow more variables to be inputed.

    max_input_vars = 3000
    suhosin.post.max_vars = 3000
    suhosin.request.max_vars = 3000

    The post with the answer:

    http://support.advancedcustomfields.com/forums/search/?bbp_search=max_input_vars+%3D+3000

    Eliot, I know this issue is not related to your plugin, but just a php setting. However since it seems like a few people have already experienced the same issue, maybe you could have common solutions as this one placed somewhere easy to find in your support forum.

  • I’ve increased the value for the max_input_vars to 8000, and the problem is still not resolved. Can you give me any other direction to take?

  • I’m having a similar situation with repeater fields. There’s a limit to how many repeater fields in a row I can use before they stop saving. I used a custom php.ini in the site root to do the following:

    > php_value max_input_nesting_level 128
    > php_value max_input_time 300
    > php_value max_input_vars 3000
    > php_value max_execution_time 300
    > php_value post_max_size 32M

    But this did not fix the problem. I’m going to try to boost the max_input_vars to higher.

  • Update to WP 3.8 did not solve the problem. But I’ve increased the PHP default value from php_value max_input_vars 1000 to 3000. This did solve the problem. The field group I use has about 65 added entries. This gives at least 15 input vars per entry. This may help to estimate the necessary value of max_input_vars for others.

  • Hi @elliot,

    When layouts get lost after saving they are not available for selection on a post edit page any more. But as long as I don’t save the post the lost layouts will be displayed correctly on the front end.

    When I delete a layout (which contains 20 subfields) from the flexible content field, saving of the whole field group succeeds. Also adding a new layout afterwards, saves succesfully. But adding many subfields to that new layout resulted in a failure again. Deleting additionally another layout with nearly 20 subfields allowed me to save the new layout successfully.

    Creating and displaying a new field group containing a flexible content field is no problem.

    Also execution time is no problem. Other processes which need about one minute have finished successfully.

    Is it possible, that WP limits the number of max_input_vars?

  • I’ve also increased the memory on my server, and max_input_vars as well. Both to no avail. @elliot is there anything else we can try/do to help you debug?

  • I’ve exactly the same problem with a flexible content field now (acf v4.3.2 / Flexible Content Field v1.1.0).

    I did succesfully change the field group with older versions of ACF. The last change is about half a year ago. PHP value max_input_vars has always been 1000. Also there is plenty of memory available (256MB and page requests need about 60MB).

    The error already occurs if I simply change the value of ‘Maximum Layouts’. When saving this value is not stored, also the value of ‘Button Label’ is reset to the default and the last three layouts of the flexible content field disappear. But a change of the label field at the top is successfully saved. When exporting the field group in a xml file the missing layouts are not contained any more.

    When importing an earlier backup the missing layouts are back again. I’ve tested this on two servers.

    Do the newer versions of acf use much more input vars than before? Or may it be a bug in the plugin which cuts the input stream?

  • hi @elliot

    I think it isnt the same i already found the thread you send.

    i added this to my .htaccess
    php_value max_input_vars 5000
    php_value suhosin.get.max_vars 5000
    php_value suhosin.post.max_vars 5000
    php_value suhosin.request.max_vars 5000

    this didnt solve the problem

  • Silly me, of course the answer was not number of fields, but number of post vars…

    72 fields just happened to push the post vars count over PHP 5’s default limit of 1000. This issue also crops up with really large menus in WP.

    The fix:

    Add a php.ini file to /wp-admin/ and put these settings in there (assuming your host allows php.ini overrides):

    
max_input_vars = 3000
suhosin.post.max_vars = 3000
suhosin.request.max_vars = 3000

    From: http://anothersysadmin.wordpress.com/2012/02/16/php-5-3-max_input_vars-and-big-forms/

  • Ok i solved the issue…
    I had to increate php max_input_vars from 1000 to 3000

    I pasted this line of code into the htaccess file
    php_value max_input_vars 3000

  • @cleocq

    Many many many thanks!! This problem was bugging me over hours …

  • I also had to increase max_input_vars for my mega custom type …

  • Hi @CCDesignTeam

    The referenced topic talks about increasing the ‘max_input_vars’ variable in the php.ini file.

    This is a server file (Not in WP) and to find out where it is / how to edit it, you will need to contact your web host.

    Hope that helps.

    Thanks
    E

  • Ok, I resolved this. Couple of things to try – Ensure that the order of conditionals is correct, I had mine a bit messed, was adding an item in the middle instead of appending it to the end. I also increased the max_input_vars tp 6000 and threw the max_input_nesting_level to 10000.. I cannot say if they made a difference, I have limited time to test, I’m fairly confident that its the order that caused it to remove conditionals…

  • I can confirm that this is a maxvars issue. I have a repeater with just over 50 various fields. Adding additional fields outside of the repeater worked fine. Adding an additional field within the repeater caused some of the repeaters settings to revert.

    For example the repeater layout reverted from “Rows” to “Table” and the button label reverted from my custom string to “Add Row” and I couldn’t save my desired settings unless I deleted one of the repeater subfields.

    For those who stumble across this, I simply overrode PHP’s max_input_vars default (1000 I believe) in php.ini. 3000 did the trick for me.

  • Ok searching for this problem was killing me!

    Don’t forget to consider this:

    “I had the same problem and it turned out that because the server was using the Suhosin patch I also needed to set the following my .htaccess file:

    suhosin.post.max_vars = 20000
    suhosin.request.max_vars = 20000”

    I found it on stackoverflow and it solved my problem. Nobody speaks about this on ACF support forums.

    See u 🙂

  • Thanks guys! I was hitting up the max_input_vars limit in my php. Bumping that up in my PHP config file solved the issue.

  • Hi elliot,

    I don’t know what you excactly mean, but the workaround in the other high topic to this problem

    http://support.advancedcustomfields.com/forums/topic/max_input_vars-solution-not-working-for-me/

    with the user.ini fixed it. But I don’t think that this should be a solution for ever …?

    But I think about a way we don’t depend on such big field groups:

    Is there a chance that you can implent conditional (tab and/or hide) logic over field groups? Than we can split big field groups and can use tabs and/or hide fields furthermore.

    Or add a new field typ “field group” so we can include a field group in a field group.

    Edit: Another user had the idea a month ago:

    http://support.advancedcustomfields.com/forums/topic/reusable-field-groups/

    Greetings,
    Svenni

  • spoke to soon – the max for this one seems to be 70

  • Hi Websupporter

    just wanted to let you know that I rolled back to 4.1.8 (svn) and can now add more fields

    the issue seems to have occurred in 4.2.0 (svn)

Viewing 25 results - 176 through 200 (of 211 total)
1 2 3 … 7 8 9