Forum Replies Created

Viewing 20 posts - 1 through 20 (of 20 total)
  • Author
    Posts
  • in reply to: Filter WCV row actions error #72432
    Scott Lengacher
    Participant

    That’s the example code from the KB. I’m using it, modified of course, to try to add another element to the array. The array contains the actions that can be taken on an order, such as Mark Shipped.

    in reply to: Filter WCV row actions error #70551
    Scott Lengacher
    Participant

    @fervous , I’d really like to use this filter. Am I doing something wrong? Thanks.

    in reply to: Allow Applying User to upload photos #70550
    Scott Lengacher
    Participant

    Yeah, I was hoping that in addition to this, there might be some additional restrictions possible. Limiting the customer to two uploads or something like that.

    Thanks.

    in reply to: Filter WCV row actions error #70147
    Scott Lengacher
    Participant

    @ben or @digital-child, do you have any insight here? Thank you.

    in reply to: Custom Taxonomy Saving Improperly #68400
    Scott Lengacher
    Participant

    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.

    in reply to: price markup #68395
    Scott Lengacher
    Participant

    Thank you, Jamie. I’m glad there was already a filter in place. I’m sorry I failed to notice it. This works:

    add_filter( 'wcv_product_price', 'add_product_fee' );
    add_filter( 'wcv_product_sale_price', 'add_product_fee' );
    function add_product_fee( $field ){ 
    	$value = get_post_meta( $field['post_id'], $field['id'], true );
    	$field[ 'value' ] = empty( $value ) ? '' : $value - 450 ;
    	return $field; 
    }

    Of course, I am aware that I need to save the values in the db with the markup applied, and I finished that up yesterday using this:

    add_action( 'after_setup_theme', 'markup_puppy_price' );
    function markup_puppy_price( $post ) {
    	if ( isset( $_POST[ '_regular_price' ] ) ) {
    		$_POST[ '_regular_price' ] += 450;
    	}
    	if ( isset( $_POST[ '_sale_price' ] ) && $_POST[ '_sale_price' ] !== '' ) {
    		$_POST[ '_sale_price' ] += 450;
    	}
    }

    Just to explain, we want all prices to be inclusive (no additional fees or shipping, and the buyers don’t see our fee), and we will be arranging shipping, which is why the 450 is so important. So, the 450 will be coming to us, but we don’t want our sellers to be responsible for adding our fee when they’re entering their prices. This way, the seller only needs to think about their sale price and not worry about any math or remembering to to factor in our shipping markup, etc. The seller always sees “their price” and the db always has the total price.

    Again, thanks for your help.

    in reply to: price markup #68363
    Scott Lengacher
    Participant

    I’m working on something like this right now. And the first issue is the need to filter the output of the _regular_price that vendors see on the product-edit form. In order to do that, there needs to be a filter for $field in the class-wcvendors-pro-form-helper.php file. I added one myself at line 110:

    } else { 
     	$field = apply_filters( 'wcv_product_input_field_modifier', $field );
    
    		if ( $field['show_label'] )

    Then, in my functions file, if I want to change the price that vendors see while editing:

    function change_price_before_display ( $field ) {
    	if ( $field['id'] == '_regular_price'  ) {
    		$field['value'] -= /*My markup value*/;
    	}
    	return $field; 
    }
    add_filter( 'wcv_product_input_field_modifier', 'change_price_before_display' );

    Now, I’m moving on to other pieces of this project. But I am wondering if, @digitalchild , you could add an input field filter like mine to the next release? Thanks.

    in reply to: Custom Taxonomy Saving Improperly #68214
    Scott Lengacher
    Participant

    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.

    in reply to: Custom Taxonomy Saving Improperly #68212
    Scott Lengacher
    Participant
    in reply to: Custom Taxonomy Saving Improperly #68127
    Scott Lengacher
    Participant

    And I’m 99% sure that this is what’s going wrong with checkboxes, but I’d still appreciate some help…

    It is normal behavior for empty checkboxes to not be included in POST. So there are two common ways to handle that. Either create an accompanying hidden field with the same name that will POST and be used if the checkbox is empty, or overriden if the checkbox is checked. Otherwise, the server can expect certain fields, and interprets the absence of a POST value as the unchecked state and handles it accordingly. Best I can tell, that is how the Virtual and Downloadable checkboxes are handled.

    in reply to: Custom Taxonomy Saving Improperly #68094
    Scott Lengacher
    Participant

    @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.

    in reply to: Custom Taxonomy Saving Improperly #68083
    Scott Lengacher
    Participant

    @digitalchild

    Concerning taxonomies, here’s what I think is going wrong:

    The form helper generates an option with a value set to the key (ID) for the particular term:

    		foreach ( $field['options'] as $key => $value ) {
    			echo '<option value="' . esc_attr( $key ) . '" ' . selected( esc_attr( $field['value'] ), esc_attr( $key ), false ) . '>' . esc_html( $value ) . '</option>';
    		}

    That looks like this, in my case:

    <select id=... ><option value>Select a sex</option>
    <option value="1301" >1280</option><option value="1300" >1281</option>
    <option value="1281" >Female</option><option value="1280" >Male</option></select>

    Naturally, the value is what gets sent with POST. Then, when saving the POST data, WCV saves that value (which is the ID, not the term name), like this:

    $wcv_custom_tax = array_intersect_key( $_POST, array_flip( preg_grep('/^wcv_custom_taxonomy_/', array_keys( $_POST ) ) ) );
    	if ( !empty( $wcv_custom_tax ) ) { 
    
    		foreach ( $wcv_custom_tax as $taxonomy => $data) {
    					
    			$taxonomy = str_replace( 'wcv_custom_taxonomy_', '', $taxonomy ); 
    			$tax_data = array_map( 'intval', $data ); 
    			$tax_data = array_unique( $data ); 
    
    			wp_set_post_terms( $post_id, $tax_data, $taxonomy ); 
    		}
    	}

    So, the ID gets saved as a term, causing the problem. So, I think this is a bug. ( @fervous, can you bring this to Ben and Jamie’s attention? Thank you.) I see two ways of fixing it: either the form helper sets the option value to the term name, or the product controller handles the save differently. The first seems easier, and…

    Due to the way the form helper handles taxonomies and generating the options, selected='selected' never gets set.

    in reply to: Custom Taxonomy Saving Improperly #68079
    Scott Lengacher
    Participant

    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.

    in reply to: Custom Taxonomy Saving Improperly #68031
    Scott Lengacher
    Participant

    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.

    in reply to: Custom Taxonomy Saving Improperly #67974
    Scott Lengacher
    Participant

    Pretty sure I copied the wrong code earlier. This is the code that saves the term ID rather that the term name, thereby creating a new term with a name equal to the other term’s ID (as describer above):

    WCVendors_Pro_Form_Helper::select2( apply_filters( 'wcv_custom_taxonomy_puppy_sex', 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',
    				'is_taxonomy'	=> true,
    				'taxonomy_args'	=> array( 'hide_empty'=>false ),
    				'value' 	=> $puppy_sex_field				
    				) )
    			);

    BTW, if I eliminate the taxonomy arguments and instead use an array of options, then it saves properly.

    'options' 	=> array(
    			'male'		=> __( 'Male', 'wcvendors-pro' ),
    			'female' 	=> __( 'Female', 'wcvendors-pro' )
    			),

    However, if I do this, there’s no way to have the currently set value selected by default when editing an existing product. Besides, the addition of another term (in other use cases) would mean needing to manually edit the options array.

    in reply to: 2 custom taxonomies not working #67954
    Scott Lengacher
    Participant

    Arjan, it is likely that those numbers are actually the term IDs for those taxonomy values. I suggest you check. That is the issue I’m now facing.

    in reply to: Tax by vendor location workaround? #53423
    Scott Lengacher
    Participant

    @Rustan, Did you figure something out? Does Avatar tax tables working out for you?

    in reply to: Vendors being logged out upon upload #49498
    Scott Lengacher
    Participant

    Correction, the SSL plugin did the trick. Wow, ok, it is time for me to go to bed. Sorry for the confusion there.

    in reply to: Vendors being logged out upon upload #49495
    Scott Lengacher
    Participant

    Never mind, your code did the trick. Thank you so so much!

    in reply to: Vendors being logged out upon upload #49494
    Scott Lengacher
    Participant

    Which Theme are you using? I am using the social marketplace and having the same problem. I just added SSL and the the Really simple SSL didn’t do the trick.

Viewing 20 posts - 1 through 20 (of 20 total)