Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.We have 3 shipping methods. UPS Fedex and USPS. UPS and Fedex are setup to use a custom packaging type and USPS is setup to use the default Custom Box (1x1x1mm). The ShippingRateWidget checks to see if there’s a package type set for the shipment. If not, it marks a flag $use_default_package_type. Then in the loop where the widget iterates over the shipping methods it sets the package type for the shipment based on the default package type of the shipping method. So the shipment entity ends up keeping the packaging type of the last shipping method. Later, the shipment is saved when you choose a rate and submit the form which saves it using the last shipping method’s packaging type. It isn't changed after that if you select a new rate/shipping method
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | commerce_shipping-reset_package_type_after_widget-2920242-2.patch | 1.36 KB | mikelutz |
Comments
Comment #2
mikelutzThis is a quick and dirty and untested patch to fix the problem short term. It resets the package type to empty after building the widget, and then sets it right before calling selectRates. It shouldn't break anything, but it's not the right permanent solution.
Comment #3
mikelutzI added a PR which has the above patch and an updated test. Even if we find a better fix, I think the updated test is valid.
https://github.com/drupalcommerce/commerce_shipping/pull/3
Comment #4
mikelutzComment #5
mikelutzhttps://github.com/drupalcommerce/commerce_shipping/pull/4
Same code, rebased and squashed to a single commit
Comment #6
bojanz commentedIt doesn't make sense to keep the $use_default_package_type logic in the form element at all, since it doesn't work properly.
Comment #8
bojanz commentedCommitted an improved fix. Thanks!