Looks like a small bug. Quite an ironic one actually.

I moved all my custom product meta values in 1.0.5 from _gf_* to _wcv_custom_* to be more in line with wcvendors when I ditched gravity forms ( bloody awful thing to work with! ).

Looks like you had a similar idea in 1.1.0 and created a section in the save_meta function of the product controller to iterate through any similarly named variables and save them. Unfortunately the update_post_meta() call uses store_id instead of post_id.

I use the action just after, at the end of the function to save the meta data. The function has a bit of extra validation and deals with other things as well so would prefer to use that.

There’s an argument that custom meta data isn’t standard and should be dealt with on an ad hoc basis not with a straight no-validation update/insert.

As well as the fix to the variable name I would also request/recommend that the key capture applies a filter to let the user bypass it, so:

// To be used to allow custom meta keys 
$wcv_custom_metas = array_intersect_key( $_POST, array_flip(preg_grep('/^_wcv_custom_product/', array_keys( $_POST ) ) ) );

if ( !empty( $wcv_custom_metas ) ) { 

foreach ( $wcv_custom_metas as $key => $value ) {
	update_post_meta( $store_id, $key, 	$value ); 	
}

}

to:

// To be used to allow custom meta keys 
$wcv_custom_metas = apply_filters( 'wcv_custom_product_meta', array_intersect_key( $_POST, array_flip(preg_grep('/^_wcv_custom_product/', array_keys( $_POST ) ) ) ) );

if ( !empty( $wcv_custom_metas ) ) { 

foreach ( $wcv_custom_metas as $key => $value ) {
	update_post_meta( $post_id, $key, 	$value ); 	
}

}

Thanks.