Custom Fields
Support General select_advanced with Ajax

This topic contains 4 replies, has 2 voices, and was last updated by  wgstjf 3 weeks, 6 days ago.

  • Creator
  • #16551

    Hi Anh,

    We’re also trying to do much the same thing as referenced in:

    We need to use select_advanced as we are sourcing data from a custom table rather than a custom post type. We have the ajax side of things working perfectly, the issue is that the field is not being saved to the database.

    If we edit the post.php file to print out all the posted data we can see that our custom field data is being posted it’s just not being saved to the database. I’d really appreciate your help on this as we have spent the last 4 hours trying to debug this but to not avail…

            'name' => __('Special Offer Product'),
            'id' => 'offer_product_codes',
            'type' => 'select_advanced',
            'options' => indigo_get_selected_post(),
            'js_options' => array (
                    'ajax' => array(
                            'url' => '/wp-admin/admin-ajax.php?action=ajax_get_products',
                            'dataType' => 'json',
                            'type' => 'get',
                            'delay' => '250',
                    'minimumInputLength' => 3,
                    'allowClear' => true,
                    'placeholder' => 'Choose product'
            'columns'   => '4',

    This is what get’s (correctly)posted when you ‘update’ the post:

    [offer_product_codes] => THEREG

    It just doesn’t end up on the _postmeta table and I can’t figure out why…



Viewing 4 replies - 1 through 4 (of 4 total)
  • Author
  • #16554


    On further inspection it seems to be something to do with the following filter action which is called in the process_value function in inc/field.php of the MB plugin.

    $value = self::filter( ‘sanitize’, $value, $field, $old_value, $object_id );

    Prior to this filter the submitted $value (in this case ‘THEREG’) is correctly defined. After this filter the $value is empty.

    What sanitizing is happening here and how can we bypass it or meet its conditions?





    Ok, so… update.

    Just tracked down the following field option:

    'sanitize_callback'   => 'none',

    With this enabled on our custom select_advanced field the value saves as expected! 🙂

    My one remaining question is, why is our value being ‘sanitized’ and thus not stored? Is it because the returned value is not defined as an ‘option’ when creating the field? If so, how would you recommend getting around this since we cannot define the options as they are pulled in via ajax?

    Thanks in advance,



    Anh Tran

    Hi Will,

    Your solution on sanitize callback is true. In Meta Box 5.1, we introduced the sanitization mechanism to make the data safe before saving into the DB.

    For choice fields, the value stored is considered safe only if it’s available in the field’s options. In this case, the options is dynamically populated via Ajax, the sanitization will break.

    One solution is bypass it at all, as you did. Another solution is write your own callback. Both should work well.



    Thanks for the explanation Anh and the suggestion of the custom callbacks.

Viewing 4 replies - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.