As mentioned before, I’ve started playing around with Savant3 as an candidate to complement the current view code.

So far I’ve got a simple subclass (plus about 5 lines of patching in Savant.php itself) to make it usable as template wrapper.

I appreciate that it is rather simple and I can’t really follow some of the complaints about code missing compared to Savant2 (which I haven’t looked at at all).

Advantages

• Savant provides pretty much everything the current theme class has to offer. True, it doesn’t have a method to generate theme URLs, but that is easy to add by subclassing. Also, since there is a setting to configure the default view class it would be easy to switch between implementations.
• Another feature of Savant (as of version 3) is support for compiler. The default templating system (if you want) in Savant is straight PHP, sprinkled with some nice helper methods.
• However, there is support for compiler. Another word to describe this might be pre-processor. So, how is that good? Well, I guess it could be used to implement caching on block level. Considering that each sidebox is included separately, some could be cached, even if the page as a whole is not. I think Smarty does a similar thing, even though this migh be abusing the system a bit…
• I’ve mentioned that templating is just plain PHP. This would tie in with the current ZenMagick approach and could  could be implemented almost transparently.
• Another nice thing is that theme inheritance is pretty much build in. Savant allows to configure as many search locations for templates as you want. Done in the right order, this behaves exactly like theme inheritance! And with much nicer code!

Beside the goodies above using Savant might have some positive side-effects on other ZenMagick code as well. For one thing, it would force me to really continue with my theme code cleanup. It might be a good time to get rid of the them info class altogether, perhaps in favour of a simple properties file?

So, I am really tempted. However, there will be more experimenting before I’ll be  making a decision. Until then there is more code cleanup to be done. On the other hand I might put this into the mix while I am at it … stay tuned

My refactoring of a lot of ZenMagick code is getting along fine. It’s actually fun and I get a chance to look anew at some of the older code bits.
While this doesn’t really add any new features it’s still worthwhile IMHO, because it makes me rethink things, and helps untangle some code.
The major block left is, unsurprisingly, the view/controller stuff. Since I am not very happy with:

• The view class(es)
• Some of the controller code
• The URL mapping

I might delay that a bit while doing other things. I’ve started looking at templating libraries again, just in case there is something useful. I might have a go at Savant. It’s small, simple and does pretty much the same as my view code, except a lot nicer and more flexible.

Any other suggestions for this?

The last week has been for for the restructuring of the ZenMagick source files. One of the main reasons for that is that the recently added support for the magic __autoload() function really helps and allows to structure files according to logic (I hope) and not to please the loader.

The result will be new folder lib, replacing the current core folder to hold all general source files. This is perhaps not the end, but it’s good enough for now.

In there, there will be three subfolder:

1. core
   The real core. All files in here depend only on each other. That means it will be easy to re-use those files without and other dependencies. All that’s required are two or three lines of code:

   include 'whatever/path/to/core/ZMLoader.php';
   ZMLoader::instance()->addPath('whatever/path/to/core/');
   ZMLoader::instance()->loadStatic(); // only required if using creole

2. mvc
   This will eventually contain the generic MVC bits of ZenMagick. Right now this is still pretty empty as there are too many dependencies to the store related code and extracting this is really only planned post ZenMagick 1.0.
   However, seeing that I do work on this code continuously, it’s good to have a place for those changes rather than just making notes and hope that I will remember what I had planned sometime in the future.
3. store
   This is the place for all store related code. This includes helper code, the controller, configuration files, etc.
   Should it ever come to a proper generic MVC framework, this code will move into a separate store project that gets executed as one of (hopefully) multiple web applications on top of the framework. Ideally, the admin application could be a second one (sharing a lot of the store related code).

Other than that I’ve landed the product association framework and a first handler that implements the zen-cart also_purchased_products.php functionallity. I hope that before the next release is due to have at least one more handler that will allow to tag products. We’ll see how that goes.

Also, there has been some initial work/thinking about vBulletin integration. I am really excited about this since the project includes a great vBulletin developer that will handle the forum side of the code, which is something I am very grateful about!

Next on my list is following up on the outstanding work on the shipping provider and cart service. Definitely enough for another week

I am really excited about a new project to write a vBulletin integration plugin for ZenMagick. I can’t really give any more details, but it looks like it might end up full blown two way syncing of user data and perhaps even single sign on!

I’ll write some more once this there is some progress to talk about…

Over the last few releases a number of new classes and other files have been added. Now that I work on adding more services it becomes really obvious that it is time to think about re-structuring the way the files in the core folder are organized.

Another issue is that I am not too happy with the ‘core’ folder itself, so that name might change too!

One thing I’d like to archive at the same time is to split files into generic and store-application specific. For example, the database related classes are pretty much self contained and (except for the ZMZenCartDatabase implementation) do not depend on zen cart in any way. Same is true for some of the services, MVC code and other. All in all another step to separate the framework from Zen Cart/store code.

Since class loading does not depend on files being in any specific folder/locations. That means upgrading ZenMagick by replacing the zenmagick folder should be safe and nothing else should be required.

I’ve done a bit of 3rd party integration work for ZenMagick, mostly on the Wordpress and phpBB plugins. The following is a summary of my experiences and thoughts about that (based on a discussion I’ve recently had with a client).

3rd party integration examples in ZenMagick

The ZenMagick Wordpress and phpBB plugins implement user syncing from Zen Cart/ZenMagick to the respective 3rd party application. That means any user/account change relevant in the other application is forwarded (or, more precisely, applied to the other application’s database).

What is full integration?

There is, of course, more to be had. Full integration would be to do exactly the same (ie. updating the Zen Cart database) from within other application (where appropriate).

Why ZenMagick plugins only implement one side of side of user syncing

Syncing from ZenMagick to another app. is obviously not that hard. In fact, I’ve spend quite a bit of time tweaking the ZenMagick plugin architecture to allow doing that in a way that does not require any patching on Zen Cart or ZenMagick core files [excluded patches on Zen Cart to make ZenMagick work at all].

Things are looking quite differently doing the other side. The main blocker in implementing that is simply time! I just don’t have time to get involved in every 3rd party at the low level required in order to handle registration, login, logout and other events. I am sure other apps have code to allow to capture and process those events one way or another. However, learning that just for the sake of a plugin is just not possible.

I suppose for someone who maintains just a single plugin it’s fun to dive into both apps involved, but for me it’s just not practical.

Events that need handling for full user syncing

There are a number of events in each application that result in user data being changed. For ZenMagick, events exist to allow easy processing of the following events:

• registration
  Registration of a new user. Once a user account is created, an event is fired that includes the new account. Also included is the password in clear text to allow plugins to store it (as-is, or as some sort of hash) in the other applications database
• account update
  Fired each time account information are updated.
• password change
  Since Zen Cart/ZenMagick have a separate dialog for updating a password, this is a separate event from account update. As with the registration, the clear text password is passed in the event.
• request new password
  Similar to a password change, however in this case the password is generated rather than changed.

Since it is usually not practical (the only exception so far is Wordpress) to use code from both applications at the same time, the typical solution to add data to the other application is to generate low level SQL. (For exampe, phpBB uses a global $db to access the database, same as Zen Cart!).

Single Sign On (SSI)

If SSI is required, the list of events to handle needs to be expanded by the following two:

• login
  An event to notify interested code/plugins that a user has successfully logged on. The account is part of the event parameters.
• logoff
  Indicates that the current user has logged off.

Capturing these events is as simple as all the others above in ZenMagick. The tricky bit is to actually make the other application believe that the same has happened over there!

There are a number of ways to archive this:

1. Fake login/logogg requests
   The code that handles the login/logoff events generates a GET/POST to the other applications login form / logoff URL with appropriate parameters.
   This does work, however for my taste this is a bit too fragile.
2. Simulate login/logoff
   What I mean with this is that all activities required to register/invalidate a session are replicated. This includes:
   • Set session cookie
   • Create session record in database (or other session store)
   • Add user id or other session data required to make a session valid

   Obviously, this is the more elaborate alternative and also not without downsides. It requires intimate knowledge of the other app and is prone to break when the 3rd party application is upgraded.

3. Linked user accounts
   This approach is based on some sort of repository (usually a database table) that is used to map or link corresponding user between Zen Cart and the 3rd app.
   Then both applications need to be extended to allow to recognize each others session. This doesn’t have to be complete, though. It is sufficient if ZenMagick can identify the 3rd party’s user id and vice versa. The mapping table can then be used to lookup the corresponding own user details and the user gets logged in automatically.

Personally I really like option #3. I haven’t tried implementing it yet, however it seems to involve the least overhead on both sides. Also, it minimizes the amount of knowledge that each application needs to have of the other one and leaves each application to manage it’s own sessions, not the other ones!

In the most generic version there could be a login service on ZenMagick side that manages a number of 3rd party specific sniffer modules that try to detect 3rd party sessions for each request. In that scenario only the really application specific code would need to be written from scratch for each new external application.

The good news is that with zm_auto_login a plugin already exists that can login a Zen Cart user based on an customer id taken from a separate database table (and identified by a separate cookie [that could be shared by both apps]).

Work on 0.9.7 has now really started. While I still struggle with some of my test enironment I am back in a position where I can comfortably work and be productive.

So far I’ve managed to integrate the token service plugin into core, so the plugin will be marked obsolete as 0.9.7. I am also close to having the announced associations service ready to do some work. Once that is good to go I might add a simple plugin to actually make it useful.

Next bigger items on my list is to finally finish the new ZMShippingProviders and  ZMShoppingCarts services. Once that is done it should be fun to start working on making the ZMAjaxCheckoutController really useful. Only thing that is not quite clear yet is whether the shipping estimator on the ajax cart controller should survive or not…

There is also some paid-for work that will take up some of my time. It looks like there might be another one or two good plugins coming out of this, more on that perhaps later once I’ve got something to show.

Last night I finally released ZenMagick 0.9.6. While I am not 100% satisfied I still think it is a good release.

Upgrading might be a bit tedious this time, due to the many changes to form field names. However, using the default theme should give you some idea about what to do.

My wish for this release is that it will generate more reactions than the last – and I am not only interested in positive response. Every bug report is better than nothing at all.

Like always I’ve got already a few things lined to work on now. Sometimes it’s actually quite hard to restrain myself in order to finish a release rather than adding and adding…

First of all there is the (not final) list of services to add to core. In addition I’ve got currently a list of the following items, but nothing is final yet:

• finish new cart and shipping code (plus ajax and cleanup [shippnig in cart and checkout ajax])
• finish some plugins
• easier plugin enable/disable – more admin ajax
• widget review
• more framework work
• setUrlMappingInfo – rework and finalize
• admin migration?

Also, I hope to tackle a few more items from the visions page.

Enjoy

I’ve been pondering adding some more (not just database access) services to the core of ZenMagick. Right now my (rather short) list of services is mostly made up of plugins and yet-to-write code:

• zm_cron
• zm_token
• a generic product association service that delegates to installed association plugins
• a rewrite of ZMOffers as service, plus the ability to plug-in alternative/additional discount calculations; this would be on product level and work as alternative to order total discounts that operate on cart/order level

The motivation to add the cron and token service to core is that they are way to valuable to be optional. Also, I found that in particular the cron job is already referenced from enough other plugins to justify the move.

If there are other services that would be useful I’d be happy to hear about that (preferrably with some sort of justification).

I think I’ve complained before about the pain of creating a file release on sourceforge. While I can understand the motivation behind the design, it’s still a big pain, especially updating the processor and file type for each plugin!

So, today I finally spend some time puttng together a small greasemonkey script to make life easier. it’s still a but crude, but works well enough for my purposes.
What it does is the following:

1. Iterate over all select elements and pick the ones named processor_id and type_id,
2. if not already selected select ‘Platform independent‘ and ‘.zip‘,
3. if the dropdown was modified also modify the table row (set background to some red),
4. and also add a target to the form to allow submitting forms to a new tab to avoid having to reload the page for each submit

Admittedly, that’s all rather specific for my needs but on the off-chance that someone might find it useful – here it is.