I am a bit worried about the performance of the new ZenMagick database layer. It seems to work reasonably fast on the demo site (I ran the trunk code last night for some tests), but it doesn’t seem to scale well with less performant systems.

Some difference in the numbers is easy to explain, though. The stats for the new code include the data to object conversion, which involves quite a bit of reflection (method_exists() for example).

However, the lower spec the system, the worse gets the ratio of using $db compared with ZMDatabase

I guess there is not too much I can do right now. The OO mapping code is the same that is used right now in lots of the service classes. Just, with migration code to using ZMDatabase it means there are more places using it.

On the other hand I have started working on reducing database access, so that might make up for some of the additional processing time. In particular products with lots of attributes should benefit from that!

Ooops!

It appears there is a file missing in the release!

The problem will show up on the account, account history pages and any other page that tries to format dates.

The workaround is to grab a the file from the svn repository.

Download and copy into the folder core/rp/toolbox/defaults - filename should be ZMToolboxLocale.php (case sensitive!)

sorry for the trouble

EDIT: deng! looks like that won’t work as that class depends on other not released code!

For now, I recommed to use the old zm_date_short() function (you’ll need a previous version to cut&paste), or, if you don’t want to download an old version just for that zen_date_short($date); straight away!

A lot of security issues are concerns in web applications are related to exposing more to the public than absolutely necessary. The ‘code in the document root’ problem is one of them

zen-cart and ZenMagick suffer from this form of exposure as both are located in the document root (or subfolders). One indicator that this is perhaps not a good idea could be the number of empty index.html and .htaccess files.

Better structured applications, for example CakePHP, allow to move the application code itself outside the docroot. This leaves just the templates and other web files (.js, .css, images) visible.

In the case of zen-cart there is not a lot that can be done easily. A lot of code depends on fixed directory structures and once you add thrd party mods things get really difficult.

ZenMagick, in contrast, does not assume a lot and in fact it’s quite easy to move outside the document root.

It took me about four steps to archive this (on a running installation):

1. Move the zenmagick folder (except for the themes) two directories up (assuming that zen-cart is installed in the docroot itself)
2. Modify zen-cart’s index.php to reflect the changed location of store.php
3. Modify includes/init_includes/overrides/init_templates.php to reflect the changed location of init.php
4. Patch ZMRuntime::getZMRootPath() and ZMRuntime::getPluginsDir() to point to the moved zenmagick folder and its contents

I might actually consider changing the installation to do this as a default in the future. For now its another reason why I like ZenMagick:)

Another candidate to follow this system would actually be the cache folder to avid exposing cached HTML pages!

One new feature in zen-cart 1.3.8 was the addition of session/security token to the login form. This makes it harder to use XSS to hijack your session and is considered a good thing.

With version 0.9.2 this will also be done in ZenMagick. The beauty of sharing code to do things makes this transparent for the templates, so no changes to forms are required.

EDIT: The previous statement is, of course, not quite correct. The login box needs a wee change as it currently does not set the form id!

Even more, it’s possible to enable this feature on other (POST) forms as well, simply by adding the form id to a setting. This way even plugins may opt in to session token (the new OpenID plugin is going to do exactly that…)

I just added another store to the list of ZenMagick reference sites.

Its great to see more and more stores popping up. I especially like the fact that most stores really have their individual look and feel, rather than just being clones of the default theme. To me this is proof that ZenMagick really is good at what it claims to be: a great help to implement your own HTML rather than getting lost in template files.

It you think your store should be on that list, feel free to register and add it. Alternatively, you are welcome to drop me an email (perhaps even with a sentence or two) and I’ll be happy to add it.

It looks like there will be a couple great new plugins come out with the next release.

OpenID

The first, as hinted before, is going to be support for OpenID. The plugin will allow to add a new login form where the user can enter their OpenID. Obviously, the account edit view needs to be extended to allow setting an OpenID for the account.

Wordpress

The second plugin is going to be support for Wordpress. In contrast to the available zen-cart mod this plugin will work by adding wordpress template files to your theme. So, all code is still in one place. Support for other wordpress plugins is implicit, so nothing else required.

The plugin works by including wordpress code with themes disabled (WP_USE_THEMES). Then all URL generation is modified using wordpress filters - a great extension mechanism.

The only issue I have right now is that the main wordpress code needs to be included globally, so this can’t be done from within a function. The reason being that there are a number of globals that wordpress needs :/ So, a few changes to the Zenmagick plugin architecture were required to make this work (not great, but ok).

I recently did some investigation into the generation of email content for emails intiated via the admin interface.

The code that gets executed is in zen-cart’s admin files for each admin function (for example, admin/gv_mail.php).

The only email that gets currently handled by ZenMagick is the order status update mail All others still use the zen-cart email templates under ../email (for HTML), or the hardcoded text for text based emails.

While it might be possible to improve the situation here (which I should and will do) there are some issues.

• Guest checkout may result in duplicate email addresses
  While this is not very likely it does complicate matters. This would mean to rewrite most of the customer selection code that is based on email address.
• Without a lot of patching the only information available will be the predefined HTML blocks.
  That means some more regular expressions in email templates to extract the information wanted. Alternatively, this could/should be moved into zen_fixes.php or the ZMEventFixes class.

In any case, if you have been wondering about the format of your stores emails, at least now you know why:)

Expect some gradual improvements over the next few releases…

I just checked in a couple changes that fire new events in case of a new account being created. The really nice things is now that event listener have a chance of modifying the account directly without having to change a single line of core code (or globals!).

For example, the following code would change the default authentication status for all new accounts:

class Blocker {
public function onZMCreateAccount($args) {
$account = $args['account'];
$account->setAuthorization(ZM_ACCOUNT_AUTHORIZATION_BLOCKED);
}
}

ZMEvents::instance()->attach(new Blocker());

I guess it couldn’t be any easier than that (other than re-defining the default authentication value

So, as usual, upgrading the demo site pciked up two minor issues with the new release.

• The quick edit admin plugin contains a custom field config file that will break the site.
  This is a test file I created and that was not intended to be included in the release. Deleting the file fixes the problem (even though it’s a nice example of how to customize the fields
• The product info view in the demo theme does not display attributes.
  This is a regression caused by the theme changes in this release and all that is missing is to actually echo the attribute HTML.
  Line $53 should look like this: <p><?php echo $option ?></p>

I’ll update this post if I find anything else.

Astute readers might have already found the hint about OpenID in my tasklist. I have been pondering support for OpenID for quite some time, but decided to wait until 0.9.1. is out before diving into it.

Actually, that is not exactly true, as I did spend some time preparing for it. In particular, the code changes to extract the PHP compressor and the new PHP packer were already done with this in mind.

So, I manager to compress and pack the excellent PHP OpenID library by JanRain into a single file. Add some inspiration and code bits from Saeven OpenID and you are almost there

Unfortunately, the plugin will require code changes to ZMAccounts (well, not really changes, but upgrade to using the new ZMDatabase layer). But hopeully the next release will not take as long as the last one.

Note to self: Upgrade website with new API docs for 0.9.1 and also the demo store!