USPS, in an unannounced move last Friday 8th November, decided to change the way it supplied rates information via its servers to the many ecommerce carts around the global who request realtime USPS quotes. They changed the transfer-encoding to chunked. This is a more efficient way for this data to be transferred, so not really before time.
However it caught out a number of old usps modules which relied on an ever growing number of filters to clean up the rates data xml, because these scripts relied on the old http_client class which didn’t support dechunking this data cleanly.
For those modules that called upon curl this change would have made no difference, eg zencart, whose usps script uses curl primarily and only fallsback to http_client as a last resort.
Free code download I’ve modified the oscommerce usps USPS Rate V4 Intl Rate V2 module to check and use curl. This is written for Loaded Commerce 6.5 but can be modified for other version use.
There are a lot of things going on in the mysql database of an oscommerce-based store. Data is getting written into table rows, other data is getting updated, some deleted. Over time all of these operations leave behind old markers for rows, empty blocks that could be used but are being ‘avoided’ etc that can build up to the point of causing weird errors in the cart.
Optimization is the jargon for cleaning up the debris in the database so the read/write processes run more efficiently, giving you quicker query times and more accurate, trouble free store operations. It’s the server equivalent of defragmenting a disk drive of your computer.
The optimization process is simple and I’d recommend performing this regularly. Here’s how:
If you have a cPanel hosting interface, look for the link to the database utility phpmyadmin:
Select the database you want to work on, then check the size of what’s referred to as ‘overhead’ – ie junk that prevents the database from working as smoothly and efficiently as it could:
If there is some, remove it by selecting All Tables (1) and then from the dropdown in the middle, Optimize Tables (2) :
After the procedure has completed, the overhead count on the lower right should show 0 bytes. Job done :
How often do you have to optimize a database?
I recommend every 3 – 4 weeks.
Anything else we should do when there?
Never hurts to run Analyse Table as well as this is like a wheel alignment for the indexes and keys used on tables.
I’d also recommend truncating (ie emptying) the frequently updated tables like whos online, visual_verify_code and sessions.
If you need help with this contact me or alternatively I can provide maintenance like this (and more) on a support contract for your site