NF

This would be a great addition, +1

I still have to close the annoying sale banner every single time my admin dashboard is refreshed. Moving to a different plugin because of this.

• This reply was modified 2 years, 3 months ago by NF.

This snippet might be useful, I use it, sets the country by users IP:

add_action( 'default_checkout_country' , 'set_user_geoip_country_as_default_checkout_country', 900 );
function set_user_geoip_country_as_default_checkout_country( $default_country ) {
    $geolocation     = new WC_Geolocation();
    $user_ip_address = $geolocation->get_ip_address();
    $user_geoip_data = $geolocation->geolocate_ip( $user_ip_address );

    if ( isset($user_geoip_data['country']) && ! empty($user_geoip_data['country']) ) {
        $default_country = $user_geoip_data['country'];
    }

    return $default_country;
}

Then just hide the field using CSS and it is still pulled through onto the order details.

• This reply was modified 2 years, 5 months ago by NF.
• This reply was modified 2 years, 5 months ago by NF.

I have found the issue, and it’s not the setting I expected it to be as I already have all of the scripts, style sheets and JS excluded from combination.

It was the:

Remove Query Strings from Static Resources
Removes version query strings from your static resources improving the caching of those resources.

Hopefully this will be useful for others.

Partial refund of a cancelled order where a restocking charge is deducted from the refund total. The order normally remains “completed”, however we change it to “cancelled” to reflect the correct order status.

Plugin in question that I am trying to get working is: https://www.ads-software.com/plugins/autocomplete-address-and-location-picker-for-woocommerce/

I have been able to exclude the JS combination successfully, however cannot get it working unless JS deferral is turned off at the moment.

Ah I see, is the WP Cron wiped when it is deactivated?

I will try switching to the CR Cron

Further update, I have found the bug and know how to replicate it!

Steps to replicate:

General tab > Enable one of the shipping options> shipping tab > shipping options > select “force shipping to the customer billing address”

Return to general tab > disable shipping > place an order > the shipping details are now forced in despite shipping being disabled

This can be solved by enabling shipping > shipping tab > shipping options> select one of the defaults instead of “force shipping to the customer billing address”

So it seems the “force shipping to the customer billing address” is overriding the main disable shipping setting entirely.

Personally I think the main disable shipping should override the shipping options, as once shipping is disabled this function is hidden entirely.

I’m sure this could prevent a lot of frustration for anyone that is in the same situation as me if the logic can be improved around this.

Conflict testing results.

On the staging site I disabled all plugins, including mu-plugins, switched the theme to storefront, enabled only Woocommerce and made sure there was no caching active on the server level for the staging site.

Tested a new order and the issue persists, shipping details are still being populated.

Could it be a bug where if the store has previously had shipping enabled, and then switched to no shipping (this is the case for me), there is something stuck causing the shipping details to still be populated, as if it was still running under the old setting of shipping being enabled?

Could you test that on your clean install by first enabling shipping, make an order so it populates shipping details as it should, and then change the settings to no shipping, make an order and see if it populates shipping details or not?

Thanks for the info, will begin conflict testing on a staging site today and update you with the results.

Update, I found you can block individual IP’s from the current settings. Would still be nice to add IP ranges, user agents etc.

Hello,

Sorry for the delay I have been out of office.

Ticket number is: 4125582

Sure, whats your support email?

Ridiculous to remove them entirely. Visa and Mastercard actually require their payment logos to be clearly displayed at checkout in their merchant agreements I’ve signed with other payment processors, can’t imagine it’s any different with Stripe.

Our customers now have no idea which card brands our store can accept and our failed transactions has started to spike.

Tested with the following plugin and everything works correctly with only a single tag added: https://www.ads-software.com/plugins/ga-google-analytics/

This would suggest to me the issue is with this plugin and I will use the other until the issue can be diagnosed and resolved.