Reply To: value for acf_render_field_setting being overwritten

• mvaessen

• September 12, 2016 at 8:42 pm

Hi John,

Ok, we use PHP with the custom ACF field, provided by ACF, to create a custom field.
This custom field is for posts and other CPT’s.
The custom field has 2 options, A Report and B Report. When you save the post, the chosen option is stored in the DB. Typical normal functionality.

When the page reloads, or when you re-edit the post or CPT, you will see the same custom field (which is a select in this case). You would EXPECT it to show the option you have selected when you saved previously, right?

It doesn’t.

I checked you’re plugins code, to see how we can make a custom select field, and add it to a post. It got there, worked fine. We found, by searching your code (might wanna include this in the docs), that if you want to show which option you have selected previously, you need to set the value (stored in the db, which was why i referred to get_field, to verify it was actually stored correctly in the DB so that was not the problem) at the custom field. Right? How else would it know which option to select. If there is an option build in, it didnt work, so we went for the value solution.

We wrote this code when you guys were at 5.3.5, which worked as you would expect: Pick an option -> save the post -> edit the post again -> see the previously stored option selected. And now, it doesn’t.

So, i started debugging my code, looking for errors in either storing or whatever. Then i checked the site which was on 5.3.5, and it worked fine. So i tested it on your latest commit and it did not.

As you would expect, i went searching in your code and found that the value was replaced, with an empty string. So i debugged all the lines of code to see where it changed and WHY.

If you look at: plugins/advanced-custom-fields-pro/api/api-field.php, go to line 658. This passes the settings array into some sort of validator. Put a var_dump($setting) on line 657 and put 1 (with a exit or die behind it) at line 659. Look at the difference for the value setting. Nothing, right? In your validation method (at line 658) you can clearly see that it puts value at NULL if no value is given. Totally makes sense.

Now, register a field (like with the custom field plugin) and do not add a default value. Because, a default is for when no value is giving: fallback. Do you see that the var_dump($setting) at line 659 suddenly HAS the default_value set as an empty string? I didn’t set it, did you? It is empty, but it is set. Agree?

So, then at line 678 (where i suggested a change at my first post) you see the code that says: when default_value is set, replace value with default_value. Thats weird, right? Why would i want to replace the chosen value to be replaced by the default / fallback, which i did not set?

So like, when i have a value, but i also have a default (fallback) setup, my select will always resort back to the default (fallback). I don’t think that is a very logical behavior, do you?

The reason i suggested the simple change, is that when a dev does not supply a default_value, then don’t use it! This now looks like a fallback, with a fallback.

So, to your guess that we are using the plugin wrong: probably, but how would i know? Its not documented ANYWHERE. I need to look through code, finding misleading argument names which suggest kinda different things then what you seem to suggest they do.

Please take the time to follow the steps and reconstruct / reproduce the behavior. Its pretty simple and to me it is pretty weird. Especially that it worked fine in 5.3.5 (so looks like we used it as intended, how else would it work using in argument name like value? Looks pretty as-expected to me) and now it does not.

Max