This plugin, while it has not been updated in a long time, will still work to detect if max_input_vars is the issue.
https://wordpress.org/plugins/wp-max-submit-protect/
We’re hosted on WP Engine, who says this about max_input_vars:
Max Input Vars
The default max_input_vars setting is 10000, indicating no more than 10,000 variables can be attached to any request.
This setting cannot be adjusted, as this is set at a platform level and higher values will have negative performance implications.
Granted, 10,000 seems like it should be enogh. Hmm.
I don’t have any other suggestions. 99% of the time when values are not updating it is a symptom of the php setting max_input_vars not being set high enough.
max_input_nesting_level can also be an issue if you have repeaters that are deeply nested, but this is rare.
There may also be other server settings that also deal with these dependent on your hosting environment, but I don’t know the specifics of these.
There have also been reports in the past of issues with caching of different types that cache admin values, but this should also be rare.
Unfortunately, beyond this there isn’t much I can do to help you other than the basic “deactivate other plugins” and “try a different theme” to see if you can locate a conflict of some kind.
The only thing that I have seen that can cause this is PHP max_input_vars. Your value seems large enough, but I don’t know. Please try installing this plugin and then seeing if it gives an alert. I know the plugin says is has not been updated in a while but it still works. https://wordpress.org/plugins/wp-max-submit-protect/
Hi, I have increased the value of PHP max_input_vars but still, it’s not saving the fields value.
No, there is no limit to the number of field groups or fields. If you are having an issue with saving on pages with a lot of fields it may be because of php max_input_vars
There isn’t really any way to tell from what you’ve supplied. It could really be many things.
I would start with the basic WP debugging steps. Deactivation of other plugins and changing theme to see if you can figure out is something else is causing it.
My first thought when you say “migrating to ACF” is that you have other fields with the same names as the ACF fields, this could cause the problem.
Another issue could be that you are exceeding the php setting max_input_vars on your server.
All of these are just guesses.
You have 400 rows with 10 fields each, that is 4001 fields including the repeater itself. This does not include any other fields on the page.
max_input_vars is not high enough, but I doubt that is the cause of your issue. This setting being too low would mean that not all of the data would be updated as expected. Missing input might cause the error, but from experience I would say not.
More than likely you are seeing the save time out during the process of updating all of those fields. A browser will time out after about 30 seconds and this is not affected by max execution time. The server will continue to process even after the browser indicates a timeout.
400 rows is a lot and I would have looked at other ways of storing this data than a repeater field if this number was expected.
But there are cases where it cannot be avoided. I have a plugin that I use for this type of problems https://github.com/Hube2/acf-prevent-timeouts
I am not familiar with max_input_vars values, do you have a suggestion? I read on some websites they say it must be above 3000 but not much of an explanation was there about the number.
And by the way I am using a shared hosting I wonder if that’s a problem. They may restrict some functionalities to the shared hosting users.
Your issue is with php settings. Most likely max_input_vars and possibly also max_input_nesting_level. You need to increase the limits on these values.
It sounds like you are having an issue with the php setting max_input_vars or a related php setting.
How many fields are there? What is this setting on the server?
@hube2 thanks for the quick response. I don’t believe that is the problem since I just updated the phprc, which is what this Dreamhost server is using, to include the following:
; {{{ The following lines were automatically added by DreamHost
zend_extension=opcache.so
memory_limit=500M
; }}} That's all from DreamHost
max_input_vars = 5000
max_input_nesting_level = 128
max_execution_time = 300
post_max_size = 32M
max_input_time = 300
suhosin.post.max_vars = 8000
suhosin.request.max_vars = 8000
I can verify that everything except the suhosin settings are applied. I’ve tried updating both post and custom field group and nothing is changing. Anything else you can think of?
Having 60 rows in a repeater will likely be an issue unless you increase php max_input_vars.
Using a CPT will allow for and unknown future enhancement. If you use a repeater it will be more difficult to make changes.
Repeaters are difficult to search/filter and they are difficult to put in some order other than the order they are entered. Repeaters have their place, I just don’t feel that it for large data sets.
Hello,
I increased the quotas of max_input_vars, max_input_nesting_level and post_max_size but the problem persists.
is there another probable source of the problem?
Thank you,
Hello,
I increased the quotas of the max_input_vars, max_input_nesting_level and post_max_size, but the problem persists.
is there another probable source of the problem?
Thank you,
I think you are running into an issue with a php setting, possibly max_input_vars or max_input_nesting_level or maybe post_max_size. More than likely it is max_input_vars.
This reply has been marked as private.
ACF has advised that this might be due to “hitting a limit on the number of variables that can be used on a single page load on your server”.
We followed their instructions to edit the php.ini file on the server and add max_input_vars=3000 and it seems to have fixed the issue.
php max_input_vars. This php setting will limit the number of fields and you probably need to increase it.
Hmm, good point, I raised my limit to a safe value. However I really don’t know why it was showing that amount it back-end. I get the point of not saving them because of the low max_input_vars limit, but that display error is strange.
Also, it is weird but now they all display fine (even before raising the limit). Anyway, I hope it will be all right in the future. I am marking my question as resolved. Thank you.
max_input_vars is obviously too low it your have 1500+ rows. 1500+ (times) number of fields in each row (plus) all or your other fields.
However, this should not prevent ACF from showing these 1500+ rows in the admin if they exist on the site. max_input_vars only effects form submission and I can’t provide any solution as to why the rows are not appearing on the admin page.
You might want to rethink why you’re using a repeater field here and if there might be a better solution. 1500+ rows seems a little extreme.
I increased the max_input_vars value and it solved the problem.
If this kind of problem occurs shouldn’t the plugin raise an error? I wasted so much time trying to debug this issue.
There can be a limit but it is not imposed by ACF, it has to do with the PHP setting max_input_vars
