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.

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…

I’ve just updated the demo store with a release candidate version of ZenMagick 0.9.5.

There are some interesting visual and other changes that the demo store illustrates:

• Use of PDO based database API
• New plugin to switch between ZenMagick and Zen Cart template
• Improved event support for Zen Cart templates (that’s what the switch is really for!)
  The extended event support now allows ZenMagick plugins to manipulate the final HTML of Zen Cart templates. That means, all ZenMagick plugins that rely on this mechanism can now be used in Zen Cart templates, too! Obvious examples are the page stats and style switch plugin (even though the style switch doesn’t really work for Zen Cart templates, right now).

One thing that is now good to see is the difference in database queries. Even though the Zen Cart default template and the ZenMagick themes do not display exactly the same data, it’s still impressive to see the difference in queries

I somehow lost my release notes so the public release will have to wait until early next week to give me time to get organized again.

Happy demo’ing!

A while ago I wrote that I’ve been working on (yet) another implementation of the ZenMagick database API using PDO.

After some back and forth (the code was removed and readded yesterday) I’ve started working on that again. There are a couple good reasons for that.

Firstly, since Creole is not supported any more, having another implementation seems like a good idea. Secondly, it appears that it is quite a bit faster than Creole (and perhaps even Zen Cart’s $db).

I haven’t had a chance to verify this usingpages with lots of database access, since there are still bits missing in the implementation. The good news is, though, that the tests for ZMDatabase have been improved and extended in the process of filling the gaps.

In related news, I’ve decided (more or less) to make another change to the database API. This will only happen after 0.9.5 is released, though. The methods to control transactions are a bit clumsy and I hope that things will be a bit more intuitive in the future.

I am currently going through all unit tests to slowly prepare for the next release. Since all tax service tests failed for a while I decided to see what that was about.

(more…)

Form validation rules
Since it is now possible to either add or replace validation rules for a given form id, there is a pitfall in that plugins typically set up their custom validation rules before the global/theme validation rules are loaded. If a theme developer decides to override the default rules for a form those plugin rules might get lost.
For example, a particular site might not require a date or birth, postcode, etc. and it might be easier to replace the default rules with a new (smaller) set of rules.

To avoid overriding plugin rules I’ve started converting plugins to use the onZMInitDone() event callback to register custom validation rules. This event is fired once al bootstrap, init and theme setup is done (right before the controller gets executed).

Database auto mapping

I might have written about this as part of a release announcement, but I can’t really remember, so here goes (again)…

Most All ZenMagick services and other classes that access the database use manually created mappings to map object properties to database columns. These mappings are store in the appropriately named file core/database/db_mappings.txt. The mappings also contain information about data types which are used to properly bind values (ie. cast to int, boolean or quote to name just a few).

Sometimes it is not practical to create mappings in advance. In particular if the exact format of the table is now known. In those cases the ZenMagick database API can generate a generic mapping on the fly to ensure type safety. One good case where this is useful is to access 3rd party databases/tables (the new phpBB3 plugins will make use of this).

Currently this is disabled. To enable just change the value of the setting ‘isEnableDBAutoMapping to true.

One of the new features in the upcoming Zen Cart 2.0 version is going to be a reduced number of database queries for price lookup. Most of those queries are attribute related and therefore do not affect all stores/products.

Due to the current work on making ZenMagick properly available for Zen Cart templates, I’ve had the chance to do some easy comparisons. (more…)

I’ve been pondering whether to have another release before Christmas for a while now and I think it would be a good idea. As far as releases go this is going to be a pretty minor one.

I spend a some time fixing some small things that croped up and als refactored a lot defines away (making them consts in service classes mostly). Some theme related defines about directory names got removed completely as they do not really change a lot (and shouldn’t either).

On the plus side there are going to be two new plugins. Firstly, the already annourced form handler and also the code I’ve been using on the demo store to switch themes.

There is also some new code in the form of new cache implementations and also a new ZMDatabase implementation using PDO.

The only real downside is that I’ve touched every single plugin. That in itself is probably not a bad thing, however the sourceforce file release interface requires to set platform and file type for each separately and that is a real pain.

Yesterday I checked the creole homepage for updates and to my horror I discovered that the project is being abandoned.

While I can understand the reasons behind this step to a degree, I still feel sad on different levels. I’ve picked creole as alternative to the current Zen Cart database code as it seemed mature and, at least to me, rather promising.

Also, the style it is coded in is very close to my ideas about how PHP code should look like. Seeing that the repository is going to exist, maybe there is still hope that someone else will pick up the project.

For ZenMagick, nothing really is going to change. I’ll be trying to convert the current 1.2 beta code into a single file as I’ve done with the 1.1.0 release (I had a go at that in some spare minutes, but there have been changes that make the current import code break, so it’ll take some time).

I am glad that I took the time to write my own (thin) database layer for ZenMagick to avoid depending on a single external project. This is proof that it was time well spend, even though the circumstances are very unfortunate.

I might evaluate another database API for the future, although this is very low priority and will be far in the future. Suggestions are, of course, welcome.