It’s worse. I’ve added the following code to a clean copy of product-edit.php:

WCVendors_Pro_Form_Helper::input( 
	array( 
	 	'post_id' 	=> $object_id, 
	 	'id'	 	=> '_wcv_custom_product_puppy_vaccinated', 
	 	'label' 	=> __( 'Current Vaccinations', 'wcvendors-pro' ),
	 	'type' 		=> 'checkbox',
		'wrapper_start' 	=> '',
		'wrapper_end' 		=> ''
	 )
);

On page load, it is properly displaying the state of the checkbox as I have set it on the backend (either yes or no). If it starts as unchecked (no), and I check it, then the change is saved properly. However, if it begins in a checked state and I uncheck it, then it doesn’t get saved.

I have inspected the POST data using Chrome dev tools and can see the _wcv_custom_product_puppy_vaccinated value set to yes when I set it from unchecked to checked. But when I do the opposite, _wcv_custom_product_puppy_vaccinated doesn’t appear in the POST data at all.

@ben or @digitalchild , any ideas here? This is strange.

Anna, I’ve seen that code before, and it does work. However, the main difference between the code you shared and my scenario is that I’m dealing with a taxonomy. And if I write my code with an options array, as yours has, then it saves properly, but the correct value isn’t shown after save. In other words, the product edit page always shows the first item from the options array, rather than showing what’s in the db.

I might be willing to abandon using a taxonomy for this, but that would still leave the big problem of being unable to save checkboxes. We can make that the priority issue.

@digitalchild & @ben

In order to get this working, I had to do two things. First, in my frontend template, I needed to set a value, but I had to do it in an unexpected way. Including this in the documentation/knowledgebase would be a good idea).

	$puppy_sex_field_terms = get_the_terms( $object_id, 'puppy_sex' );
	$puppy_sex_field = $puppy_sex_field_terms[0]->name;
		WCVendors_Pro_Form_Helper::select( array( 
			'post_id'	=> $object_id, 
			'id' 		=> 'wcv_custom_taxonomy_puppy_sex[]', 
			'label'   	=> __( 'Puppy Sex', 'wcvendors-pro' ), 
			'placeholder'   => __( 'Puppy Sex', 'wcvendors-pro' ),
			'show_option_none'	=> __('Select a sex', 'wcvendors-pro'),
			'wrapper_start' => '',
			'wrapper_end' 	=> '', 
			'desc_tip'   	=> 'false', 
			'taxonomy'	=> 'puppy_sex',
			'taxonomy_field'	=> 'puppy_sex',
			'taxonomy_args'	=> array(	'hide_empty'	=>false,
							'hierarchical'	=> true ),
			'value' 	=> $puppy_sex_field
			)
		);

I had to retrieve the terms, which are returned in an array of objects, and cannot be passed thru the helper. Since this allows for only a single term, I took the array of objects and extracted the single term name, and then I set it as the 'value' for the helper array.

That wasn’t enough though, because as I noted earlier, the html options output include the term ID for the value attribute rather than the term name. This causes two problems: the form saves the term ID as a new term unto itself, and the method WCV uses to determine which option should have the selected attribute fails to identify any option.

Now, with the value for the helper array properly set, I had to make one change to line 227 in class-wcvendors-pro-form-helper.php. (I wouldn’t touch these files normally, except, as noted, I think this is a bug.)

From:

		$options[ $term->term_id ] = $term->name; 

To:

		$options[ $term->name ] = $term->name; 

And that solved it. The proper option has the selected attribute, and the form saves correctly, since it’s now passing the term name rather than its ID in POST.

Whether or not this was the proper or best way to fix the problem, I don’t know. I’ll leave that judgement to you.

Continuing what I said earlier about the server expecting certain fields in POST, and that being the way checkboxes are turned off when they’re absent from the POST data…

This is how it’s handled by WCV for Virtual and Downloadable checkboxes:

	$is_downloadable = isset( $_POST[ '_downloadable' ] ) ? 'yes' : 'no';
	$is_virtual      = isset( $_POST[ '_virtual' ] ) ? 'yes' : 'no';

So, I have temporarily resolved my issue with checkboxes by doing the following: I already had the checkboxes in the backend product edit form by using woocommerce functions like this:

woocommerce_wp_checkbox( array(
		'id' 		=> '_wcv_custom_product_puppy_vaccinated',
		'label' 	=> __( 'Current Vaccinations', 'woocommerce' ),
		'desc_tip' 	=> true,
		'description'	=> __( 'Check the box if the dog is up-to-date on vaccinations.', 'woocommerce' ),
	) );

And saving those was handled with:

function save_puppy_info_option_fields( $post_id ) {
	$puppy_vaccinated = isset( $_POST['_wcv_custom_product_puppy_vaccinated'] ) ? 'yes' : 'no';
	update_post_meta( $post_id, '_wcv_custom_product_puppy_vaccinated', $puppy_vaccinated );
…
}
add_action( 'woocommerce_process_product_meta_simple', 'save_puppy_info_option_fields'  );
add_action( 'woocommerce_process_product_meta_variable', 'save_puppy_info_option_fields'  );

So, all I had to do was add the following action to go along with those last two:
add_action( 'wcv_save_product', 'save_puppy_info_option_fields', 10, 1 );

Now the frontend checkboxes save too. This, of course, doesn’t change the fact that the WCV form helper is only doing half the work. But I think it’s pretty clear what would need to happen with an upgraded form helper — it would need to look for checkbox type fields being generated and then “anticipate” those fields to be in POST, and set them to no if they aren’t sent in POST. Probably not the easiest task; I can’t quickly think of a method to accomplish that.

Thanks, Jamie.

Would it be possible to add a filter to the next release that will allow me to modify the settings for a custom type box that I have added?

Long version: I added a custom type box _puppy_type. I want it checked by default on the frontend, but I want it unchecked by default in the backend. You have a filter product_type_options, but it only applies to the _virtual and _downloadable checkboxes. It would be nice to have a filter that applied to all or just to the custom ones. Thanks.