One of the things that ZenMagick does not very well at the moment is handling file permissions of files it creates.

I just added this on my 1.0.0 tasklist, so hopefully it should get better soon.

Until then, there is a simple workaround - using the PHP Console that comes with ZenMagick (admin: ZenMagick -> Console.

The following shows the most useful commands for handling permissions.

getcwd();

Returns the current working directory. In the console context, this is going to be the full path to the admin folder: This is helpful to get your bearings.

chmod(..);

Another PHP function to change file permissions. For example, the following will grant full file permissions to everyone (user/group/other) to init.php:

chmod(getcwd().'/../zenmagick/init.php', 0777);

ZMTools::rmdir(..);

A very dangerous function that allows to recursively delete a folder tree incl. any containing files. To, say, delete an empty theme the following could be used:

ZMTools::rmdir(getcwd().’/../zenmagick/themes/MyTheme’);

Even though I used getcwd() in the examples to build the filename/directory name, it is worth using proper full names to minimize the chance of deleting anything accidentally.

For those waiting for 0.9.2 - things are progressing, although on a somewhat reduced speed.
Using the new unit testing plugin (to be released with 0.9.2) I managed to iron out some inconsistencies in ZMAccounts, which were causing some strange errors.

Handling of custom fields is not working as expected - there was a surprising number of places where things were actually not working!

Looks like I will have to look at the old database code again - ZMCreoleDatabase does break the phpBB plugin - somehow the active database is not switched. Unsurprisingly, this works ok using ZMZenCartDatabase….

Email support is greatly improved - in particular now that I have found a quite good place to keep all the custom code in one place do the templates start to look like templates and not spagetti code. I’ve added new templates for gv_queue, gv_mail and coupon. That means there are only two more emails left and those do not seem to be to important (unless someone complains loud enough).

There will be some new business events - ZM_EVENT_CREATE_ACCOUNT, ZM_EVENT_LOGIN_SUCCESS and others. I think there will be even more- in particular the fact that it is now possible to modify objects passed into the event handler make this much more useful.

There is also an event that allows to customize the context of all emails. This will allow for injecting custom data to make emails more powerful. (In fact, this is how ZenMagick now prepares emial content, rather than having code in each template).

The view code has been clean up a bit and is now more consistent. This should make plugins with more than one view much easier to create.

I’ve also added support for session token to secure forms against XSS. Forms to be procected can be configured dynamically (this allows, for example, the OpenID plugin to take advantage of this feature, too).

And, of course, the usual number of fixed bugs is in the mix as well.

The code is currently tested and I would expect a release within the next few weeks.

As mentioned earlier, I am trying to reduce the number of database queries. One of the biggest culprits here is the attribute and attribute price handling.

With the new database code I finally have all attribute data easily available and so it just needs some patience to follow the zen-cart code to find out what exactly has to happen and how to convert the code to use the already loaded data.

Right now I am using this product for comparison. With the current changes on trunk I have the number of $db queries down to around 590 337, compared to the whooping 1500 using 0.9.1. The best thing about it: I am not even finished

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…