Support

Account

Register Login

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

Search Results for 'max_input_vars'

reply

  • Hey @eddr,

    Do you have a lot of fields? Before I had the problem with the same field names, my problem was that the max_input_vars setting in php was set too low (default is 1000 I believe).

    Maybe you can check your php log and see if it gives you any errors about that? And if it does put something like php_value max_input_vars 3000 in your .htaccess file, or edit (if you can) your php.ini file.

  • Try installing this plugin https://wordpress.org/plugins/wp-max-submit-protect/, attempt to save your new fields and see if you get a warning message about exceeding max_input_vars.

  • Our PHP settings of max_input_vars = 5000, we are not using JSON. About field_name, we tried to change field name but still no changes.

    My option_name in DB looks like that:
    option_name varchar(191) utf8mb4_unicode_ci Yes NULL

    We tried to add Page Link field outside the repeater, and this is working. So seems like the problems is only inside repeater fields. But it was working this way for few years, why would suddenly stopped working? Any other clue?

  • All the research I’ve done leads me to believe that it has something to do with this Sohosin extension. I don’t know anything about it, but it seems to me to be another attempt at protecting php coders from themselves.

    One thing that I did find out is that Suhosin sets max_input_vars to 200, this is an extremely small number. At a minimum, using ACF, this should be 2000. Not having this high enough can cause all kinds of strange behavior.

  • update:
    found some post on this forum about this problem, so i’ve:
    – changed max_input_vars to 55555000 (a default value given from my hosting provider, but big enough)
    – changed wp_options/option_name lenght to 256 (not sure i did it properly, see attached screenshot)
    Unfortunatly my problem is stil there

    Schermata-20....png

  • It sounds like you’re running into an issue with the php setting max_input_vars. This plugin will let you know if you are https://wordpress.org/plugins/wp-max-submit-protect/

  • Hey james, thanks for the reply. I increased the max_input_vars since my folder is in subfolder I put the php.ini file in the site folder when the root did not work and that did not work. I also installed the site on my local server, imported the fields on a fresh local wordpress install even restarted apache. It still does not work :'(

  • Hi @salshine

    That’s weird. Could you please try the to increase the max_input_vars variable on your server? This page should give you more idea about it: https://www.advancedcustomfields.com/resources/limit-number-fields/.

    Also, could you please try to reproduce the issue on your local machine?

    Thanks 🙂

  • Hi @salshine

    It’s possible that you have an issue with the max_input_vars variable. Could you please check this page to learn more about it: https://www.advancedcustomfields.com/resources/limit-number-fields/

    If the issue persists, could you please open a new ticket and provide the credentials to your site here: https://support.advancedcustomfields.com/new-ticket?

    Thanks 🙂

  • ACF is a great tool, and I wouldn’t use anything else, but it does have its limits. I created a site with a field group that would actually time out the server. Since then I’ve found that limiting how many fields you add, especially when it comes to some types of fields is a good idea. In your case I would break the group down to multiple options pages and group the fields logically.

    The problem is not really in ACF. The problem is in WP. WP does not have any way built into it that allows updating multiple meta fields or options values in a single query. Each value to be updated creates several db calls and at a certain point the number of db queries drags down the page speed.

    As far as fields not saving properly, James is most likely right that this is caused by going beyond the max_input_vars php setting on your server.

  • Hi @geert

    Hard to know where to start…

    Okay, so most people on the web with a WordPress site probably has shared hosting (I’m guessing). They have little to no control over the servers settings and limitations. Here’s some standard PHP values which are unlikely to be set higher in such shared hosting:
    http://php.net/manual/en/info.configuration.php

    disclaimer: I’m not gonna research everything here before (limited time) so some is a little bit of guesswork when it comes to numbers.

    max_input_vars there is one of the most interesting ones. Basically it says that PHP will accept a maximum of 1000 input fields to send to a single request (page load). In the case of WP admin that would likely be a POST request. WordPress per default already have quite a bit of fields for a standard edit screen. There’s a whole bunch of hidden fields as well as formats, categories, tags, featured image, title, editor, permalink, visibility, status etc. Let’s say you also have a few regular custom fields. Then you also add a repeater field to this. Each row might contain 2-10 fields + some hidden fields ACF uses to keep track of everything. Maybe you even have nested repeaters! So for each row there’s 2-10 fields + a nested repeater which in term contains 2-10 fields. And say you add in a gallery field there as well. That’s at the very least 1 field for each image.

    You’re quickly gonna find that you hit the 1000 input vars limit if you abuse repeaters. That’s gonna stop you from adding any new content to the page before you delete other. That in itself should be enough to reconsider huge repeater fields. But to make matters worse there’s also server limits like max_execution_time and max_allowed_packet (mysql). Saving all these fields will take some time and if you’re not on a great internet connection you may hit the max_excecution_time which will lead to your page save ending abruptly and unfinished. max_allowed_packet is a variable for mySQL which basically limits how large of data chunk you may insert in one go. It’s much harder to hit but it’s possible.

    If you’d be on a VPS you could prevent all of this by just upping your server stats. However you’ll still get a very slow admin experience and let’s face it, you’re patching a leaking boat and probably have to pay a hefty price for it (big servers aren’t cheap).

    Then there’s also the issue of WordPress database structure and the performance of WP_Query. 10up has written a great article on performance with WP_Query and one of the things to avoid is post meta lookup. Usually there’s no choice BUT we can at least do what we can to use simple post meta like a single date field or a boolean. And of course try to minimize the amount of post meta for each single post. https://10up.github.io/Engineering-Best-Practices/php/#performance
    Consider that ACF adds two rows to wp_postmeta for each field (both regular and sub fields).

    So if we can refactor our data structure to use a custom post type which would contain some fields and then perhaps link different posts/post types together with the post object or relationship field we’ll end up with safer and quicker admin requests, faster and often more versatile use of wp_queries in our front end and a better DB structure more fitting of WordPress strengths and weaknesses.

    It’s hard to say a number of repeater rows that’d be “too much” since it depends on what they contain. But for me, if I find that I’d end up with more than 20-30 row of simpler repeater data or 10-15 rows of more complex ones I would consider a different solution. Sometimes it’s hard to predict tho. We’ve had customers where they were supposed to use repeaters for just a few categories of Press media attachments but they ended up dumping soooo much media there that we eventually had to rebuild it for them with a CPT where each post was a single media file and a taxonomy for the categories of media.

    Hope that was a sufficient answer 🙂

  • Just got this resolved. Had to increase the php setting for max_input_vars from 1000 to 2000.

  • Hi @etiennedupuis

    Have you seen that in later versions of ACF you can collapse/shrink a repeater row to a single “line” with your chosen field value on it?

    If you still find it unmanageable, to be frank, you should reconsider how you structure your data. There are more and worse issues with dumping everything into a repeater field. For example hitting your servers limits like max_input_vars resulting in you unable to add information.

  • Hi Dan,

    Okay.. well the problem with a front-end pagination is that you’d still hit your servers max_input_vars limit etc eventually.

    I have a clearer image of your setup now but not completely. So you’re creating a single report post and in this you add “infinite” rows of events. Why are you not just creating a report per event?

    If you need to “organize” or “group” these events (reports) somehow could you maybe use a taxonomy? So say you now have a report called “Traffic” in which you have 100 rows of events. What if you have a taxonomy called “Traffic events” and have 100 report posts each with a single event in them (doesn’t have to be a repeater any more since it’s just one instance).

    say IF that works.. then you’re thinking “My god, we can’t change our structure that much this late”. Well you can.. you just need a smart way to convert your existing data.

    You could code a function which would look through each current report post. Add a term in your new taxonomy for each report post (maybe just use the reports title as the term title). Then loop through each repeater row and create a new report post and assign it to the newly created term along with the rows fields as meta fields on this post. If you got a decent coder it shouldn’t be a problem!

    One advice tho, I’d create a new report post type for transferring to. If there’s an issue (might require some trial and error) in converting you can just clear out all posts in this post type and start over not worrying about mixing old with the new. Then when you’re satisfied you can delete the old report posts and use a plugin to convert all new posts into the old report post type (and then delete the new report post type which would now be empty anyway).

  • It is already max_input_vars = 100000

  • Hi @saadsohailk

    This is possibly due to PHP limiting the number of variables.

    Try to increase this by adding
    max_input_vars = 3000

    In you php configuration.

    Let me know if it helps.

  • Hi @vipul

    Here is a more specific solution to the problem 🙂

    PHP limits the number of values that you can have in the php configuration files.

    In order to extend/increase this limits you need to edit the following files in your php.ini file then restart the service.

    I updated the PHP configuration just in case to:

    php_value max_input_vars 
php_value max_input_time 
php_value max_execution_time

    I hope this helps.

  • Hi @maresj

    It is possible you have hit the php variable limits.

    Try adding this settings to your php config files. 

    max_execution_time = 90 ; Maximum execution
max_input_time = 60	; Maximum amount of time
memory_limit = 512M ; Maximum amount of memory
max_input_vars = 2000

suhosin.post.max_vars = 5000
suhosin.request.max_vars = 500

  • 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/

Viewing 25 results - 76 through 100 (of 179 total)
1 2 3 4 5 6 7 8