I think I’ve posted a variation of this already some time ago, but this time it is really all about the order of things.
Imagine a perfect world with perfect software, how would order totals look like (if you have all sorts of funny combinations)?
My idea would be:
Cart Total: Total of all cart items
1-n taxable amounts: things, like shipping, etc.
1-n tax: total of all tax for the cart; may be more than one line due to different tax on different things
Cart Subtotal: above cart total plus all taxable amounts
1-n non-taxable amounts: like shipping, gift wrapping, cc surcharge
Total: The real, real total
Anything else? Different??
Sporadically when doing testing ZenMagick I get database errors when trying to buy giftcards. The error in question is:
“Incorrect decimal value: ‘f’ for column ‘value’”
Looking at the data it appears that the value of the shipping ot_total module is ‘f’ when order->create() is called.
Just wondering if this is just me or something that ‘just happens’? And if it isn’t just me, is there fix?? (Admittedly, I’ve been too lazy to debug this so far…)
EDIT: Turns out I did already know the answer to this! In the other post I mention that at some stage the shipping details are set as:
$_SESSION['shipping'] = 'free_free';
It seems that under certain conditions this is not updated with something useful like an array containing id, title and cost. In that case the ‘f’ is actually the first ‘f’ of the string ‘free_free‘!
I think I’ll add a fix for this into ZMEventFixes, but it should really be fixed in the zen cart source…
Looks like we are having some trouble with databases on zenmagick.org (forum and wiki).
I’ve contaced the ISP, so hopefully things will be back to normal soon.
EDIT: lol – haven’t heard back from hostingdirect, but the sites seem to be up again – yay!
Just a little note about my last VirtualBox upgrade to 3.1.4. After the upgrade and upgading the Guest Additions, the guest (Windows XP) became painfully slow.
The reason was very very bad disc performance. Eventually I removed all shared folders and that helped. I can’t remember if a reboot was necessary or not, but now things are almost back to normal (network is still slow and external stuff that is not GET in a browser will just timeout!).
If anyone has more about how to fix this I’d really appreciate to hear that…
Just a quick heads up that I will be renaming all store related settings soon(-ish).
By now, all core and mvc settings should have a prefix of zenmagick.core and zenmagick.mvc, respectively. Along with that all prefixed settings have been documented in the settings plugin.
By adding a app.store prefix I’ll be doing the same for store related settings. This should hopefully help uncovering some unknown features and generally seems to be a good idea to do.
In the long run I hope that this will mean that the settings code may be merged into the core store code as the main means of managing global settings, instead of using the main local.php.
In my last instalment of the exciting free shipping series I’ll try to come to a conclusion as to what to do next
The first thing that really strikes me is that there is really confusion about the term free shipping. One of the reasons is surely that there are two different shipping modules dealing with free shipping, plus a virtual one (free_free) that plays together with the (general) shipping order total module!
Looking at the available options of the two shipping modules it appears that the freeshipper module does the same (in a much more concise way) as what the magic free_free code (plus ot_shipping) does. Except, that the free_free stuff allows to set a minimum cart total to qualify for free shipping!
But, hang on, there is still freeoptions, the second free shipping module! It has heaps of options to restrict free shipping, based on total, weight and item count in the cart.
So, freeoptions really is the most powerful module and can do all the things the other ones can, incl. setting a shipping fee!! and a handling fee!! Seems to contradict the name, but perhaps that’s just me…
Ok, looks like we have a conclusion: Drop the custom code, drop the free shipping option in ot_shipping and we are done!
Sounds good but leaves two bits uncovered:
- Virtual carts
This could be handled by adding a check for a virtual cart to the shipping module to decide whether it is available and change the checkout process to set freeoptions as shipping module for virtual carts.
- Multiple free shipping rules across all available options
Now this is a more general issue with some checkout options. In this case duplicating the module (plus renaming) would be a solution, but perhaps not so nice.
Alternatively, free shipping (except perhaps virtual carts) should probably be handled by promotional code rather than shipping. That would take care of having multiple conditions (for a lot of things, actually).
So, for now I think the refactoring of the checkout code will:
- Drop the custom ‘free_free‘ code in favour of using freeshipper for virtual carts.
- Leave both shipping modules as they are
- Eventually merge both into a single shipping option or write a new promotions plugin
We’ve been having a live chat server (XMPP) running for a while now and I think it is about time to let people know about it. The URL is: conferene.zenmagick.org.
If you are using jabber or gtalk and have a question, feel free to join and get help in real time! I am usually logged in during New Zealand daytime hours (UTC+12+daylight saving).
Alternatively there is an anonymous web interface available via speeqe.com.
I think I finally figured how the mysterious ‘free_free’ shipping module is working in zencart!
Let me start by saying that this is about the technical details, not about configuring it (although, that is part of it). (more…)
After hiding for a week or so, development has picked up speed again. While this is great it leaves the questions as to where to stop to get a release done.
Right now there are so many more things I could (and would like to) do that it is hard to slow down again.
What happened last week is that I finally got the new shipping provider service working. Not only that, it also looks as if the current code displays (the final order is correct, though) wrong numbers for a couple shipping modules :/
One immediate result is that now the new Ajax based shipping estimator is working as expected. Most likely it will stay in the demo theme for the next release while I try to figure out some good general JSON structures to make error handling nicer for Ajax calls.
There is now also a working (but not complete and thus disabled ) implementation of ZMCheckoutShippingController. Once I have figured out a good way to deal with virtual carts that can go live too. (And after that selecting shipping via Ajax will follow…).
There are also a couple new events:
Allow to log customer searches (will make the search log mod work again).
Allow custom code to take additional action before a user is redirected to the login page. This might be needed to clear the database basket tables in some cases (as that is currently done by zencart during checkout if the user is not valid)
I also added a couple lines of code to the loader to allow the pageStats plugin to display the number of objects instantiated by the loader. Another interesting number….
Finally, I fixed an interesting bug that caused the loader to scan the whole filesystem if a non existent folder was added to the class path!
All in all not a bad week and more to come!
Working on the new shipping method controller I’ve come across a few more inconsistencies, both in zencart and ZenMagick, IMHO.
- zencart shipping modules set errors on a per provider basis, same as ZenMagick. I think this should be on method level, though. Right now, if one a module has one working and one non working method, both would be ignored (I think).
- In addition to my last post (and comments), zencart is setting the shipping method to ‘free_free’. It appears that this is a ‘virtual’ provider/method to allow selling virtual goods without shipping cost.
While this is ok, I think it would be better to have a dedicated shipping method to handle that, rather than some magic code.
If there is more, I’ll probably update this post (or the last) in order to keep things together. I think I’ve got now most things covered, though.
After looking some more at the freeshipper and freeoptions shipping modules, some things have become clearer and some are getting muddier and muddier…
From what understand looking at the code the two do the following:
Is the module that will handle free shipping if all products in the cart have the ‘always free shipping‘ flag set. This is done via the catalog management pages.
It’s a bit sneaky that you still can set a shipping fee (and a handling fee!). However it means that it is possible to configure a flat fee for carts that only contain products flagged that way, so it isn’t only about free shipping, but about being able to group products.
This one will only kick in if freeshipper is not active and allows for a number of different conditions to decide whether the cart qualifies for free shipping or not.
I am still not sure I understand why there have to be two different modules for that, but there is also code to handle whether one or the other or none are enabled, based on the cart.
It is also noteworthy that all build in shipping modules check for these two modules as part of their enabled/disabled check. This is how zencart decides whether there is only free shipping or not and if there should be the chance to chose free shipping or be forced to take it.