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
Many many many thanks!! This problem was bugging me over hours …
I also had to increase max_input_vars for my mega custom type …
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)
I have the same issue today and found this post.
the max number of fields allowed is 66
as we both have the same restriction – may not be a server issue?
I tried all the things above that you did and got the same result.
I am using this to help a client easily add images and text to an html slider code so need at least 150 fields just to start with.
Any ideas?
Hi @elliot,
thanks for your help. I asked now in Stockoverflow.
If I find a solution, I will share it here.
All the best
Thanks for all the information, but unfortunately, I’m just a PHP programmer specializing in UI, so I don’t realy have much knowledge of server configuration / limitations.
Perhaps you could post a link to this on a general PHP forum such as stack overflow? I’m sure there are some guns out there that will be able to solve the issue for you.
Sorry I can’t be of much other help.
Thanks
E
Thanks @jplew that did the trick! However I wasn’t getting any PHP Warnings in my error log – in fact I’m getting no errors when I save the form which is strange.
Initially I thought my solution of deleting and re-adding entries worked but I hit the same brick wall a few days later. I had come across max_input_vars previously but it was commented out in my PHP.INI so naively assumed it was Unlimited. Here’s what I’ve added in my .htaccess to fix the issue:
php_value max_input_vars 3000
php_value max_input_time 120
php_value max_execution_time 60
I’ll have to keep an eye on it but hopefully 3000 is high enough to avoid this problem occurring in the future.
Thanks for all the help guys
Chris.
Hi:
@elliot
I was also experiencing this problem, but your suggestion to check the server logs was correct. Here is what I found in my php_error.log:
PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0
It is because I had an obscene of amount of fields on my page. Luckily I’m working locally so I can adjust max_input_vars
. Not so sure about my host though…
Hi @elliot,
Fantastic! You are right.
max_input_vars works bad for me and setting below in .htaccess resolve my problems.
php_value max_input_vars 7000
Thank you for all,
Shota
If something strange happen, like this one, always check httpd errors first.
I got a similar problem in acf field creation area.
[error] [client 127.0.0.1] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0, referer: http://local.dev/wp-admin/post.php?post=728&action=edit
Yep, error tells you what to do. Just increase max_input_vars value in your php.ini. I see my local installation dont even have this value but you can just add it to php.ini and restart server. It will work ๐
Some discussion on this: http://stackoverflow.com/questions/10303714/php-max-input-vars
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.