The original version of this post was posted over on zen-cart’s forum , so I figured it might be worth cleaning it up a bit (not too much, though) and reposting it here for folks that do not read the forum.

This is a rough outline of the planned ZenMagick releases leading to ZenMagick 1.0. It’s quite vague about how many more 0.8.x or 0.9.x releases there will be, but that is something I do not know myself yet. (more…)

Not sure how many of you do gift vouchers on your sites, but you might be happy to learn that finally implemented that view and the business logic behind it in ZenMagick. It actually quite embarrassing to admit that I completely missed this so far!

I  contrast to the zen-cart page flow I put the redeem form into the gv_redeem view as that makes more sense to me. The FAQ is not implemented – it’s just a glorified version of an ez-page chapter and should be implemented as such by the store owner if required (or included as pre-configured ez-pages by zen-cart).

I also fixed quite a few small and medium size bugs. If you can’t wait for 0.8.4, check the bug reports; most do contain workarounds or fixes.

Since GV redemption was the last form submit not being implemented in ZenMagick (except for the checkout process), I am now in a position  to disable zen-cart’s header.php processing for normal store pages completely. This should hopefully bump performance a bit as it takes away redundant processing when using ZenMagick. I’ll also be able to remove some of the zen-cart fixes which were previously required to make zen-cart’s header.php code work with ZenMagick generated requests (in particular POST requests).

I am still undecided as to what else should be included. Considering the number of bug fixes I might decide to make this a rather small release and release soon…

The new Ajax features required adding some new methods like addProduct(..), removeProduct(..) and updateProduct(..) to the shopping cart class.

One thing I haven’t mentioned yet is the new attribute support. This is only relevant if using product attributes in which case there is base product (without any attributes) and product variations (same base product with different sets of attributes).

Base product could be a T-Shirt and product variations the same T-Shirt in different colours.

The new methods do now support adding default attributes if a product has attributes configured, but none are passed into addProduct(..).

The function doing all the work is zm_sanitize_attributes(..). It will build a set of default attributes and then merge the given attributes into those. The effect is that adding a product without attributes will result in a cart items that has all default attributes assigned (uploads are currently not supported at all).

This piece of functionality can be disabled with the new boolean setting ‘isSanitizeAttributes’.

It appears that some files of the new 0.8.3 release on sourceforge.net are corrupt. Not sure yet as to which files are really affected, but for now the alternative is to download zenmagick-0.8.3.zip from the zen-cart contribution section.

EDIT: I updated there core release file and tha apidocs but it might take a while before those changes are replicated onto the mirrors. Until then, please download from the zen-cart contribution.

Now that the 0.8.3 is on live, I added the Google Maps Store Locator plugin to the demo site.

The plugin admin page allows to set the location using a similar map with a drag/drop marker to mark the spot!

Adding a new page is perhaps one of the most common tasks, so I hope this is useful for a lot of people.

Adding a new page is different from adding a static page in that static/ez-pages just add content while using an existing template. Here, we will be adding a new template and, depending on the complexity of the requirements, a new controller and perhaps even view mappings.

(more…)

Last teaser before the next release, which should hopefully come out next weekend…

One of the bigger additions to ZenMagick in 0.8.3 is what I, in lack of a better name, called SACS (Simple Access Control System). Not overly original, but it gets the intention across, I think.

(more…)

With PHP6 coming the days of PHP4 are numbered. Following the example of many other PHP projects I have decided that as of February 2008 I will no longer support PHP4 (at least if I need newer features I’ll not hesitate to use them).

There is no immediate need to convert any code – ZenMagick works just fine with PHP5 (haven’t looked at PHP6 yet). There are, however, a couple advantages that I would like to use in the future:

• Interfaces
  There are a few classes in ZenMagick that actually should be interfaces rather than classes.
• Protected and private class variables
  Currently, all class members are visible. They are not documented in the API docs, but it’s still possible to use them. I’d like to change that, even though this will mean that ZenMagick itself will have to behave better
• Reference handling
  Coming from Java, reference handling (or the lack thereof) in PHP4 drives me mad. PHP5 will allow to get rid of a number of ugly hacks I had o use to get around some of those problems. I also suspect that proper references everywhere should allow for a small performance win – creating copies of all the objects (in particular categories!) does take some time after all.

I will explain any dependencies on PHP5 as they appear, so sites still depending on PHP4 should have a chance to port stuff back to PHP4.

The ZenMagick admin pages are something I am not overly proud of. On average they are perhaps not worse than other mods admin pages, but compared to the effort I put into the storefront code they are very sad to look at.

There are some notes in my TODO list (which I do not update or consult very often) that ponder the need for the use of a framework to rebuild things from scratch. I still think this would be the best solution, but then there wouldn’t be much left of zen-cart at all The biggest downside (and the actual show stopper right now) is the fact that it would be very hard to migrate slowly (ie. one screen at a time).

So, while I really like the idea I feel there should be an intermediate step that involves some sort of simpler approach while leaving enough flexibility to make new pages (mostly) reusable in the long run.

I’ve had some half-hearted attempts at building something, but the fact that none of the current logic is reusable makes it a very big project. The only reusable piece so far is the new menu code. Still, it will require a lot more before it starts to make real sense… We’ll have to wait and see, I guess….

I have been thinking a bit more about the mutlistore mod and if/how this would work in ZenMagick. (more…)