A quick heads up on the current ZenMagick development. Aside from the odd bug fixes I am quite happy with the result.

Currently, as it happens, I am working on email support. It’s a funny one. (more…)

PHP is a scripting language. As such it is quite easy to put pieces of code that are used in different places into a separate file and include/require it when needed. This was and still is common practice, especially when not taking an object oriented approach.

So, what is wrong with it?

Every now and then I need to trace request processing in zen-cart to figure out what actually happens. This can be a very frustrating process as zen-cart does exaclty what I described above. Furthermore, there is code to load and instantiate classes and utility code on demand. Don’t get me wrong - this is perfectly legal and ZenMagick has also some code to do stuff like that.

What happened yesterday was that I was trying to fix a bug in ZenMagick code. On the checkout success page there is the option to select products that you are interested in and for whose you want to get update notifications. This was broken, as only one product got picked up, rather than all selected.

Eventually, I found that ZenMagick’s zm_href(..) function does not handle multiple values for a single request paramter correctly (for example: notify[]=3&notify[]=19) . The square brackets are the PHP way of creating an array of values in the request parameter arrays $_GET and $_POST, respectively.

Anyway, before I could find that, though, I had to find my way through includes, redirects to the same URL just with a different action value in the URL, redirects and eventually came across main_cart_actions.php. They only reason that I looked into that file was that a global searchfound the string notify in it. Now, thanks to the zen-cart event handling, there is lots of notify around, but still. So, it turns out that updates to product notifications are handled by the shopping cart! WTF!

The basic idea in zen-cart’s architecture of having a dedicated folder containing code to handle a particular request is not bad. But every time I am looking for something special, it’s handled in a special file that sits on a higher level. Makes sense as the code is shared between different requests. on the other hand it’s usually hard to find even though more often than not I look there first!

A couple emails I received lately made me wonder about uninstall. True, ZenMaick does clean up the changes it has made to zen-cart files, but it’s not perfect. There will be improvements but it is not (yet) going to be a full uninstall procedure.

Also, I prefer a procedure where the user has at least some degree of control about what is happening. (more…)

Something I’ve been wanting to write about for quite some time…

To answer this question we first need to get a good understanding of what ZenMagick actually is. ZenMagick is:

• An object oriented API that allows to access most of zen-carts data in an abstract way, so the caller does not need to know anything about the underlying database structure
• It also is/contains an alternative templating/theme system. This does behave similar to what zen-cart has to offer with a few exceptions:
  • ZenMagick theme files do use the ZenMagick API - there is never going to be SQL in a template file!
  • Due to the fact that the API is used, there is no need to require/include back and forth to make business logic
    available to theme files, making them much smaller and easier to write
  • ZenMagick does not support all of zen-carts options to configure the look&feel

(more…)

A quick update on what’s happening with the upocoming version 0.7.0.

I have to admit that I am more that happy with the changes so far. Not only did I implement the stuff I had planned to do, but I also added a few things I didn’t even know about beforehand (more…)

Another round of things that might be interesting for people using ZenMagick. Also a chance for me to write down a few things that are not documented anywhere else and hopefully add them to the ZenMagick website as well… (more…)