IQComputing Alex

Hello @lgs77717

A slowdown is likely to happen, but not consistently. The ShipStation API takes a good amount of time to retrieve rates whenever a zipcode is entered, but WooCommerce does a good job at caching those rates at checkout so repeat requests shouldn’t be making additional API calls.

You should be able to see this by enabling Debugging under Settings > Integration. The logs should be under WooCommerce > Status > Logs. Whenever you refresh your checkout you should see the postalcode/zipcode persist (pre-populate) to what you’ve entered previously. The logs should indicate if an API request is happening on every refresh. If so, this may indicate something is modifying the default WooCommerce caching functionality.

So in short, the ShipStation API calls are the biggest slowdown that is unfortunately out of my hands, but WooCommerce should be caching the returned rates and the shipping address information to prevent repeat API requests.

Hello @sinisterfish

First and foremost, thank you for your detailed report – it is/was very helpful! We wanted to follow up with this after some testing and investigation.

Bug 1: Currency double-conversion with multi-currency plugins
Unfortunately, I wasn’t able to replicate this issue on a default WooCommerce install using their demo products. The shipping prices did convert properly on both the cart and checkout from USD to GPB. This plugin, Live Rates, uses the WooCommerce Settings set currency as the base. If USD is the Setting Base, this is what will be in the ShipStation request.

Bug 2: “Select Cheapest Rate” breaks checkout display entirely
This is a legitimate issue in how the lowest rate is being returned. This will be patched with the next release.

Bug 3: Rates being summed instead of deduplicated
There does seem to be an issue with rates encompassing the entire cart and quantities that we are looking into. That being said, the plugin only works with the generic package type from each shipper. This can be seen in the get_shipping_estimates method.

https://github.com/IQComputing/live-rates-for-shipstation/blob/main/core/api/shipstation.php#L293

By doing this we do not need to worry about deduplication. The shipper (API) either gets the product dimensions or the custom box dimensions that the system supplies it.

—

We’ll continue to investigate this issue and reply back to this thread once a patch has been implemented. Thanks again and have a wonderful rest of your week!

Hello @lgs77717

We wanted to inform you that the returned Shipping Rates should be ordered from lowest to highest cost, with lowest at the top of the list. Let us know if you continue to run into issues with rates showing out of order and we may investigate further. Have a wonderful rest of your week!

Hello @piexxer

The core issue occurred when we moved the Shipping Calculator over to using Cart Hashes as Keys instead of Product IDs. Looking at the Upcoming Github Branch changes to see what was different between the previous version and now.

https://github.com/IQComputing/live-rates-for-shipstation/commit/6c64e59fc73bc5c830adba33b858509c6b71033b

Previously, the get_requestsby_individual() method was returning request results keyed by Product ID, as you can see on line 517 in red. We need the Cart Hash for later so that we can re-access the cart and get the quantity.

In the process_available_rate() method, which accepts the ShipStation Rate result and 1 Package result, on line 952 in red and green, is where we’re getting the actual quantity from the cart – in which we need the cart hash to do so and not the Product ID.

Finally, if you’re looking to modify the Calculator Object or API we do have a hook where you may completely switch out the Shipping Calculator Class, allowing you to supplement your own ShipStation API Handler Class as well, using the iqlrss/shipping/calculator_object filter hook. Using this hook you can provide an object to override the base calculator methods (as your class must inherit the base calculator class) and override the api() method. This should allow you to add in the customizations you need without having to worry about not keeping the plugin up-to-date or feeling like you have to modify the core plugin code.

https://github.com/IQComputing/live-rates-for-shipstation/blob/main/core/shipping-method-shipstation.php#L735

I did re-work it to be much more efficient in it’s calls to avoid any unnecessary, as there are also other hidden areas to consider on this for performance, which your plugin does not if it was to be simply changed to full qty support logic, however it also calls in areas where it’s not ideal in it’s current logic, so there is room for improvements.

The plugin is Open Source and on Github. If you would like to make contributions based on your investigations, I’m sure everyone using this plugin would be grateful. Otherwise, if you would like to extrapolate further, our team could look at implementing these improvements.

https://github.com/IQComputing/live-rates-for-shipstation/

In any case we’re glad you were able to find a solution. Have a wonderful rest of your week!

Hello,

Thanks for the feature request. While we do not have a timeline for the implementation, we will add this to our list of features.

In the meantime, you may be able to hire a local developer to implement a small development snippet to reorder the shipping package rates:

https://www.businessbloomer.com/woocommerce-sort-shipping-costs-low-high/

/**
 * @snippet       Sort Shipping Rates by Price - WooCommerce
 * @how-to        businessbloomer.com/woocommerce-customization
 * @author        Rodolfo Melogli, Business Bloomer
 * @compatible    WooCommerce 7
 * @community     https://businessbloomer.com/club/
 */
add_filter( 'woocommerce_package_rates', 'businessbloomer_sort_shipping_methods', 100, 2 );  
function businessbloomer_sort_shipping_methods( $rates, $package ) {
      
	if ( ! is_array( $rates ) ) return $rates;

	uasort( $rates, function ( $a, $b ) { 
		if ( $a == $b ) return 0;
		return ( $a->cost < $b->cost ) ? -1 : 1; 
	} );

	return $rates;

	// NOTE: BEFORE TESTING EMPTY YOUR CART
       
}

This plugins shipping rates run through the same filter hooks that WooCommerce has to modify the output. The above is still a reliable solution, but again we recommend reaching out to a local developer to implement it.

Hello @theodotcom

Thanks for the clarification. Unfortunately, no immediate solution, but some of these Shipping Services do come with “flags”, things like hazardous material or fragile. We may be able to use these to flag certain products to align with certain Shipping Services that modify which rates get returned for an overall cart.

We’ll look into this a bit further with that in mind and we’ll keep you posted on what we find out.

Hello @centuryperf !

Is this only happening on the Admin Panel when viewing the order, or are you noticing it on the frontend as well?

For the Canada / International shipping options issue, this is another one we haven’t been able to replicate. Are you able to get shipping options from ShipStation directly (using the calculator on their website, through the ShipStation account)? Could it be an issue with the set Shipping Zones?

Hello @richecolocity

I was able to replicate the issue on my end, but was also able to get returned rates at the same time. It’s not clear what the issue is but it looks like either an issue within the plugin itself or the ShipStation API. We will investigate this further on our end and publish a patch once we narrow down the cause.

In the meantime, if you have any further insight on this issue, please let us know.