Save entire field values array in db for increasing performance

• matteo-websolution

• July 3, 2018 at 8:17 pm

Hello there,

Matteo from Websolution here. I’m struggling with performances of ACF Pro since i started to use it, maybe 2014… The problem still seems to be the business logic of the plugin, good but (too much) linked to the concept of post metadata. It allows to create complex queries using the usual WP_Query, but if you start to have two hundreds of fields per page the system go on the moon with RAM and total queries.

I already tried lots of solutions, one of those was to develop a caching layer for the option pages created, so when the first time i call the get_fields function, i create a transient with an array of all the values, and the second time i only have a single query done.

But i think we could do it better…

Today i started a new site, and this time i wanted to do some timing consumption tests…
I created an option page with 30 fields, and the results are quite embarassing, considering the option page usually contains common parts of frontend (header, footer specs):

• without a single query done but the post data set, the frontend present 26 queries done
• with the only function call get_fields('options');, the frontend consume 110 queries (?!?!?!?!?!?!?), too many for starting a project in 2018

So, i have in mind something which can change the plugin performance for ever, but a good discussion needs to be done before. Without breaking any kind of already done site, i would:

• leave the whole saving process intact as is
• save a new field (acf_encoded_IDOFTHEPAGE i.e.) with every acf form data json encoded or serialized into a single array for each page or options page where acf is present
• modify this values array when a group of fields is modified, as the format value for each field could be changed
• create a new helper which allows you to return the previous field, with already formatted values

So, speaking with an example, if i have an option page with the fields:

1. Header (Group) with:
   • Logo
   • Payoff
   • Menu selector
2. Footer (Group) with:
   • Logo
   • Social links (Repeater)

i would expect to have from the helper a result like:

{  
   "header":{  
      "logo":"https://www.google.com",
      "payoff":"I'm an example payoff",
      "menu_selector":"menu-primary"
   },
   "footer":{  
      "logo":"https://www.google.com",
      "social_links":[  
         "https://www.facebook.com",
         "https://www.twitter.com"
      ]
   }
}

What you think?
Matteo

EDIT: found this on the Internet, it could be helpful because the concept is quite similar to mine https://www.timjensen.us/acf-get-field-alternative/

• matteo-websolution

• July 4, 2018 at 1:53 am

I created for you a simple class which should do exactly what i said.
In fact, with 1 query per page now i have all my data ready for a better frontend performance.
You can find the Gist here: https://gist.github.com/teolaz/dc595d5beed29ddad18066d01c237464

• John Huebner

• July 4, 2018 at 2:34 am

This is just one observation.

If the values stored for an options pages should always be loaded then the options page auto load setting should be set to true. Doing this will reduce the number of queries done since WP loads all of these values in a single query, stores them in a cache for the page and then should not query the DB again for these values.

• matteo-websolution

• July 4, 2018 at 7:38 pm

Well, i don’t totally agree with this… if you have multiple option pages and want a single page template to be driven by a particular option page, those options should be loaded by hand only, don’t you think?

• matteo-websolution

• July 4, 2018 at 10:20 pm

The only problem i’m seeing in my code is in case of a field group update, as the “cached” fields are already formatted and if you change return format specs you should update all pages showing those exact fields. I cannot think to hook on save_post for doing this check, as if you have a milion of pages you should first search every page that respects location rules, and then update the fields… maybe it’s better to create a tool which can update all database leaving the user when to use it…