I was trying to use ACF to create a Theme Options page, like themes sold out there that has many fields, counting 138 fields until now. With no success and there is much work to do yet 🙁
The Edit Field Group gets a little slow to load, and the fields start bugging, changing their settings when updating the group. I’m thinking in building this directly on JSON or by script.
Someone has already tested ACF with a large amount of fields?
The slow field group editor usually occurs when your browser or machine can’t handle a lot of elements on the page. ACF uses a lot of scripts to handle the options so it will look good on your end. If you use a machine with low specifications, could you please test it on another machine that has higher specs?
Regarding the changing settings, it’s possible that the data posted to the server have reached the max_vars setup on your server. Could you please take a look at this page to learn more about it: https://www.advancedcustomfields.com/resources/limit-number-fields/?
I hope this helps 🙂
No, this doesn’t work, in my tests some Select fields inside a Repeater changed their settings when updating the group. As a Theme Options page can be very large in options to customize a theme, I will change to another solution more specific for this situation and use ACF to small forms only. Thank you James!
ACF is a great tool, and I wouldn’t use anything else, but it does have its limits. I created a site with a field group that would actually time out the server. Since then I’ve found that limiting how many fields you add, especially when it comes to some types of fields is a good idea. In your case I would break the group down to multiple options pages and group the fields logically.
The problem is not really in ACF. The problem is in WP. WP does not have any way built into it that allows updating multiple meta fields or options values in a single query. Each value to be updated creates several db calls and at a certain point the number of db queries drags down the page speed.
As far as fields not saving properly, James is most likely right that this is caused by going beyond the max_input_vars php setting on your server.
Hi, everybody, i was experienced some slow issues too. But, i discover something or that´s what i think.
– I´ve started creating a new theme, custom functions, new field groups, flexible content, etc. I didn´t have so many content, not so many fields too, in fact i get the slow issue just with a page using two flexible layouts. At some point everytime i´ve save a post/page, takes too much to save, something like 10-20 secs. But only if i change something, custom fields, content, title. If nothing changes and click save, it takes just a second.
– I disabled all plugins. Nothing changed, even an empty page with just some “ops” text to save into content, takes about 20 seconds to finish the save action and refresh the page.
– I disabled my custom theme and actived twentyfiftyn. Same thing… slow on save (but just if somethig changes on the content, title, etc) So, no ACF running, no other plugin running, twentyfiftyn installed only, and still slow ?¡?¡
– This happened localy and on server, has no difference.
At that point i realised that has nothing to do with my local settings, my custom theme, flexible or repeated fields, php version or anything else because i ended up re-instaling wp with a new empty ddbb, then i instaled and active ACF, and then my custom theme, filled some data width some flexible content and so on, and guess what? Now saves normaly, quick.
So, what you think? It seems that something in the ddbb was causing the slow thing? May be yes, something created by ACF, fields not longer used, or data on the post meta table that was missed or something like that?
Using ACFPRO 5.4.1 and WP 4.5.3.
Hi James, you know? it´s happening again, i have only 4 pages, using just in one of them, 2 flexible layouts with really not too many fields… 11 seconds to save.
I thinks it´s something with js that takes a lot of time checking one by one if some has change… is that correct?
If that, there must be a way to avoid it and only save directly the ones changed. The changed status could be something applied to the field once is changed, like adding a class “changed”, then, the save process will only take those “changed” fields to save, and no need to check one by one. Or i´m missing something important behind the script that can´t do that way things?
Could you please share the JSON or XML export file of your field group so I can test it out on my installation?
I have a lot of field on a post and the update just takes several seconds.
Also, have you tried to check the query using the plugin I mentioned? Could you please check the network tab of your developer tools too to see any scripts that slow down the request?
You must be logged in to reply to this topic.
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!
© 2023 Advanced Custom Fields.