Support

Account

Register Login

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

Search Results for 'max_input_vars'

reply

  • Same problem here… and getting desperate…

    Checked max_input_vars, nesting_levels, input_time… Also changed option_name to 255 chars… Nothing.

    No errors neither in php logs, apache or mysql. No slow queries… I’ve debugged with save_post and acf/save_post and the array is complete in WP debug.log (it includes the not saved fields)… But they do not save to the DB…

    This behavior started after adding a repeater field in a field group. I had a lot of custom posts with custom fields working fine. Then realized I needed one more repeater field and added to the field group… This made the fields stop saving…

    Some magic would be greatly appreciated 🙂

    Latest version of WordPress and ACFPro at this time.

  • I have the same / or a very similar problem: I have a 9 fields with 10 nested repeaters each, all showing up on a page. The fields started saving ok, but after a while wp-admin would start to come up with issues. I have been able to fend these off with define(‘WP_MAX_MEMORY_LIMIT’, ‘-1’); , and the following php.ini entries:
    mysql.connect_timeout = 120
    expose_php = Off
    max_input_time = 42000
    allow_url_fopen=1
    max_execution_time = 42000
    memory_limit = 256M
    max_file_uploads = 256M
    file_uploads = On
    post_max_size = 256M
    upload_max_filesize = 256M
    max_input_vars = 50000
    max_input_nesting_level = 256

    However, there page now seems to have reached another ceiling and no matter what I do, it won’t save changes. It times out after 2 mins and goes to a 404 page(/wp-admin/post.php). MySQL has surprisingly appears to have 282359 wp_postmeta entries, which I thought was quite a lot, and the ACF seems to have stopped saving rows half the way through its last save.

    Any clues as to what might be causing this limit? Is it a timeout issue? There doesn’t seem to be a problem with the field character size as it’s not that long.

    Could anyone think of a reason?

  • I’m having trouble getting custom field values to save. I have increased the values of all of these variables to:

    • max_input_vars 18000
    • max_input_nesting_level 500
    • max_input_time 500

    I still cannot save my fields.

    I think the issue might have to do with having imported the database from a different WP install. The fields that were created for the old install continue to save. But any new fields I create don’t save. The new install is running on a localhost server. Also, I’m not using any caching.

  • Thanks Hube2. I have been developing locally in MAMP Pro. Here is what I did after some research into the solution you recommended.

    I increased this ‘max_input_vars = 3000’.

    In MAMP that is under File > Edit Template > PHP

    acf-zora-cre....txt

  • This is caused by the php setting max_input_vars

    Check out this plugin, it lets you know when you’re exceeding the limit.

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

    acf-zora-cre....txt

  • How many rows have you added to the repeater?

    Usually when there is a problem saving data in a repeater field is has to do with some a PHP setting on your server and having too many fields submitted.

    The PHP setting involved is: max_input_vars

    See what this setting is on your server and try to increase it.

  • I had a problem a while back where I would create flexible content rows but they would not save when I updated the page. The issue turned out to be PHP related and not tied to ACF. Check out this post and see if any of the ideas there help:

    http://support.advancedcustomfields.com/forums/topic/if-there-a-limit-to-number-of-subfields-one-can-have/

    Specifically, the PHP config setting max_input_vars might need to be increased.

    content-2015....xml

  • besides max_input_vars there are other things that can cause this, max_input_nesting_level & max_input_time may also cause problems.

    As you say, if you move it further up it gets saved and the later ones do not. This is definitely a problem with the input not getting there and not a problem with ACF itself.

  • I actually fixed this problem myself by changing max_input_vars in php.ini

    This might not be your problem but php 5.3 has a limit of 1000 input vars. When you have a lot of fields with say the collapsible field or repeater field you will get up to over 1000 variables pretty easily. I just upped mine to 10,000 and everything is working correctly.

  • I would like to chime in.
    After YEARS of having this issue I finally found this thread.

    For me it was 39 fields, meaning ACF didn’t count past 38.
    The only way I could fix this was by manually changing values in the custom fields column.

    By adding the line
    php_value max_input_vars 3000
    to my .htaccess I was able to correct this.

    Thank you for sharing this.

  • Hube2,
    Thank you! This was the issue. There are several ways to adjust the settings for the max_input_vars via .htaccess, php.ini, etc. Although, I had to go through my actual hosting control panel (WHM) and increase the value through there – This option should be in WHM -> Service Configuration -> PHP Configuration Editor -> Advanced. It was set to 1000 so I increased it to 3000. Thank you so much for your help. I’m only wondering now if there are any security issues with this limit?

    Thank you so much!
    Jason

  • You are probably running into a PHP max_input_vars issue. This PHP setting limits the number of fields that can be submitted through a form.

  • You’ve probably guessed it, looks like a max_input_vars problem. While it looks like you only have 360 fields, when creating field groups you need to mulitply that by all the different settings that are possible for each field (id, label, name, type, instructions, etc, etc.) There are probably at least 10 fields for every field you’re creating so that turns your 360 fields into 3600 fields being sent when you hit submit.

    This max_input_vars setting can be changed in php.ini or per directory if your hosting provider allows it. http://php.net/manual/en/info.configuration.php

    Usually, it the host allow it then you can add the a line like the following to your .htaccess file

    php_value max_input_vars 5000

    Some hosting providers also allow you to place a php.ini file into the root of your site that you can use to override the global server values.

    There are also some other ways listed here that I have not used personally and have not experienced hosts that allow them: http://php.net/manual/en/configuration.changes.modes.php

    If your host does not allow you to override php values in one of these ways, I don’t think there’s much else you can do. You’re best bet is to contact your hosting provider and ask them if they provide a way to make the change.

  • Aaaaaaand I answered my own question by digging a bit deeper into your forums. I found this thread: http://support.advancedcustomfields.com/forums/topic/repeater-field-values-disappearing/

    And discovered that dropping the following into my htaccess file fixed it:

    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

    Though I haven’t tested on my live server, only localhost, but I think that my problem was the max_input_vars thing. Yay!

  • Hi Elliot

    I think the problem was max_input_vars on the server. I’ll try again soon and let you know.

  • Then you have me stumped. The only time I’ve ever had a problem creating more fields is when I exceed max_input_vars.

    There are a couple other php settings you can try increasing:
    post_max_size
    max_input_nesting_level

  • I’m having a very similar issue. I’ve got a menu built out using a lot of custom fields and repeaters. Initially our issue in AC4 was that when you would click update it would take a long time to load then refresh and the new fields we had added would be gone. We upped max_input_vars and about every other PHP value I could think of.

    So I was hoping the upgrade would fix our saving issue, but it seems to have cropped up a different one. Now when I try to save I get the same “Uncaught TypeError: Cannot read property ‘length’ of undefined” error in load-scripts.php. This seems to go away when I delete some data / fields, but crops back up when I try to add it back in. Any suggestions?

  • You understand me correctly, I can not add more fields on the page is
    http://awesomescreenshot.com/0f635h2s43

    In the post, normally stored in all fields.

    max_input_vars 6000 Nothing has changed.
    http://awesomescreenshot.com/07635hbsb8

  • Your php setting for max_input_vars is 3000

    Look at the field group you’re creating. Each field you’re creating has many inputs there may even be a bunch of hidden inputs. If you add them all up they are most probably near your 3000 limit.

    When you submit the page to save your fields, if there are more than 3000, php simply throws away the excess, so they are not submitted to the script that needs to save your field group.

    Does your host allow you to increase that setting? I would suggest upping it to 5000 see what happens. If your host does not allow you do change that php setting then you’ll need to figure out a different way to accomplish what you want to do using less fields.

  • You are most likely running into a problem with your php installation rather than an ACF bug. PHP setting max_input_vars usually has a default value of 1000.

  • You need to alter your php ini setting max_input_vars. You’re reaching the maximum number of input fields allowed on your server.

  • Hi xanthonius,

    Might be too late, but I just had a similar issue and found this thread. For me it was caused by max_input_vars being set too low in php.ini.

    This setting controls how many variables will be accepted by PHP at once. Building a large ACF field group in the admin can require sending hundreds or thousands of variables to the server on save, so if max_input_vars is set too low and the field group you’re building is too big, your data gets truncated when you save it – in this case, probably in the middle of a conditional logic section.

    PHP documentation for the setting is at http://php.net/manual/en/info.configuration.php#ini.max-input-vars, but if you google ACF max_input_vars you’ll likely find more relevant help.

  • ok … looks like this is caused by the new default max_input_vars=1000 in php.ini. Changing that limit to 3000 solved the issue for me.

    Maybe it is possible to add a check into ACF to issue some kind of information or error if this happens?

  • Hey @jkuzma and @elliot,

    We were having this exact same issue for the last few days and it was getting extremely frustrating as things broke four days before our client site’s go-live.

    I read through all the other similar thread (ie. ‘field not saving data’) and tried the max_input_vars and memory limit fixes, to no avail.

    And then I bumped into @jkuzmas post and realized our problems has started right after we decided to stop using the admin’s template selection meta-box, but reverted back to only PHP based templating (like we’ve always done in previous projects, hence why we’ve never seen this problem before).

    So basically the problem was that the meta field _wp_page_template was set for a page, but the template didn’t exist anymore. Clear it empty, or better yet, fill it with the default phrase ‘default’, and everything works again.

    We suspect this has something to do with ACF’s location rules checks.

  • I tried creating a php.ini file containing

    php_value max_input_vars 7000

    and uploading it to my server but it ACF still won’t let me add any more fields or groups or anything…

Viewing 25 results - 151 through 175 (of 211 total)
1 2 3 … 6 7 8 9