Morning all,
Not sure if I have found a bug or if there is something wrong with my set up, but I’m having trouble applying location rules to a field group.
I have a field group, with a single field that is a fairly complex Flexible Content layout controller. I can apply one location rule to it (to a custom post type), but when I try and apply it to another custom post type, it simply won’t save and defaults to CPT “posts”.
I’ve no idea what the problem is other than there is an awful lot of data in the post_meta associated with the specific ACF (one of the meta_value has 25K+ chars in it) – other than this the ACF functions perfectly, and performance is fine.
I’ve tried to manually add the serialised meta_value to a meta_key = “rule” in the db but to no avail.
Any suggestions gratefully received!
Thanks,
Joel
As an addition to this problem, I’ve been having a look in the db and seen for the problem ACF that it seems to be repeating the meta data for the config
I have a very similar ACF but it only value for meta_key: field_xxxxxxxxxxxx
Is this right?
Hi @joels
It is possible that the size of your flexible content field is breaking the functionality during save.
How many sub fields does it contain?
If you create a new field group with a much simpler flexible content field, does the issue persist or does it resolve itself?
Thanks
E
Hi Elliot,
Thanks for your reply and apologies for picking this up late, but I created a work-around shortly after posting (splitting the layout controller into multiple parts), although that is not really sustainable long-term as it doesn’t allow for enough control over the content.
The flexible layout contains 13 individual layouts, and a total of 43 different fields from 2 to 6 per layout. The post_meta field for the layout options has 24844 characters in the meta_value field.
It works in the dev environment but not on the production server. We’ve tried upping the memory_limit in the php.ini file, although this then works on one of the dev machines but not the other (but still not in production).
Can you think of any other bottle neck that might cause this to fail? It fails depending on the particular ACF we’re using, sometimes they don’t allow new rules (with meta_key = “rule”) to be written and sometimes they don’t allow new layouts to be added. There is no obvious “fail” as such, when the ACF is updated, it simply reloads the page as one would expect, although the new changes have not been added. If I start a new field from scratch, it behaves as expected up to the point where it gets “large”, although I have not been able to identify exactly where that point is I’m afraid.
We’re at a bit of a loss, but if you have any thoughts, we’d appreciate hearing them.
Many thanks!
Hi @joels
I believe the flexible content field is simply too large to be saved into the DB.
Please note that in ACF5 (soon to be released), sub fields are saved as individual fields, so this ‘too large’ issue won’t be a problem.
Hopefully this will solve your issue completely.
Thanks
E
Thanks Elliot,
OK, no problem I’ll try and calm down a bit with the number of fields I’ve got. Looking forward to v5 though.
Cheers!
Good to know what the problem is here. But I don’t understand why it suddenly started breaking my websites.
It’s an important realization that testing every update locally and on a staging environment is really the way to go..
Anyways, I hope v5 will come soon!
