magento2: getDestCity() method returns nothing in collectRates() method.

A custom shipping carrier shouldn’t require any block or front end modification at all, assuming it intends to only return shipping rates.

If we ignore any custom shipping methods for a second and just look at core Magento 2 - consider the DHL carrier that is built in to Magento. In the Carrier.php in module-dhl: ->setDestStreet($this->string->substr(str_replace(“\n”, ‘’, $request->getDestStreet()), 0, 35)) ->setDestStreetLine2($request->getDestStreetLine2()) ->setDestCity($request->getDestCity())

• In both cart and checkout the city and street will always be null as it is not set on the request object
• This same request is passed to collectRates function of every carrier that is active in Magento.
• We expect city and street to be null when shipping rates are requested from the cart, but in the checkout these fields are available for both guest and logged in customers as the shipping rates request is triggered via Ajax after the shipping address form has been filled out for guests, or an address has been selected for logged in customers

As your built in DHL carrier is requiring these fields in the request, I would say this is a bug with core code at this point.

In addition, any custom shipping rate carriers would fully expect the full shipping address fields to be available on the shipping rate request as they have been filled out by the customer and are often crucial to accurate shipping rates. These were available in Magento 1, so at this point it’s a step backwards.

Guest checkout: the fix required appears to be in module-checkout/view/frontend/web/model/js/shipping-rate-processor/new-address.js -> add the additional address fields to the payload -> you are re-using the service URLs that are used in the cart to estimate rates which doesn’t seem correct to me. This will eventually call estimateByAddress function in ShippingMethodManagement which only expects and adds region, country and zip code to the request. I think you should have a separate serviceURL at this point that will call a function that expects the full address payload and adds to the request.

Logged in customer checkout: the fix required appears to be in module-checkout/view/frontend/web/model/js/shipping-rate-processor/customer-address.js -> again you are re-using the service URLs from the cart, which will call estimateByAddressId function in ShippingMethodManagement which only adds the region, zip code and country to the request. I think you should use a separate service URL to call a function that adds the full address to the request. You have the shipping address via the Id so all of the shipping address fields are available.

HI @Zach2212 pls check this module i fix it using this module. https://github.com/shopgo-magento2/checkout-city

HI @joni-jones pls check this module i fix it using this module. https://github.com/shopgo-magento2/checkout-city

This is still an issue with logged in customers.

Execution path is passing through estimateByAddressId function in ShippingMethodManagement which only passes in country, region and post code. There should be a separate execution path for checkout for logged in customers that passes in the full address details.

Can we get this reopened?

That’s a better info and thank you for that, very valuable We are investigating how can we improve this by rewriting some interfaces, so you can have a better easier access to full shipping data

@webtonic , @wsakaren - at the very moment we are fixing it.