Support

Account

Register Login

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

Search Results for 'max_input_vars'

reply

  • Hi @thestart,

    Thanks for the post.

    It is possible that your server is terminating the save process before ACF can finish the field’s save process.

    Please increase your max_vars setting by making the following changes to your php.ini file:

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

  • The problem was max_input_vars.
    I should have looked harder for the earlier thread, which I already seen, bearing the solution – http://support.advancedcustomfields.com/forums/topic/stuck-at-59-fields-not-saving-more/

    max_input_vars = 10000;

  • Hi John,

    I had extensively googled the issue and multiple times ran into this max_input_vars suggestion so I had already tried adding the following lines in my .htaccess file:

    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

    Unfortunately this didn’t seem to help with my particular problem.

    I have found that after I was able to change the field keys back to what they were supposed to be set as from phpmyadmin the fields were saving again. (I looked them up on the staging server where the field keys were still correct since I hadn’t updated the field group)

  • I’m not sure about the second comment you made, but the OP sounds like a problem with a php setting max_input_vars This can happen when submitting more fields that is allowed by PHP. Try installing this plugin and then saving the post where you’re having problems with things not saving. If this is the problem you’ll get a popup that will tell you what you setting is. https://wordpress.org/plugins/wp-max-submit-protect/

  • Check your:
    1) max_input_nesting_level
    2) max_input_vars
    in your php configuration, I set it to:

    1) max_input_nesting_level=256
    2) max_input_vars=5000

    and i`ts fix my problem.
    Hope its helps you.

    P.S. Sorry for my bad english)

  • The limitation to any number of fields is caused by a PHP setting. The php setting is max_input_vars. This limits the number of fields that can be submitted in a form. You will need to increase this value.

  • You’re running into a problem with max_input_vars. You need to raise that. This is a good plugin for letting you know what you’re submitting more inputs than your server allows. https://wordpress.org/plugins/wp-max-submit-protect/

  • the php setting form max_input_vars can cause odd things like this to happen. Try installing this plugin and see if you get an error when submitting https://wordpress.org/plugins/wp-max-submit-protect/

    If that’s not it then you need to start deactivating plugins to see if there’s some incompatibility that causing it.

  • There isn’t any way to hide the repeater field so that it does not load. There is a plugin that will collapse them https://wordpress.org/plugins/advanced-custom-field-repeater-collapser/

    There is not limit to the number of rows you can have in a repeater except for settings in PHP and the physical limits of your server. There is a php setting named max_input_vars, if you go over the value of this setting then the excess rows will be ignored. There is a plugin available that will tell you when you’re exceeding the setting. https://wordpress.org/plugins/wp-max-submit-protect/

  • Hi John,

    Thanks for the advice. I totally agree with that. Since we’ve identified that it was required to increase the max_input_vars, we are right know redeveloping the field groups structure for a better approach, creating a couple of more custom post types instead and reducing the amount of fields per group.

    Cheers,

    Milton

  • Hi John,

    Thanks for that, I didn’t even consider the max_input_vars as part of the problem, but in fact it was. Increasing the limit solved the issue and ACF is now able to “update” the current field group JSON file rather than creating a new one.

    I didn’t realise my field group is that big now. Probably the only thing that makes me think it was something related to the ACF plugin was that I always got a “field group updated” successful message instead of a warning or error and the fact that it creates another JSON file.

    Anyways, thanks for the tip mate.

    Cheers,

    Milton.

  • Yes, that does clear thinks up a bit. I will take a look at this.

    I have one suggestion though without looking too closely though. Usually when fields and field data disappear when saving a field group and other odd things like this it’s because you running up against the limit of the php setting max_input_vars.

    Without duplicating a field your field group has 15,245 fields. I’d say that you’ve already increased max_input_vars before or you couldn’t have saved what you posted. You might want to increase it again. I find this plugin very helpful when developing large complicated fields groups. https://wordpress.org/plugins/wp-max-submit-protect/

    Let me know if that does not solve your problem.

  • Has this topic been abandoned? I too am having this issue. I built a page template for a client to showcase breweries at an upcoming event. There are 14 subfields inside 124 repeater fields and that seems to be the limit the browser will handle. I have upped their max_input_vars to 6000 but still no dice. I don’t want to have to go back to them and say “Sorry that’s all it can handle.” If I had known this would happen I would have made the breweries into their post type and looped through them like that. Will this issue ever be resolved? Is there a way to show like 20 repeater fields and then paginate the rest in the admin area? Or do something similar to what was done here (http://sevenspark.com/wordpress/speeding-up-the-appearance-menus-screen-in-wordpress-3-6) for WP menus prior to 4.3?

  • Hi @gwenzez

    Thanks for the question.

    There is no limit to the number of custom fields that can be added to a field group or in your case the repeater. Your server might be terminating the save process before ACF completes its job, you will need to increase the max_vars PHP setting. You can make the following changes to your php.ini file:

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

    The WSOD might also be as a result of a plugin conflict, please deactivate all other installed plugins and switch to one of the stock WP themes to check if the issue will still pop up.

    To update the plugin you will need to log in as an admin.

  • When this happens it is usually a problem with the PHP setting max_input_vars. You need to increase the value of this setting. To see where it is and to prevent loosing data try this plugin https://wordpress.org/plugins/wp-max-submit-protect/

  • It seems odd because the field group does not look that large. Are there other field groups on the pages. Usually when a field does not save it has something to do with the php setting max_input_vars.

    Can you install this plugin then attempt to save and let me know if you get the popup warning?

    https://wordpress.org/plugins/wp-max-submit-protect/

  • Thanks for the responses. I’m actually on a dedicated server, so increasing the memory really does increase the memory. And yes, I’m sure that my max_input_vars and memory limit are correct by verifying in the php info.

    I added these:
    max_input_vars = 3000
    suhosin.get.max_vars = 3000
    suhosin.post.max_vars = 3000
    suhosin.request.max_vars = 3000
    Per the FAQ, although I bumped those all up to like 16000 with still no results. And memory is at 800MB currently.

    I was in the process of adding new fields when this started happening. I had to add 7 and I made it to 5 before it stopped working for the final 2. So I’m sure that no other plugins were updated or installed and I’m certain nothing else on the site was being changed either during the additions. It just decided to stop at 60 and making these changes hasn’t worked. I’ve also checked the database manually to be sure that it wasn’t some display issue, but the new entries I created (that ACF said were created successfully) are not in the database either. Thanks again.

  • Okay, and you’re sure you’re actually getting 800mb? If you are on a shared hosting it’s possible your own changes to for example wp-config or htaccess isn’t being used.

    Could you try creating a file info.php in your server root and place:
    <?php phpinfo(); ?> in it. Then go to yourdomain.com/info.php .. There you should be able to find what your memory_limit and max_input_vars are really set to.

    As for the php errors it’s only the last one about headers that I think might be doing some actual damage. Seems something (either your theme or a plugin) is trying to output things before they should.

  • This is primarily caused by the php setting max_input_vars. You will need to increase it.

    This plugin will tell you when you form exceeds the number allowed by your server: https://wordpress.org/plugins/wp-max-submit-protect/

  • That is a pretty large field group, and I can’t see what all of the field types are due to the errors, are some of them repeaters or flexible content with nested fields?

    Running into trouble with the php setting max_input_vars can cause strange results.

    Try installing this plugin: https://wordpress.org/plugins/wp-max-submit-protect/

    It will tell you if there are more fields being submitted than is allowed. This is actually what I initially suspected.

  • Glad you found the problem. Yes, exceeding max_input_vars can cause some strange behavior. I find this a must install plugin during development of new sites https://wordpress.org/plugins/wp-max-submit-protect/

  • Thank you, John. It turned out that we needed to increase max_input_vars in our php.ini. It started to do some very weird things once we went over the limit. It took a while to figure out but it’s all fixed now.

    Thanks. 🙂

  • Hi @bruno-martins

    I am not sure what you mean by “It does not work” is the Repeater field not saving values? If this is the case, it may be related to the field_name length.

    ACF uses the field’s name to save a value into the database. When saving sub fields, the ‘save name’ is generated by the ancestors names + the row index and can become quite long. It is possible that the length of this ‘save name’ can become too long for the wp_options table, and WP will not be able to save the value at all.

    You can solve this by reducing the field name length.

    If the issue is to do with the field not saving, you can make the following changes to the php.ini file:

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

  • This is a problem with php.ini and the max_input_vars setting.

    Check out this plugin, it can tell you when you are exceeding this number and what that number is: https://wordpress.org/plugins/wp-max-submit-protect/faq/

  • http://support.advancedcustomfields.com/forums/search?bbp_search=max_input_vars

Viewing 25 results - 126 through 150 (of 211 total)
1 2 3 … 5 6 7 8 9