A while ago I wrote about the loader and how there were still a couple pieces missing to make loading really useful.

As it turns out PHP has an answer for my question and that is __autoload(). I’ve read a little bit about this special method [or hook if you like] but then forgot about it again. Having a better memory would have saved me a few hours, I guess

The __autoload() function allows application code to make one final attempt at locating and loading unresolved classes/interfaces and functions. Adding this function with a simple call to the loader was all needed to make everyone happy and remove the need to call ZMLoader::resolve('CLASSNAME') to be able to safely use CLASSNAME.

However, things were not quite as easy. The loader uses a lot of class_exists() and such and (obviously) those trigger another call to __autoload()! So, I’ve rearranged the central code in ZMLoader again and actually it is a lot more readable now [and perhaps even a bit faster too!]

The most satisfying bit of the whole excercise was removing the code that preloads a range of classes to be able to use the service classes right away. Also, in places where explicitely classes with the ‘ZM‘ prefix are used it’s now possible to use PHP’s new operator rather than the more convulated ZMLoader::make('CLASSNAME');.

Perfomance doesn’t seem to have suffered from this change and in some case might even be better (at least when not using core.php). And while I was at it I added some simple stats to the loader and extended the zm_page_stats plugin to display those. It’s rather basic and consists just of the number of static and class/interface files loaded during a request. Still, interesting to compare different pages.

Last night ZenMagick 0.9.5 was finally released! I am quite excited about this particular release, because it includes a couple things that make ZenMagick a lot more attractive to existing Zen Cart installations.

For one thing, there is a new patch that allows plugins to access the final HTML content of Zen Cart templates. This has been around in ZenMagick (for themes) for quite a while and proves to be very powerful.

A lot of the storefront plugins (page stats, page caching, google analytics) depend on this feature and now they can be used with Zen Cart templates too!
If you head over to the demo store you’ll see that the HTML generated by the default Zen Cart template is caches like any other page, following the same rules!

Another quite surprising thing (at least  for me!) is the new PDO based ZMDatabase implementation. It seems to be the fastest implementation so far and the demo store seems to do fine using it, so I might make it the default implementation for the next release.

There are also improvements to existing plugins and, of course, a couple new ones. The most interesting one is probably the phpBB3 plugin. It provides the same features as Zen Cart’s phpBB support, just for phpBB3.

I also really like the new theme toggle plugin that allows to switch between Zen Cart and ZenMagick. Probably not very useful for a production environment, but good to compare features, displayed values, etc.

Of course, this is not the end, and I’ve already started working on the next version. In that context a reminder that with 0.9.6 I’ll be removing a lot of the deprecated stuff. Also, the deprecated API support will be removed before a 1.0.0 release, but most likely not before 0.9.8.

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!

Somehow I overdid it with adding code to purge old cache entries by adding additional code to the memory cache implementation. Turns out that Cache_Lite doesn’t support any modus parameter for memory caching!

So, if you are left wondering where all the additional SQL queries for attributes are coming from, now you know.
Since I plan on releasing this weekend there is probably not much point in posting a bugfix or similar. Anyway, if you want to fix it yourself, just delete the following line in ZMMemocryCache.php:

$this->cache_->clean($this->group_, 'old');

On a related issue here is a nifty small code snippet that allows to display the top queries for the current request (using ZMCreoleDatabase or the new ZMPdoDatabase). Just paste that into your local.php and you’ll see the most often run queries (usually with different parameters):

class DbStats {
public function onZMFinaliseContents($args=null) {
$stats = ZMRuntime::getDatabase()->getStats();
$map = array();
foreach ($stats['details'] as $details) {
if (!array_key_exists($details['sql'], $map)) {
$map[$details['sql']] = 0;
}
++$map[$details['sql']];
}
foreach ($map as $sql => $count) {
if (6 < $count) {
echo '<strong>'.$count.'</strong> '.$sql."<br>";
}
}
}
}
ZMEvents::instance()->attach(new DbStats());

(Reminds me that I am still looking for a good WP plugin to preserve formatting and perhaps even do sytax highlighting!)

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 happened to notice a  search ‘when is zencart 2.0 actually coming‘ in today’s log. It’s a good question. Unfortunately I do not know the answer, but I do know that the next ZenMagick release is not far!

Today I checked in the final changes to make the category pages use the new sql based pagination code that hopefully will be on par with the way Zen Cart handles it [(except for being a lot more complex, of course ].

That means that the last bit I was hoping to get into the next release is actually in place. I’ll be doing some more testing and try to figure out which plugins need updates. That should hopefully get me to a point where I can write release notes and build ZenMagick 0.9.5 next weekend!

I think I really need to do something about the plugins. Ideally, they would all have their individual changelogs, but right now with core changes that affect pretty much all plugins that seems to be overkill. I guess for 1.0 that might be something to look into, though.

Coming back to the search mentioned above: Of course there is no need to wait for Zen Cart 2.0 in order to enjoy things like:

• Plugins that do not require file changes
• A simple template structure that does not need include/require
• A database API incl. DAO’s, transaction control and support for different database providers
• A MVC based framework
• Flexible form validation with rules to change both JavaScript and server side validation in a single place
• Guest checkout aka. checkout without registering
• and a lot more

Just start using ZenMagick today!

Yesterday I landed some code changes that will should show major performance improvements browsing large result lists.

Result lists together with filter and sorter options are managed by the class with the obvious name ZMResultList. So far, sorting and filtering is done in memory. While this allows for simple code to add sorting and filtering options, it also means that all items of a list need to be loaded first.

For small stores that is not really a big deal. There is a reasonable amount of caching going on in the service classes that provide access to the database. Also, with small lists the performance is as good a SQL based sorting, filtering and paging. Now for large catalogs this is not acceptable and in fact means that ZenMagick in its current form is unusable.

The way the new code works is to allow service classes (actually, any class that provides database access) to implement a new interface ZMSQLAware. When a result list is set up the code will check for implementation of this interface and if it exists, use the method(s) defined by that interface to do SQL based paging. This is similar to the way Zen Cart works now and in fact some of the code is based on that.

The next step will be to change the filter and sorter code to also be aware of SQL to have a full SQL based solution.

Today I’ve checked in support for sorters and filters! Right now, the only service to support this is ZMOrders (incl. a new order sorter (date and status) and filter (status).  The filter is not yet done properly since the code currently depends on request parameters. So among other things I’ll be reviewing all of that (for both sorters and filters) to make them request agnostic without having to write too much code.

After that is should be pretty easy to add support for other services, sorter and filter…