Support

Account

Register Login

Home › Forums › Bug Reports › value for acf_render_field_setting being overwritten

Solved

value for acf_render_field_setting being overwritten

  • Hi,

    I’ve found a bug which is present in the latest version of ACF PRO.

    advanced-custom-fields-pro/api/api-field.php:678

    The default_value (var_dumped) is “”, which means it is set, but not empty.
    This problem makes the default_value, which is not set, overwrite the value with “”. Which causes the select box (and all other selectable options) to not select the correct option.

    Suggested fix:
    } elseif( isset($setting[‘default_value’]) and !empty($setting[‘default_value’]) ) {
    // use the default value
    $setting[‘value’] = $setting[‘default_value’];
    }

    Cheers,
    Max

  • Can you post the code you’re using to add a field setting? Is this on an existing field type or on a custom field type?

  • Hi John,

    This was setup using the PHP implementation to create a custom field (via PHP). I’ve used code provided by you to create a plugin which enables me to create a custom type: http://www.advancedcustomfields.com/resources/tutorials/creating-a-new-field-type/

    The following code is (removed some customer-related stuff) from the file “fields/acf-fieldtype.php” (partially custom name):

    function render_field($field)
    {
    $select_options = [
    CUSTOMER::REPORT_A => ‘A Rapport’,
    CUSTOMER::REPORT_B => ‘B Rapport’
    ];

    acf_render_field_setting($field, [
    ‘key’ => $field[‘key’],
    ‘type’ => ‘select’,
    ‘name’ => $field[‘name’],
    ‘choices’ => $select_options,
    ‘value’ => $field[ ‘value’ ]
    ]);
    }

    What i did to find the issue: var_dump $settings function in the ACF PRO plugin at the beginning of acf_render_field_setting, before it extracts the settings, then below the setting extraction and then below the code for which i suggested a fix.

    Cheers,
    Max

  • You need to add the default value to the arguments for acf_render_field_setting(), and I don’t know why you’re setting the value here.

    
function render_field($field)
        {
            $select_options = [
                CUSTOMER::REPORT_A => 'A Rapport',
                CUSTOMER::REPORT_B => 'B Rapport'
            ];

            acf_render_field_setting($field, [
                'key'     => $field['key'],
                'type'    => 'select',
                'name'    => $field['name'],
                'choices' => $select_options,
                'default_value' => 'the default'
            ]);
        }

    If your select field allows only 1 selection then default_value it will be a string. If the field allows multiple selections then it will be an array of strings.

  • Hi John,

    When you don’t setup a default, the first option will be selected. That is not the problem.

    The problem is, that when i save the field (the field itself works fine), the value is correctly passed through. I’ve tested this on 5.3.5 and it works fine there.

    The value attribute should hold the SELECTED option. So, when you save a post and this custom ACF field is on there, the value is saved in the meta and is returned correctly when i fetch it using get_field(‘report_type’). BUT, the selected=”selected” is not add to the option which is selected. This is caused by the bug which is in the first post:
    the value is overwritten due to a mis-design. If you program something to check for “isset” and it IS SET, but has no value, it still is set. Therefor it will ALWAYS resort back to the default_value.

    If i understand you correctly, you are suggesting that i should use the default_value option to get the correct <option> the selected=”selected” attribute. That would be a big design flaw in my opinion.

    If you can debug the acf_render_field_setting function in the ACF PRO plugin and insert an array into the $settings (second attribute) variable, you can see what i mean.

    Max

  • PS: see /wp-content/plugins/advanced-custom-fields-pro/fields/select.php

    At line 349:
    $this->walk( $field['choices'], $field['value'] );

    Then line 388:
    $this->walk( $v, $values );

    Which ends at 401:

    // vars
			$search = html_entity_decode($k);
			$pos = array_search($search, $values);
			$atts = array( 'value' => $k );
			
			
			// validate selected
			if( $pos !== false ) {
				
				$atts['selected'] = 'selected';
				$atts['data-i'] = $pos;
				
			}

  • okay, now you’ve completely lost me.

    render_field_setting() creates fields that are available to the admin when creating a new field group and adding a new field. This has nothing to do with the value that is saved to a field and these values are only saved to the field settings, which can be found in the “content” of the “acf-field” post type.

    get_field() has noting to do with a field setting and is the value being saved when someone edits a post, or wherever the field group is located.

    My guess here is that you are attempting to do something that should not be done with render_field_setting() and should be done by some other method.

  • Maybe you can explain more about what you’re trying to accomplish?

  • 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

  • Just so that you know, this isn’t my plugin, I just answer questions here. I know a lot about ACF, but I’m not really involved in it’s development. If you want to submit a bug directly to the developer please use this link https://support.advancedcustomfields.com/new-ticket/

    I’m still a little lost from your explanation.

    First off are we talking about a select field or are we talking about a custom field type created using http://www.advancedcustomfields.com/resources/tutorials/creating-a-new-field-type/

    Assuming you are talking about a custom field type, are you able to share the code.

    I have build custom field types for ACF, including a select field, and I have not had the problem that you indicate. The getting of the current value is handled in the render_field() method of the class and not the render_field_settings() method. You can see this on line 202 of this file https://github.com/Hube2/acf-select-w-add-other/blob/master/fields/acf-select_with_other-v5.php. This file was created using the ACF 5 select field as an example.

  • Sorry John, but I feel like I’m kind of wasting my time here.
    This topic says bug reports right? So after wasting hours of debugging and trying to explain to you (the ACF bug report forum) in a very simple walkthrough how to reproduce this very annoying bug, you’re telling me that an actual report should be filed elsewhere?! Why not suggest that in the first place?

    I appreciate the time you put into helping other people, I really do. But I do think that some things should be left to those who it matters to.

    I don’t think I’m willing to submit bugs anymore. The ACF guys are making this process very hard, and i don’t think that me putting time into a product you earn money on, should be this hard.

    Good luck

  • Actually, when you start a new topic here https://support.advancedcustomfields.com/new-topic/, at the top of the page it clearly says

    Please note that forum topics are no longer used as support tickets. Instead, please open a support ticket

    The fastest way to get a bug report to the developer is by starting a support ticket. This forum is a user support forum where users help other users. Yes, at one time the developer used this forum for all communication, but that is no longer the case. The developer does not read these forums on a regular bases, if he did then he’d never get any work done on ACF.

    Some of the people that help here can bring things to the developer’s attention, but before I will do that I need to be convinced that it is a bug and not that something is being used wrong and so far you have not convinced me of this. Mostly because I’ve done what you’re trying to do without any trouble.

Viewing 12 posts - 1 through 12 (of 12 total)

The topic ‘value for acf_render_field_setting being overwritten’ is closed to new replies.