/contributions/
A number of osCommerce shipping modules, mostly for Malaysia, but very easy to adapt to other countries.
A Zoneedit.com update script for linux
Malaysia state shipping module. Latest (2008 May 25) is v0.01
Download malaysiastate.zip (6986 bytes)
Pos Malaysia Air Parcel shipping module. Latest (2008 August 23) is v0.09
Download posmyair.zip (9003 bytes)
CitylinkExpress shipping module. Latest (2008 May 7) is v0.06
Download citylinkinternational.zip (30472 bytes)
We are no longer maintaining this module.
v0.05 traps the error caused by the changing object name at Citylink's server and retrieves the new object name so that the next quote will work. v0.05 wrongly reports the error as a missing currency, fixed in v0.06.
How these shipping modules work
The tables used by couriers to calculate shipping costs for overseas destinations can be large and complicated. It would be possible to write a shipping module that used a local (to your server) copy of the shipping tables, but keeping such an implementation up to date would be laborious and error-prone. What would be really nice would be for the shipping companies to produce their own osCommerce shipping modules, and maintain a mailing list of users to notify of updates. But then, if pigs flew, they would probably carry your parcels for free.
We wrote these shipping modules to get around the maintenance problem. They don't hold shipping tables, they ask for a shipping quote from the couriers' websites. When your customer goes to the checkout, osCommerce requests shipping quotes from the installed shipping modules. When one of these modules gets that request, it sends the weight and destination of the order to the courier's website.
There is a noticeable delay when using these shipping modules, caused by the request going from your server to the Pos or Citylink server and the subsequent reply coming back. Last time we looked, the Pos server was in KL, the Citylink server was in Texas, USA. The The delay your customer experiences while the quotes are loading is made up of the round-trip time for the requests, the server response (quotation) time, the time taken to transfer the returned data and some processing of the results in the module.
There is very little processing done by the Citylink module, as only a few bytes of data are exchanged between the shipping module and the quotation function on the server. The Pos shipping module must load the whole human-readable result page from Pos' server. The Pos result page has been slimmed-down since the modules were written, but it's still over 11kB. The next time you're talking to your shipping reps, please congratulate Citylink on the efficiency of their quotation system, and ask Pos (nicely!) to offer a result page for automated queries, it could save them 99% of their bandwidth!
Problems
Citylink's quotation server uses a scripting technology called Ajax to interact with their quotation page. Citylink have configured their system so that the quotation function name has a random string appended to it, like: App_Web_zcb7abfm.ashx. This name changes from time to time. When the name changes, the quotation result from your server will fail. Since v0.05, the Citylink shipping module will detect the failure and request an updated name for use the next time a quote is requested. Your customer will see a single "unable to obtain quote from Citylink" message when this happens. Perhaps while you're congratulating your Citylink rep on the efficiency of their quotation system, you could point out that the random name suffix could be losing you both business.
When either website is unavailable, either through being down or unreachable from your server, no quote will be obtained, and your customer will see a "unable to obtain quote..." message. We haven't often experienced this at Lolyco. In the last 6 months, our logs suggest that has happened in <0.5% of checkouts for Citylink, and <1% for Pos Malaysia.
A typical setup
Install the shipping modules. The Pos and Citylink servers return quotes in Malaysia Ringgit, so make sure MYR is installed and your exchange rates are up to date. There's very little to configure, and most of it is self-explanatory. Remember to use a non-zero sort order for your shipping modules. Using 0 as a sort order can cause the module to disappear from the checkout!
If you've installed everything correctly and you go to your site's checkout with a delivery address that is not your home country, you should see something like this (shipping address of UK):
The Citylink module uses a feature from PHP v5, which won't work on webhosts that use the older v4. You can check which version of PHP your webhost uses (if it doesn't tell you). Just use 'Server Info' from the Admin Tools.
These modules will only quote for overseas deliveries. You'll need to install some other module for local deliveries. The modules check the country you set for 'My Store' in the Admin Configuration. If it's different from the country in the delivery address, the modules will quote. If it's the same, they won't quote. Local deliveries are much easier to quote for, and being cheaper, you might even want to consider fixed price or free delivery. Lolyco was using the Zone Shipping by State contribution from Skittles, but since May 2008, we are using an even simpler home-grown version.
A free lunch
They say there's no such thing, but in the case of these shipping modules, that's exactly what you're getting. You can download and install these shipping modules into your own sites without even saying "please". The occasional "thanks" wouldn't go amiss, and if you're passing nearby, a free lunch is always gratefully received!
Wishing you success in your e-commerce endeavour,
Lolyco.com
We use both DynDNS and ZoneEdit for our Dynamic DNS. We use inadyn for our Dynamic DNS Custom Zones, but since inadyn uses DynDNS's checkip service, it doesn't seem fair to use it for our ZoneEdit zones too.
zoneeditscript is no longer (November 2008) being maintained by us. Installation is simple - just copy the 2 files to wherever you want them on your system (we have them in /etc). Configuration is fairly straightforward - see the notes in the files zoneeditscript and zoneedit.hosts.
The script checks a router's WAN IP address by SNMP or by using whatismyip.com. It defaults to SNMP, changing it is a matter of moving the comment symbol. Use SNMP if you can, then your IP-change check only uses LAN traffic, so you can hit your router as often as you like! There's plenty of output from the script, both to stdout (we redirect it to a file, for stats) and to the system log for actual IP changes and error conditions.
Other features... a few - see my blog article on WAN IP address discovery. Some of those methods are built into the latest and greatest script. After updating the zoneedit.com zones, it goes to sleep for an extra long time. This is an effort to reduce the effect of any error in the script that causes repeated queries to zoneedit.com. If you're in the bizarre situation of needing to make repeated updates of your WAN IP address (maybe you've got intermittent connection / testing your router's power switch?), you can killall -s SIGHUP zoneeditscript and the update should run immediately. If you're adding sites to the zoneedit.hosts file (did I say it could cope with lots of domains, not just one?) you can also force an update this way.