Home › Forums › Add-ons › Flexible Content Field › Updating flexible content field makes rows disappear in backend
Hi @elliot,
I am running into a strange issue on one of my sites.
The situation:
– I’m running the latest WP, and the latest stable ACF/add-ons
– I have a flexible content field (around 15 layout rows).
Steps to reproduce
– I edit some of the fields in one of the rows, or rearrange the rows and then save.
– About half of the fields disappear. They don’t show up in the editing page of the field.
– Existing fields that are now not visible anymore, and that had been filled in already on pages/posts, are also not visible in the backend on these pages/posts anymore. On the frontend they are visible untill I update the page.
What I’ve tried
– disabling other plugins
– disabling all of my themes custom functions
But to no avail. There are no JS errors showing up in the backend.
Could you look into this?
Hi @gerben Van dijk
it sounds like your server is simply running out of memory / vars during the save process and is not able to complete the save_post action.
There are a few topics on this forum which include max_vars solutions for your PHP settings. Can you have a quick search and let me know how you get on?
Thanks
E
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?
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?
Hi @JochenT
Currently, when you update a field group, every field is saved. If you have many fields and many sub fields, this adds up to a lot of MEMORY and time needed which some servers do not respond well to.
Can you try creating a new field group with only the field group? Does it save correctly? Can you please confirm that the problem is only with saving the field group settings, not a value on a post / page?
Thanks
E
Hi @gerben Van dijk
I would setup a local running version of the website and test the issue there. Does the issue continue locally?
I would also contact your web host to see if there are any error log info that could help diagnose the issue.
Thanks
E
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?
One of my programmers reported to me that the issue has been magically solved since the update to WP 3.8. I will look into it and report back here!
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.
Adding php_value max_input_vars 1000
to 5000 in .htaccess helped me.
Before that I had trouble saving fields and I could only add 7 of them.
I too have a lot of nested fields: flexible -> repeater -> repeater.
The topic ‘Updating flexible content field makes rows disappear in backend’ is closed to new replies.
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.