OSC 2.3.4 - Shipping cost sorting fails on checkout_shipping

[wild.lucifero]

Hello to all,

         I'm writing you because I have 2 problems and I would give them a solution. I'm sure there is something to configure in admin... but I don't find nothing.

 

On standard OSC 2.3.4 (without any mods), I installed the table and the flat shipping modules and of course I have configured them to verify that:

1) In the checkout_shipping  the shipping costs are not displayed by shipping value order

2) If the shipping value is out of range (the value is 0), it is displayed anyway.

I surfed on php code to understand and search the problems; I found sorting() function etc, but there are some code that I'm unable to understand (I'm not a php programmer) and I don't know if I'm in mistake configuring admin. On OSC 2.2 I never had these problems, so I'm not sure if there are something to configure in admin.

I tried to put to 0 the value of "Sort Order" fields in the shipping modules; I tried to put to blank value... No differences.

Is there any other thing to set? Are there someone who found my same problems, please? How did you solved?

Thanks

Ciao!

[BrockleyJohn]

Off the top of my head, there's not much difference in the standard handling of shipping in 2.2 and 2.3.4

 

The modules are ordered according to sort order, and the cheapest one is selected by default. If your 2.2 did something different, I believe it was modified.

 

If your table rate module is behaving differently, you probably have a different table of values set. Or you weren't using the standard table rate module. If the latter, you can probably use your old module with 2.3.4 but you may need to fix php deprecation messages (usually by changing split to preg_split).

 

If you want to modify 2.3.4 to order the shipping quotes according to price, it means changing the order of the array returned by the quote method of the class shipping. The structure of this array is a bit complicated so it's not straightforward. This could be done by hacking the shipping class directly, or the amount of change to core code minimised by extending the class.

 

Edit: ho dimenticato di dire "Ciao Michele"!

[burt]

If your shipping modules output "dynamic" prices (which most of them do!, other than flat rate which does not), there is no way to sort from cheapest > expensive or expensive > cheapest without hacking at core code.  

 

If you want to go down that route, it's possible to do for sure.  You need to access the array of returned quotes, loop through them, and sort based on the value.  As usual, it's been done, this was 4 years ago; I dont have the code, I dont recall for whom it was made.  At least you know it's possible.

[wild.lucifero]

Off the top of my head, there's not much difference in the standard handling of shipping in 2.2 and 2.3.4

 

The modules are ordered according to sort order, and the cheapest one is selected by default. If your 2.2 did something different, I believe it was modified.

 

If your table rate module is behaving differently, you probably have a different table of values set. Or you weren't using the standard table rate module. If the latter, you can probably use your old module with 2.3.4 but you may need to fix php deprecation messages (usually by changing split to preg_split).

 

If you want to modify 2.3.4 to order the shipping quotes according to price, it means changing the order of the array returned by the quote method of the class shipping. The structure of this array is a bit complicated so it's not straightforward. This could be done by hacking the shipping class directly, or the amount of change to core code minimised by extending the class.

 

Edit: ho dimenticato di dire "Ciao Michele"!

Ciao BrockleyJohn,

        first of all: really many thanks to give your time for free to understand our silly problems.

I wrote that the problems on osc 2.3.4 are: the shipping costs are not ordered by shipping value; if the shipping cost value is 0, because the weigh is out of range, it is displayed anyway on the list of shipping costs.

I'm sure: the osc 2.3.4 I just tried to test is "standard". It means that there are no changes applyed: just downloaded and installed. Idem about the database. It is just installed (fresh) without any changes.

I did: I downloaded the osc2-3.4 from oscommerce.com and installed it by catalog/install/index.php; after that I installed the module "table rate" and configure the values; I kept only 2 shipping modules: "table rate" and "Flat Rate". I changed the shipping table value to "2.00:8.50,5.00:5.50,6.00:8" and after I change the weight of the Samsung Galaxy product to 100.00. I added a new customer to buy the Samsung Galaxy to verify the shipping cost and osc listes 2 shipping methods: "Flat Rate" value to $5.00 for first and "Table Rate" to $0.00 for second. That's all. I just did this test to check If I made some errors: no add-on installed, no changes on the configurations (the language is english as standard, the currencies to USD too, ecc: i repeat, no changes). I'm sorry for my english: sorry again. At this time I'm thinking that I should configure something I don't know on admin.

Ciao ;)

[wild.lucifero]

If your shipping modules output "dynamic" prices (which most of them do!, other than flat rate which does not), there is no way to sort from cheapest > expensive or expensive > cheapest without hacking at core code.  

 

If you want to go down that route, it's possible to do for sure.  You need to access the array of returned quotes, loop through them, and sort based on the value.  As usual, it's been done, this was 4 years ago; I dont have the code, I dont recall for whom it was made.  At least you know it's possible.

Hello Burt,

        OK, I understand. Thanks for your reply. I'll check the array of shipping table and I'll try to insert the order. But... I think there is a mistake on standard osc 2.3.4; if the shipping cost value is 0; this could means that it is "out of range". For example: I cannot ship by an envelope something that has a weight of 100kg. Infact, I edited the the shipping rate to "2.00:8.50,5.00:5.50,6.00:8" and the shipping module retuns rightly the cost to 0 because the weight (100) is > 8.00 and it means the shipping is not possible on this way, I think. So this cost shouldn't put in the shipping cost table on checkout. Is it right also for you?

...and I'm sorry for my english too :sweating:

Ciao!

[tgely]

@@wild.lucifero

your zero value is a module dependency question. Use this code in shipping module class construction when it should be:

$this->enabled = false;

[BrockleyJohn]

That isn't how the standard table rate module works (on 2.2 or 2.3.4). It never disables itself in that way - Gergely is telling you to make a custom table rate module to do what you want. The standard module is designed: out of range means free shipping, not no shipping!

 

If you want to prevent people choosing that module (without changing any code) you can just add a high value to the end of your table:

2.00:8.50,5.00:5.50,6.00:8,1000:10000

 

If you are going to modify the quote method of the shipping module to change this behaviour, there are two approaches. One is to make the module disable itself so that it does not appear in the list of shipping choices for the customer. My preference is a second: for the quote method to return an error so that the customer knows why they can't choose that module...

 

It is quite possible that there is already a shipping module in the addons section that does what you want.

[wild.lucifero]

That isn't how the standard table rate module works (on 2.2 or 2.3.4). It never disables itself in that way - Gergely is telling you to make a custom table rate module to do what you want. The standard module is designed: out of range means free shipping, not no shipping!

 

If you want to prevent people choosing that module (without changing any code) you can just add a high value to the end of your table:

2.00:8.50,5.00:5.50,6.00:8,1000:10000

 

If you are going to modify the quote method of the shipping module to change this behaviour, there are two approaches. One is to make the module disable itself so that it does not appear in the list of shipping choices for the customer. My preference is a second: for the quote method to return an error so that the customer knows why they can't choose that module...

 

It is quite possible that there is already a shipping module in the addons section that does what you want.

Yes, you are right. I edited the osc2.2 php code and discovered that I installed an add-on :- , while I thought it was one of the standard (flat) renamed by me :wacko: ... It is my mistake. Im' really sorry for that. sorry sorry sorry :'(

This add-on, is "osc_2.2.OnlineMerchant-shipping_pack_ITA" and it needs simply the replacement of the split() funciont with explode(). It works with osc 2.3.4 too.

When the weight is out of range, simply displays that it is not available disabling the radio botton too.

Thanks again

Ciao!