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...
array( '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...
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.....an 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,
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.
Hello, I'm also having an issue with select_advanced that seems to be different from the above. My metabox settings are:
array( 'name' => 'Guests', 'id' => $prefix . 'sessionguests', 'type' => 'post', 'post_type' => 'guests', 'field_type' => 'select_advanced', 'multiple' => true, 'placeholder' => 'Who are the guests?', ),
I can confirm that changing field_type to "select" works, but this is not a good option for me because of the large number of possible guests. I don't have The Event Calendar plugin, which I saw in another thread caused a conflict. Any other suggestions?
Addendum to the above: I had the same theme installed on a remote WordPress installation, and the select_advanced AJAX worked fine on it until I updated the core Metabox plugin, then it started giving the same error.