Reply To: Different storage type

• John Huebner

• April 20, 2020 at 4:25 am

I am not the developer, just a long time user that has gotten to know the workings of ACF. If you really want to get the developer to weight in then you’ll need to submit a request here https://www.advancedcustomfields.com/contact/

1) The reason that there is a field key for each field is so that ACF knows how to treat that field value. The issue is that any field name can be repeated. Let’s say that you have a field named “some_field”, this is a simple text field and the data of this field is save for a “Post”. Now let’s say that you create another field with an identical name and you save this field value to “Pages” but is field is a relationship field. The only way that ACF knows how to treat these two fields differently and return the correct value is that each of the fields has a different field key reference.

Many people are under the mistaken impression that ACF “knows” or “remembers” what fields are used for what post type, taxonomy, user, options page, etc. It does not. When ACF gets or saves a value two pieces of information are required, the post ID (or some other object ID) and the field key. When you are saving a value ACF has this information when the form is submitted. When retrieving a value when you use the field name ACF must look up the correct field key.

This is the reason that a field key reference is needed. The only way that this would not be the case would be if ACF required a unique field name for every field created.

2) Fields are stored separately, values in those fields are not always stored as separate values. A selection in a gallery field is not a sub field of the gallery.

So it might be possible to store the values of a gallery field in multiple entries. This would require deleting all values before updating. Then ACF would need to loop over the values and insert each. This action of deleting and then adding multiple entries could cause a performance issue in the admin. Imagine that you have 20 fields like this and each of these fields has 20 entries. This would do a total of more than 400 queries to insert the values. This is because of the way that WP meta values work.

Another issue with doing this at this point would be backwards compatibility. Changing the way ACF stores the values now would be difficult.

There are ways to overcome the issues with doing “LIKE” queries on meta values. You can see how I overcome this by reading the post I created here…. well, it seems that site is now gone….

Anyway, the idea behind what I wrote is to convert fields that you want to query by to standard ACF field. For example, lets say that I have a checkbox field and the checkbox field has values that I want to query by.

add_filter('acf/update_value/name=my_checkbox_field", "convert_my_ck_to_wp", 20, 3);
function convert_my_ck_to_wp($values, $post_id, $field) {
  $search_field_name = 'my_checkbox_field_wp';
  delete_post_meta($post_id, $search_field_name);
  if (is_array($values)) {
    foreach ($values as $value) {
      add_post_meta($post_id, $search_field_name, $value, false);
    }
  }
  return $values;
}

Now a query can be done using the alternate field name. This does create extra data in the database, but this is not nearly as detrimental to queries as doing a “LIKE” query on the ACF value. And since we only do this on fields where we need the values stored this way there is less likelihood of the performance issues we might have if every ACF field was stored in this manner.