Shipping Estimate in Product Pages

Does anyone know how to have a shipping estimate on the product page (and not only in the cart or on checkout), so that the customer will be able to know the shipping cost at an early stage and not be surprised when he gets to the cart?

if you go to design->blocks, and click on products, you can add a shipping calculator block just to products.

Thanks! That helped.

[quote name=‘moka’]if you go to design->blocks, and click on products, you can add a shipping calculator block just to products.[/QUOTE]



I can’t seem to get this to work when adding the Shipping block to my products page. I get the error message: Your cart is empty and the shipping cost cannot be estimated. Any ideas? My shipping rules are based on the weight with a minimum price of $65.00 and I am using the Supplier add-on. I’m also using v2.0.15



Thanks in advance for the help.

I know this sounds like a stupid idea but when you are trying to get an estimate have you physically added a product to your cart so you currently have something in your “my cart” area?

Wouldn’t it be nice to be able to check the shipping cost in the Product page by entering a zip code, before adding the product to cart?

That sounds like a needless complication.

[quote name=‘gginorio’]That sounds like a needless complication.[/QUOTE]



Not at all, a lot of my customers would expect this if I moved to cscart.



Postage is a buying consideration so I’ve found people would like to know the postage before adding to the cart, especially if they are looking to buy one item or indeed looking to buy a gifts up to a value.



If anyone can get this to work I would be interested.

So, a user has to add the product to the cart before they can see the estimated shipping cost on the product page?



What I am looking for is a way for a user to look at the product, and see the estimated price before they add it to the cart. Since I deal with furniture, shipping prices can get pretty steep.




[quote name=‘designinside’]So, a user has to add the product to the cart before they can see the estimated shipping cost on the product page?



What I am looking for is a way for a user to look at the product, and see the estimated price before they add it to the cart. Since I deal with furniture, shipping prices can get pretty steep.[/QUOTE]



Actually, Sears has this estimate option in the product page, but you enter the zip code in a popup window. Once you get the rate, the window close and you are back in the product page. It doesn’t involve the cart:



See “Shipping charges and Arrival date” in this sample

If I were contracted to do this work, I’d make it a custom block that would do the appropriate lookup for the weight * quantity (1 by default) and then call the routines that do the shipping estimation. I.e. steal the code from core/fn.cart.php and set appropriate variables that the custom block would understand.



The block would be configured to only be on the products pages or be added to the tabsblock on the product pages… The block would use a similar format to the ‘cart’ page’s shipping estimator…



My two cents.

how much would it cost to implement tbirnseth

1 shot custom work, probably $100 - $150 ($50/hr). If there was interest from multiple people, I’d do an addon and probably sell it for $49.

[quote name=‘tbirnseth’]1 shot custom work, probably $100 - $150 ($50/hr). If there was interest from multiple people, I’d do an addon and probably sell it for $49.[/QUOTE]



Hi tbirnseth, I’m willing to cover the cost of the addon, just want to check if you still interested on doing it and If someone else want to collaborate.



Basically the addon should works in the product detail page, exactly like in the cart page, just without the option to select anything. Just for purpose of shipping cost information. Should work for 2.1.4 CE



Thanks in advance.

I actually looked into this for another cient. I’m told that the shipping estimate block will work for product detail pages in 2.1.x… However, when I looked, the shipping estimation stuff was so tied into the “cart” that it would be almost impossible to separate out without rewriting all the shipping estimation and requests for real-time shipping info.



It would be a much bigger job than I originally thought. I was surprised that it was so wired into the cart…



And the effect or promotions, etc. make it even more problematic to separate out.

If this will require a reprogramming across multiple files better to post it in the Ideas user voice. Thanks for the info.

Best regards,

This is ridiculous !



It shouldn’t be that hard and doesn’t need to tie into the cart, all that’s needed is a lookup of country, postcode, weight and price per unit. Don’t forget this is for just one object not a whole cart.



Just a form, with postcode would be good enough for me as I only really post to the uk mainland.

It may be ridiculous, but it is in fact the way it is implemented. If it is so easy to do, then suggest you do it and offer your solution back to the forum.



As I said, it is a rewrite of fn_estimate_shipping() (and the related UI) which would take some argument of weight, country and zip. But the current fn_estimate_shipping() is hard wired to cart data. The UI is also wired to cart variables.

Besides that, when displaying realtime shipping rates for “Individual Items” on the product detail page, you want to be real careful as the rates are not accurate & are often displayed much higher than the realistic shipping rate calculated within the Cart. For example, if your typical order is for single, high dollar ticket items such as 55" Plasma tv’s, then you are most likely fine displaying the shipping rate on a per item basis. However, if your typical order consists of many individual items, or perhaps multiples of individual items, then the actual shipping rates a customer will pay will be calculated far more accurately at the cart level. So in this case you would be shooting yourself in the foot to display shipping rates on the product page on an individual single item basis.

[quote name=‘tbirnseth’]It may be ridiculous, but it is in fact the way it is implemented. If it is so easy to do, then suggest you do it and offer your solution back to the forum.



As I said, it is a rewrite of fn_estimate_shipping() (and the related UI) which would take some argument of weight, country and zip. But the current fn_estimate_shipping() is hard wired to cart data. The UI is also wired to cart variables.[/QUOTE]



Hi Hi didn’t mean to offend, I often hit the keys hard sorry :smiley:



I think you are thinking like a diveloper chap. The is no need to use any function from cs-cart to produce a shipping estimate. In fact I’m suprised no one has produced a standalone shipping estimated that can be pluged into any shop in any country.



I’m not sure but a basic html block could be used - when the product is opened it does a calculation using the weight and then looks for the closest weight in a shipping table. This price is displayed as an estimate.



But thats just based on delivery to one country, the same could be done by using a shipping table with a field for each country. So the display for me for example might show something like;

--------------------------------------------------------------------------------------------------------

Estimated delivery costs For This Single Item



Uk = £2.50

Europe = £5.00

USA & Canada = £7.50

Rest Of The World = £10.00



Savings can be made by buying more then one item. Exact combined shipping quotes will be shown in the checkout area prior to payment.

---------------------------------------------------------------------------------------------------------



In fact if you want to rule cs-cart out altogether you could use a iframe or even ajax or java that shows scrollable values for the country and weight. The customer can then find the country, takes the weight from the product details and the price is show in the window.



If I get the time I’ll do it but I’m no coder so I wouldn’t offer it for others to use on the basis that I wouldn’t trust it to be secure and I would find it hard to support it.