the php setting form max_input_vars can cause odd things like this to happen. Try installing this plugin and see if you get an error when submitting https://wordpress.org/plugins/wp-max-submit-protect/
If that’s not it then you need to start deactivating plugins to see if there’s some incompatibility that causing it.
There isn’t any way to hide the repeater field so that it does not load. There is a plugin that will collapse them https://wordpress.org/plugins/advanced-custom-field-repeater-collapser/
There is not limit to the number of rows you can have in a repeater except for settings in PHP and the physical limits of your server. There is a php setting named max_input_vars, if you go over the value of this setting then the excess rows will be ignored. There is a plugin available that will tell you when you’re exceeding the setting. https://wordpress.org/plugins/wp-max-submit-protect/
Hi John,
Thanks for the advice. I totally agree with that. Since we’ve identified that it was required to increase the max_input_vars, we are right know redeveloping the field groups structure for a better approach, creating a couple of more custom post types instead and reducing the amount of fields per group.
Cheers,
Milton
Hi John,
Thanks for that, I didn’t even consider the max_input_vars as part of the problem, but in fact it was. Increasing the limit solved the issue and ACF is now able to “update” the current field group JSON file rather than creating a new one.
I didn’t realise my field group is that big now. Probably the only thing that makes me think it was something related to the ACF plugin was that I always got a “field group updated” successful message instead of a warning or error and the fact that it creates another JSON file.
Anyways, thanks for the tip mate.
Cheers,
Milton.
Yes, that does clear thinks up a bit. I will take a look at this.
I have one suggestion though without looking too closely though. Usually when fields and field data disappear when saving a field group and other odd things like this it’s because you running up against the limit of the php setting max_input_vars.
Without duplicating a field your field group has 15,245 fields. I’d say that you’ve already increased max_input_vars before or you couldn’t have saved what you posted. You might want to increase it again. I find this plugin very helpful when developing large complicated fields groups. https://wordpress.org/plugins/wp-max-submit-protect/
Let me know if that does not solve your problem.
Has this topic been abandoned? I too am having this issue. I built a page template for a client to showcase breweries at an upcoming event. There are 14 subfields inside 124 repeater fields and that seems to be the limit the browser will handle. I have upped their max_input_vars to 6000 but still no dice. I don’t want to have to go back to them and say “Sorry that’s all it can handle.” If I had known this would happen I would have made the breweries into their post type and looped through them like that. Will this issue ever be resolved? Is there a way to show like 20 repeater fields and then paginate the rest in the admin area? Or do something similar to what was done here (http://sevenspark.com/wordpress/speeding-up-the-appearance-menus-screen-in-wordpress-3-6) for WP menus prior to 4.3?
Hi @gwenzez
Thanks for the question.
There is no limit to the number of custom fields that can be added to a field group or in your case the repeater. Your server might be terminating the save process before ACF completes its job, you will need to increase the max_vars PHP setting. You can make 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 WSOD might also be as a result of a plugin conflict, please deactivate all other installed plugins and switch to one of the stock WP themes to check if the issue will still pop up.
To update the plugin you will need to log in as an admin.
When this happens it is usually a problem with the PHP setting max_input_vars. You need to increase the value of this setting. To see where it is and to prevent loosing data try this plugin https://wordpress.org/plugins/wp-max-submit-protect/
It seems odd because the field group does not look that large. Are there other field groups on the pages. Usually when a field does not save it has something to do with the php setting max_input_vars.
Can you install this plugin then attempt to save and let me know if you get the popup warning?
https://wordpress.org/plugins/wp-max-submit-protect/
Thanks for the responses. I’m actually on a dedicated server, so increasing the memory really does increase the memory. And yes, I’m sure that my max_input_vars and memory limit are correct by verifying in the php info.
I added these:
max_input_vars = 3000
suhosin.get.max_vars = 3000
suhosin.post.max_vars = 3000
suhosin.request.max_vars = 3000
Per the FAQ, although I bumped those all up to like 16000 with still no results. And memory is at 800MB currently.
I was in the process of adding new fields when this started happening. I had to add 7 and I made it to 5 before it stopped working for the final 2. So I’m sure that no other plugins were updated or installed and I’m certain nothing else on the site was being changed either during the additions. It just decided to stop at 60 and making these changes hasn’t worked. I’ve also checked the database manually to be sure that it wasn’t some display issue, but the new entries I created (that ACF said were created successfully) are not in the database either. Thanks again.
Okay, and you’re sure you’re actually getting 800mb? If you are on a shared hosting it’s possible your own changes to for example wp-config or htaccess isn’t being used.
Could you try creating a file info.php in your server root and place:
<?php phpinfo(); ?> in it. Then go to yourdomain.com/info.php .. There you should be able to find what your memory_limit and max_input_vars are really set to.
As for the php errors it’s only the last one about headers that I think might be doing some actual damage. Seems something (either your theme or a plugin) is trying to output things before they should.
This is primarily caused by the php setting max_input_vars. You will need to increase it.
This plugin will tell you when you form exceeds the number allowed by your server: https://wordpress.org/plugins/wp-max-submit-protect/
That is a pretty large field group, and I can’t see what all of the field types are due to the errors, are some of them repeaters or flexible content with nested fields?
Running into trouble with the php setting max_input_vars can cause strange results.
Try installing this plugin: https://wordpress.org/plugins/wp-max-submit-protect/
It will tell you if there are more fields being submitted than is allowed. This is actually what I initially suspected.
Glad you found the problem. Yes, exceeding max_input_vars can cause some strange behavior. I find this a must install plugin during development of new sites https://wordpress.org/plugins/wp-max-submit-protect/
Thank you, John. It turned out that we needed to increase max_input_vars in our php.ini. It started to do some very weird things once we went over the limit. It took a while to figure out but it’s all fixed now.
Thanks. 🙂
Hi @bruno-martins
I am not sure what you mean by “It does not work” is the Repeater field not saving values? If this is the case, it may be related to the field_name length.
ACF uses the field’s name to save a value into the database. When saving sub fields, the ‘save name’ is generated by the ancestors names + the row index and can become quite long. It is possible that the length of this ‘save name’ can become too long for the wp_options table, and WP will not be able to save the value at all.
You can solve this by reducing the field name length.
If the issue is to do with the field not saving, you can make the following changes to the php.ini file:
max_input_vars = 3000
suhosin.get.max_vars = 3000
suhosin.post.max_vars = 3000
suhosin.request.max_vars = 3000
This is a problem with php.ini and the max_input_vars setting.
Check out this plugin, it can tell you when you are exceeding this number and what that number is: https://wordpress.org/plugins/wp-max-submit-protect/faq/
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
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/
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.
acf-zora-cre....txt
content-2015....xml
