Well I have had a couple of request to shipping working for v4 sooner rather than later, and the fact that over the past couple of versions the shipping/shipcalc modules has really lagged.
At this stage I am not too sure what I am going to do with this module. It is quite a mess and I really don't like how you expand it and add more shipping calculation gateways to it.
Include files are fine for simple places but once you get more complex gateways/requirements it really gets hard. Also there seems to be quite a bit of duplication, between the partner includes.
I know that it is late but I thinking that the shipping module needs to be rewritten and changed to work similarly to the receipts so that the partner modules register themselves with the system and then can interact.
And when they register they will tell the system what information they require :-
- width
- depth
- height
- weight
and maybe a few others. If they need something funny they can add to the product themselves since they will be modules. Also things like UPS we can combine the multiple partner files together, and even get it to do things like if it is a Canadian order to use the Canadian UPS.
I would also like to see boxing, so if you have 3 small items they can be put into 1 larger box. to cut down on shipping costs.
This would also follow the new checkout requirements and it will choose the cheapest option by default and allow the customer to choose different methods from the checkout review page.
If anyone wants to comment. It would be nice.
Comments
More work
If it means that the v4 alpha is put back further, would it be too much to say it should wait till 4.1? I'm really hanging out for the new ordering process and being able to replace my dodgy reusable coupon hack, so I'd love to be up and running in at least a beta of v4.
I'm really looking forward to this release, and the shipping function isn't one I use... Sorry all those shipping module fans.
Cheers,
Nick
If it's got to change: change it now
I've seen lots of changes in EC in the last months (years). I think the EC community could benefit from a more stable development. So, if there are changes to be made, make it sooner than later so all contributors can focus on implementing and expanding instead of converting and rewriting.
Stabilize what's already in place first
I have to agree with nickorr. I think it would be better to have the core of the v4 up and running smoothly before implementing a major paradigm shift in one of the less central modules. I personally have two sites that I am putting up with the new version, and I am going through the testing with each release to look for issues. Version 4 has a much more intelligent design than version 3, and I can't really see investing my time to create a website with the old version right now when v 4 is so close. My vote is always for stability first, and with the massive amount of structural changes that have already been implemented in v4, reaching stability may take a good bit of time as it is.
Drupal theming, Module development and logo design:
http://www.PixelClever.com
My problem is that to get
My problem is that to get shipping working with v4 in the new methodology I would need to make a lot of changes that I am just now sure about.
Basically I have to break it to get it going again. I am thinking that if I just write it from scratch it will just be a lot more stable and it should enable us to move forward easier.
--
Gordon Heydon