Support

Account

Register Login

Forum Replies Created

  • 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

  • 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

  • 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;
				
			}

  • 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

  • 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

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