When you create an options page, each option is added as a separate entry to the wp_options table. If you create a repeater 2 records are created for every option (plus 2 additional for the repeater name and key).
This works ok for post_meta, where metadata related to a post is usually fetched by a single database call but this is a really terrible solutions for options!
Ordinarily plugins save option values as serialized arrays. CMB2 will also save options pages as serlialized arrays.
https://github.com/WebDevStudios/CMB2-Snippet-Library/blob/master/options-and-settings-pages/theme-options-cmb.php
The options are then retrieved from the database one-by-one resulting in many additional database calls. If you save 50 options to the database there would be 100 additional calls to the wp_options table.
I tried recently to create a project with multiple options pages built with ACF. It’s simply not possible to do so as is. An object cache will help this of course, but this only masks the problem.
Digging briefly into how the data is saved: acf_update_value() saves each record separately (as 2 rows in the database). This would, I guess, need a total rewrite in order to achieve the desired effect. There would also be backwards compatibility issues of course.
Surely all repeater fields should be saved as serialized arrays. Is there a good reason they’re not? Am I missing something?
Thoughts anyone?
Been thinking about a good reason why not save some things in serialized arrays.
I think it has something to do with the way the fields themselves are save. Each field is a post, and fields can have child fields in the same way that pages can have child pages.
The one thing that I like about ACF is that the same functions are used for getting values from any field. Also, the same code is used in ACF itself to get any type of field no matter if it is a top level field or a field that is a sub field of a repeater of a sub field of a repeater that is a sub field of a flexible content field. Looking at it from the view of parents and children makes the code more usable in all conditions rather than having alternate code that needs to be run for different field types.
There is also the fact that it makes it easy to use standard WP functions for getting the data. ACF function, for the most part, are just wrapper functions for get_post_meta() and get_option(), so it makes sense to store data with them in mind and not need to do a lot of manipulation of that data after it is retrieved.
I’m not sure I hit on a reason that makes sense to everyone, and I’m sure there are a lot more possible reason.
