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
I don’t think you’ll have a lot of problems with timing out with the type of data you’re using. You already have a upper limit on the number of rows that can be added. PHP has a setting for max_input_vars which is 1000, in your scenario you have 186, well below this threshold, so again, you shouldn’t have a problem here.
Custom coding an application could be more stable or not, really depends on how it’s coded and how it works.
Are you running into an issue with max_input_vars? This can be a problem on large groups of fields. Try installing this plugin and making edits. The plugin has not been updated in a while but it still works https://wordpress.org/plugins/wp-max-submit-protect/
When having problems with large numbers of fields you are usually running into an issue with the PHP max_input_vars setting. More information here https://www.advancedcustomfields.com/resources/limit-number-fields/
The developer took my advice. All versions since 5.0 no longer have this problem.
You can change your max_input_vars setting back to the default value of 1000, and ACF will work fine with large field sets.
Hope this helps others, but for every WP site I set max_input_vars to 5000. Since then I have run dozens of sites and some with massive amounts of repeaters and other fields. So far I have not run into this issue again.
You can do this with Apache or Nginx (Whatever web server you are using) or PHP.ini.
The most common reason that values to not update is the max_input_vars PHP setting https://www.advancedcustomfields.com/resources/limit-number-fields/
