The zen-cart code which is used as basis for the full ZenMagick release was recently patched to significantly reduce the number of database queries. In particular products with attributes will trigger enormous numbers of SQL queries during checkout.

While this is generally not an issue in ZenMagick (since there is only a minimum of Zen Cart code used), it is currently limited to everything except the checkout. A good way to illustrate the difference is if you go to the ZenMagick demo store and add this product to the cart. Once you are in the cart, have a look at the stats at the bottom of the page where you can see the number of database queries (split into zen-cart and ZenMagick queries).
Now, disable ZenMagick by clicking the ‘Toggle ZenMagick theme support link in the top right corner (You’ll have to scroll a bit down now). The difference in queries is striking, IMHO.

As some might remember, I’ve been working on code to handle the checkout shipping page. Not surprisingly, products with attributes are also a big factor in checkout performance. With three variations of the above product in the cart, the number of database queries drops from about 20.000! using Zen Cart to roughly 10.000. That’s a 50% drop!

The number of ZenMagick database queries, OTOH, increases from 7 to about 200…

The reason that there are still so many queries is that shipping modules are still pure Zen Cart. Also, the ZMShoppingCart acts as wrapper for some Zen Cart code that is tightly bound to the checkout process and therefore not that easy to replace/optimize.

Is it just me or did I forget my weekly update last week? Well, I guess it could always blame Easter…

Despite that, things have moved on at pretty normal speed:

• Full release
  The full release build includes removing some things deemed unnecessary from the zencart base installation. I’ve added some more code to the build process to zip all that stuff and add it to the zc_install folder, so it is there if needed.
• ZMToolboxNet
  Removed dependency of $request. In fact, both methods moved to ZMRequest, so the class is pretty much obsolete. I’ve updated all template files, but the methods will be available for a while so upgrading is not so painful.
• Changed code to actually use the store’s ZMSeoRewriter implementation (ZMStoreDefaultSeoRewriter).
• Improved the checkout helper (ZMCheckoutHelper)
• Fixed merging in ZMUrlManager’
• Unit testing
  Since all plugins have their custom tests in a tests subfolder I declared that a convention and removed the code where each plugin had to manually add that path to the loader’s class path. Instead, the unitTests plugin will iterate over all active plugins and add the tests folder if found. That means this is only done when actually testing, nor for each request.
  So the only thing required to register a test class is to append the class name to the custom setting ‘plugins.unitTests.tests.custom‘ or register the class directly with the unitTests plugin instance.
• groupPricing
  Make this plugin useful by displaying existing pricing records and allow to modify/delete those
• fix ZMOrder::hasShippingAddress()
  This would sometimes not return the correct status.
• Add a lot more error checking to various controllers and allow for more fine grained error pages
• Fix an issue with using getallheaders() when running as CGI/FastCGI.
• Move all store code into a lib subfolder to conform to the generic MVC folder structure.
• Make the ZMSession base class work – that means the generic MVC code now does support sessions (cookie only)!
• add missing echo for gv related data to views; gv_send.php and email/gv_send.text.php

With the url() method moved to a ZMSeoRewriter instance, it is time to think about a default default implementation that eventually could be used for other apps using the MVC framework. One of those could be a new admin app…

My current preference is to write something similar to WordPress permalinks. Those links could either include index.php or drop it if rewriting is active (this would have to be configured manually, though).

Would there be anything better?

Lately I’ve been making some progress with the generic session class. With session and request class becoming more and more simple wrapper around session and request data it seems time to hold for a moment and try to find a good place to provide access to custom data like the current language, currency, etc.

Right now for the store some of that is in the Runtime class. But that is just ugly code to hide the fact that a new session object is created every time instead of using the reference that $request holds.

There are a few more things like this and getting this structured a bit seems like a good idea. One strong candidate to hold all these information is, of course, the shopping cart. Not only is it (already) the main session object, most information stored elsewhere are typically used in conjunction with the cart (data).

Another good reason is that I’ve seen similar organization in other e-commerce systems, so it seems to make sense.

Finally, moving some of that would make the Runtime class a bit more generic again and move application specific stuff in application code. (To be clear, Runtime is an application class, but it extends a generic core class that is not designed for some of the things Runtime does right now).

As usual, comments and opinions are welcome.

Another question about zen cart (and hence ZenMagick).

Looking at the checkout process and comparing it to other solutions I wonder if the checkout confirmation page is really necessary. Theses days were people are so worried about conversion rate, having an additional page that doesn’t really add any functionality seems a bit of a waste.

Is that something that should be dropped in ZenMagick?