We have a "Select" type custom field called "Self Assessment 1 Quiz" that does not have any default option specified. We dynamically populate the available options for this field in a CRED form using the following function that queries a separate table to find the available options:
add_filter( 'wpt_field_options', 'selectfieldoptions', 10, 3);
function selectfieldoptions( $options, $title, $type ){
switch( $title ){
case 'Self Assessment 1 Quiz':
global $wpdb;
$options = array();
$myrows = $wpdb->get_results( "SELECT id, name FROM DB_selectOptions where (cat_id = '1') or (name='-') ORDER BY name" );
This solution works well and the correct values do get stored in the custom "Self Assessment 1 Quiz". However, when we try to display/output that field in a content template using [types field='self-assessment-1-quiz' output='raw'][/types], the output is blank. Interestingly, using [wpv-conditional if="( $(wpcf-self-assessment-1-quiz) ne '' )"] does work and does detect that the value stored in the field is not empty indicating that there is a value stored but it cannot be displayed.
However, If we change the field definition and explicitly add options, then the field does display when using [types field='self-assessment-1-quiz' output='raw'][/types].
This behaviors started happening when we updated to the latest version of Types(3.0.1) and Views(2.6). Prior to these versions, we were able to display the value of "Select" fields even if the options are not defined.
Please see attached screenshots of the field definition without options and with options.
Yes, [wpv-post-field name='wpcf-self-assessment-1-quiz'] does work.
Does that mean we have to replace every occurrence [types field='self-assessment-1-quiz' output='raw'][/types] with [wpv-post-field name='wpcf-self-assessment-1-quiz'] in our solution as well as in any other solution we have developed where we use "Select" type custom field that have no options defined .?
As I said in my post, this happens only with Custom fields that have the Type "Select" and the Option not set.
Any other type of custom field works just fine with [types field='filename'][/types]
Please try it on your WordPress installation. Create a Custom filed of type "Select" and do not set the option. Then populate the custom field with a value using a CRED form. Now when you try to display the value of that field using [types field='filename'][/types] you will see that it is blank. Only [wpv-post-field name='filename'] works.
In the past with prior version of Types and Views, it used to work both way.
As I explained it in my post, we populate "Select" custom field using a CRED form and supplying the pulldown option with values that are stored in a separate table and brought over using a custom function/filter.
add_filter( 'wpt_field_options', 'selectfieldoptions', 10, 3);
function selectfieldoptions( $options, $title, $type ){
switch( $title ){
case 'Self Assessment 1 Quiz':
global $wpdb;
$options = array();
$myrows = $wpdb->get_results( "SELECT id, name FROM DB_selectOptions where (cat_id = '1') or (name='-') ORDER BY name" );
We will use [wpv-post-field] for new solutions, but how about existing solutions. We have several sites where we use [types field='filename'][/types] across the board since this shortcode used to work. Now all these sites where Select custom fields are used are in effect broken.
Where you able to recreate that problem on your end ?
Please escalate this issue in order to create a fix.
I'm actually aware of this issue. I believe Types shortcode needs some reference in order to retrieve the field information. Each field type is handled different by our shortcode even though we use the same shortcode.
The wpv-post-field shortcode can get the raw data from the database. So this is why I believe that the Types shortcode is processing this differently .
I'm not privy to the intricate workings of this but I suspect this is the issue based on looking at why the [wpv-post-field] works. If you were to add some values to the select I know it would work.
I don't think this is something that our development team would fix either because of the use of an undocumented hook.
The fact that "Select" custom fields with no options used to work in the past with the shortcode [types field='filename'][/types] and many solutions were built based on them and now they stopped working, is problematic. There is no mention anywhere that the shortcode [types field='filename'][/types] is deprecated and should not be used with "Select" custom fields.
Why then would you allow "Select" custom fields with no options to be defined. The system should detect that condition and warn you.
We now have to revise all our solutions to adjust to that change. The is unfortunate.
