Shipping by Dimensions of the Largest PRoduct

I'm selling stickers of different sizes. They're not heavy, and the height of the package isn't going to be different for one sticker or fifty stickers (for example), cause it's essentially a piece of sticky paper (it's vinyl, but the dimensions are similar enough). However, the length of the largest sticker is the determining attribute for package size, and thus the shipping info.

I'm not sure how to do it. I've tried using the weight module as a way to bypass this, but it's additive, and I would need the "weight" for the package to be equal to the "heaviest" product. (Even then, it would be very confusing to the customers - whah, how does a sticker weight ... 20 size units?? Umm?).

I'm sure I'm not the first one to have such a problem, but I'm not exactly sure how to word it because so far Google searches have been useless. I don't know how else to go about doing this, so any help would be appreciated.

Well, I think that you are going to have to build a new shipping module to do what you want. It isn't really that hard but depending on your php abilities then you might want to get someone else to do it. You could see how much people were charging by putting it as a job on oDesk.

Hmm. Thanks for your reply.

Is there any reference material you would recommend for writing your own module? I'm fairly decent with .php, so I might take a shot at it.

I don't think so no.

So. start with an existing module. I'd choose the per item one as it is quite simple.

You are going to need two files as a minimum.

includes/modules/shipping/my_new_shipping.php
includes/languages/english/modules/shipping/my_new_shipping.php

The language file is pretty obvious. The actual module you should be able to work out from what is in the original one.

As an aside:

You can add the 'length' information to the product. So to do that you would create a new table in the database ( which is better than just adding the info in a new column in the products table ). Then you need to edit collect_info.php, preview_info.php, update_product.php, copy_to_confirm.php and confirm_to_delete.php.

OR

You can just abuse the 'weight' slot in the database. You can hide the weight information from the front end and just use weight to equal length.

niccol:

You can add the 'length' information to the product. So to do that you would create a new table in the database ( which is better than just adding the info in a new column in the products table )

Mind if I ask why you say creating a new table is better than adding a new column to the products DB?

When I needed to add dimensional fields for the ozpost module I used the Canada Post module as an example (the idea being to not having to re-invent the wheel), as such, both of these modules (and possibly others) add the dimensions to the products table. It seems far easier to do that than it would be to create a new table, which will require more additional code to access the new table, whereas adding them as additional fields only requires minor edits to existing code (specifically, finding references to the 'weight' field, and replicating the lines of code for the newly added dimensions).

If it were almost anyone else but you that made this statement I'd probably just ignore it, but because I know you're no dummy, there is probably some, even a lot of truth behind what you are saying. I'd be a fool to not want to know your reasoning. :)

Cheers
Rod

Well, I have done it both ways I have to admit. Adding to the end of the product table is certainly easier.

But the logic is really about upgrades and future alterations. Personally I think it is just good practice. A part of that is to keep the upgrade path as clear and straight-forward as possible. If you keep modules as separate from the core as possible then users will experience fewer issues on upgrade. For instance, if someone tries to revert to a back-up version of the products table, which may or may not have the added column, then they will experience issues. I am sure you can think of other examples just as well as me, remembering, of course, that you do not know for sure that the developers may in the future choose to make alterations of their own to the products table ( probably not but who knows? )

In the day to day running it doesn't make any difference at all as both will work just fine.

For me it is mainly a conceptual choice to keep the module as separate from the core as possible. In Zen, as I know you know, that is kind of hard to do with regard to files. The developers I know are working on a proper plug-in architecture for a future version which hopefully will make that easier. With the database there just seems no good reason to mix the module bits in with the core bits. Why not keep them separate? It may not solve many issues for users but even if it solves a couple then that is great. Also the clarity it provides about 'what does what' is just good practice, I reckon.

It is not a really major point, for sure, but I don't think I am alone in this belief. I can think of a couple of multi-module authors who have expressed the same views.

Strangely, I just yesterday, had a look at Delia's module that adds extra fields to the product. http://www.zen-cart.com/downloads.php?do=file&id=926 . I was really happy to see that she had taken the separate table approach. So much so that I used the mod rather than coding what I wanted :-) Saved the client an hour of my time. So that is something that the OP might look at too.

niccol:

But the logic is really about upgrades and future alterations.

I've never found this to be an issue, at least not as far as the database is concerned.

niccol:

For instance, if someone tries to revert to a back-up version of the products table, which may or may not have the added column, then they will experience issues.

But on the same token, this situation will still exist even if a new table were created.

niccol:

I am sure you can think of other examples just as well as me, remembering, of course, that you do not know for sure that the developers may in the future choose to make alterations of their own to the products table ( probably not but who knows? )

I can only think of one case where it could cause a problem (something I was very concerned about in the early days of development), and that is in the case where php/sql code uses the 'select *' syntax and expects a specific number of fields in a specific order. Thankfully none of the ZenCart code uses thins method.

niccol:

For me it is mainly a conceptual choice to keep the module as separate from the core as possible. In Zen, as I know you know, that is kind of hard to do with regard to files.

Now this is a cause of many problems especially in regards to upgrades and backup restores, but the problems will be the same no matter which method is used.

niccol:

The developers I know are working on a proper plug-in architecture for a future version which hopefully will make that easier.

I seem to recall ZenCart V2 is planned to provide dimensional support, and I think I've seen or read something somewhere that they'll also be using a separate table to hold this data, which is another reason why I opted to pick your brains. :)

niccol:

With the database there just seems no good reason to mix the module bits in with the core bits. Why not keep them separate?

The 'good reason' I had (besides not having to re-invent the wheel) was for the sheer simplicity of the modification needed to the core code to make use of the additional DB fields.

niccol:

It may not solve many issues for users but even if it solves a couple then that is great. Also the clarity it provides about 'what does what' is just good practice, I reckon.

Seriously, the only problem that I'm aware of is the situation whereby the database has been restored from an older version (without the extra fields), but the core php files hadn't been restored.. in which case it aborts with an undefined field error. If a new table was created instead, this same condition will produce an unknown table error.
In the 'opposite' case where the .php files are restored from a backup (or overwritten due to an upgrade), the only problem is the module that uses dimensional data will fail to work, everything else will work as normal (no errors, even though the additional fields still exist).

niccol:

It is not a really major point, for sure, but I don't think I am alone in this belief. I can think of a couple of multi-module authors who have expressed the same views.

I have to admit, that this was my preferred option too, and if it hadn't been for the existing Canada Post module (and the fact that the weight data is also stored in the products table) I probably would have even gone that way... Clearly I took the 'easy' solution rather than my 'preferred' solution, but I've not regretted that decision (In other words, It hasn't been the cause of any support queries or any other problem).

The thing is, I don't know/remember why the addition of the new table was my preferred option, and since the 'easy' option hasn't caused any problems that I know of (that wouldn't have occurred with a new table method), I was hoping for a bit of a fresher course :)

niccol:

Strangely, I just yesterday, had a look at Delia's module that adds extra fields to the product. http://www.zen-cart.com/downloads.php?do=file&id=926 . I was really happy to see that she had taken the separate table approach. So much so that I used the mod rather than coding what I wanted :-) Saved the client an hour of my time. So that is something that the OP might look at too.

For sure. However, I loved the way you were thinking 'outside the box' with your suggestion "You can just abuse the 'weight' slot in the database. You can hide the weight information from the front end and just use weight to equal length".

If the product weight isn't going to be used anywhere, and the OP is only interested in the product length then this 'unusual' method would be the one I would go for, simply for the sheer simplicity of it.

Cheers
Rod

Thanks for all the feedback!

I don't really need the 'additive' functionality or actual weight for items, so I'm thinking that the most efficient way to solve my problem would be to find the code responsible for calculating shipping and hacking that into the needed shape. Any suggestions on where to look? (.php files, code sections, anything?)

Thanks again!

includes/modules/shipping/perweightunit.php

there are some language files that go with that too.

includes/languages/english/modules/shipping/perweightunit.php

If you want the easiest route (I guess you had no luck on oDesk?) Then hide 'weight' from the customer using the techniques outlined in many forum posts. then use weight to represent length. Then make some alterations to the language files. At that point you will have a system that will calculate shipping based on a length basis. You will probably want to alter the calculation so it is 'stepped' rather than 'linear' which you will do in the module ( in the function quote to be more accurate).

At risk of being contradicted, it might be best if you 'cloned' the module rather than just abusing the existing module. But it does involve a bit more work and it is up to you.

Will check it out, thanks!

If I 'clone' the module (ie, copy-paste and rename the file) how do I make zen-cart use it? (v1.5.1) I would clone it, but not sure how to make the clone work...

If you put it in the right place then it will find it.

You would need to make alterations to the file itself and the language file so that the defined constants are not the same as the perweight module.

I've been messing around with the code, and it seems to me like the most efficient way to do what I want (weight is not added, but only the highest weight is maintained) is to alter the way the cart keeps track of the $shipping_weight variable. Any idea where I can do that? I've poking at different parts of the 'order.php' class, but it doesn't seem to be where it's at...

Ok, seems to work the way I want it. Documenting it for anyone who has a similar problem.

You can visit anysigns.ca to see it in action. What this is, is a really, REALLY 'hacky' fix to get my zenCart to work the way I want it, having hijacked the weight attribute to mean dimension category (length, width, height). The weight of the heaviest item in the shopping cart / order will override the overall order weight. So if one item is weight 3, and the other is weight 4, the total order will be calculated as weight 4.

Here is how I done it, for ZenCart v 1.5.0 (earlier I said I was using 1.5.1 - I was wrong):

In the file includes/classes/shopping_cart.php, find and replace the following bit of code in the calculate() function:

// + or blank adds
if ($attribute_weight->fields['products_attributes_weight_prefix'] == '-') {
 $this->weight -= $qty * $new_attributes_weight;
} else {
 $this->weight += $qty * $new_attributes_weight;
}

with this:

if ($new_attributes_weight > $this->weight){
 $this->weight = $new_attributes_weight;
}

What this does is that whenever someone adds an item to the shopping cart, the cart will compare the weights of the items (NOT the quantities) and will override the current weight total of the order with the new one if the new weight is bigger than the old one.

Thanks to everyone who helped, especially nicol :)