As part of my recent work on the new shipping provider service class and Ajax shipping estimator I’ve started looking at implementing checkout_shipping via a ZenMagick controller.

Now, looking at the corresponding zencart code there is some ugly hardcoded reference to the free shipping order total module. While I am really all for free shipping I wonder why this has to be.

I’ve got a couple questions and it would be great if anyone out there could give me some answers..

• Why is free shipping an order total module and not a shipping module?
  I can see that there is perhaps need to have a ‘Free Shipping’ order total line. However, they way this is done seems a bit confusing. In particular since the free shipping ot code reverts a potentially already subtracted shipping cost from the cart/order total.
• Is there any reason why the ot free shipping couldn’t be implemented as shipping module, perhaps with an ot module to add the “Free Shipping” line?
• To avoid hardcoding any specific modules in the controller I’d propose a new method for shipping modules (perhaps others too) that tells the controller to force picking the respective module if all preconditions are met.

Having a configurable way to enforce using a particular module might be interesting for other modules too. For example, certain cart conditions could require to auto-select a particular payment method, etc.

Comments, suggestions most welcome

A few days ago one of my clients was asking about missing search stats. I wasn’t even aware that something like that existed, so I had a look. It seems one of the more popular mods is the Search Log mod.

Since 0.9.5, ZenMagick uses its own search implementation. Beside the fact that this allows to do things differently, it also makes it easy to change the search logic.

It also means that the event that zen cart fires on each search is not fired any more. So I’ve added a new search event (checked in on HEAD).

Since I still haven’t found a WP plugin for source code formatting that I like, I’ll post the code somewhere else.

There isn’t really much to report for the last seven days. Not just that motivation has been a bit low (I really needed some sort of break, though), there was also some lack of opportunity to work much on ZenMagick (that, of course, suited my rather well!).

Things have changed today and with being recharged and all I’ve actually managed to finally, after a long, long brek, get the new shipping provider/method code working. As an additional bonus there is now a second ajax demo page in the demo theme. Right now all it contains is the Ajax’ed version of the shipping estimator, but in the long run it will hopefully include demos for all aspects of the checkout process.

Having said all that, there have been bits and pieces. Not all worth mentioning, but some might be of wider interest:

• Fixed a bug that would break admin if all file patches were uninstalled. This is related to the fact that for admin the load order in zencart is slightly different
• Added a new theme to trunk. It’s not implemented at all, but it’s pretty high on my list (my lists are generally very wide, though…)
• upgraded the unfinished product tags plugin – a bit more code in the service class and some simple UI to manage tags and it will be ready to go

With the number of sites using Ajax growing it might be a good time to review some of the Ajax code in ZenMagick.

In particular I’d like to review the returned JSON structures. Right now, all of the demo code just assumes that the data returned is good, as long as there is a successful response. Obviously, that is not always the case.

So, I think it would be good to have some global structure that allows for things like a overall status flag, 1-n messages, plus the actual data (if any).

I do not know if there are established patterns for things like this, but if so I’d like to hear about those – obviously, all other suggestions are welcome too!

I realized only yesterday that I completely missed last weeks update. So, I guess I should have twice as much to write this week

However, things have slowed down a bit, so there isn’t really that much to report this time.

• Meta Tags
  Added support for product meta tags – this was overdue, I think
• Category display
  Fixed a bug that would allow to display disabled categories
• Added code to allow plugins to add to the extras menu
• music product_info
  Upgraded and improved. The plugin now includes code to add/drop the extra menu entries. This means without the plugin installed the extra menu is hidden!
  Also, added SQL to create/drop the relevant database tables. The only thing left are the actual admin pages which still ship with zencart.
• hoverbox3
  Upgraded
• fualSlimbox
  Upgraded
• admin
  Started working in getting the admin MVC code working properly. Right now there are still a few unsolved issues regarding code sharing with storefront. I have, however, already added code to access the admin user. Also, group/role support has been added to the already existing code. The authorisation code doesn’t handle that yet, though.
• Last, but not least, I’ve added the option to configure additional url mappings via theme.yaml!

Having just read the (very) last post on Joel on Software I decided to follow Joels advice to talk about more than just my *product*. I do that occasionally anyway and every time I am surprised how many hits posts unrelated to ZenMagick (but related to programming) actually get.

But today to something completely different: Chess. If you’ve browsed this site you might have found to Greasemonkey scripts that I’ve written that implement some sort of a practice board for online correspondence chess. I do play Correspondence Chess on two sites: chessworld.net and atlanticgames.net.

When I started, both sites where about even with features, perhaps with a slight advantage to chessworld.net. Now things have evolved a bit and chessworld.net is clearly richer in both game quality (ie. stronger opponents) and features. [Not that I need particularly strong opponents!]

One of my favourite thing, though, is to watch KingsCrusher, the guy running chessworld.net, play and comment! 5 minute chess.

If you don’t know what 5 minute Chess is, it’s Chess with a clock where each player has 5 minutes for all his moves. Together with his mostly insightful comments, watching KingsCrusher play International and even Grand Masters is a lot of fun, so if you want to improve your blitz and bullet chess, you should really try this.

With my current investigation of using the ZenMagick MVC framework for admin pages I’ve finally hit the point where sharing all code (and configuration) hits a wall.

For example, url and sacs mappings have to be different, so there is no point loading the storefront mappings in admin (and vice versa).

Also, there is reason to have separate implementations of some classes. For example the current ZMController class uses $request->getAccount() to validate access. However, for admin requests this doesn’t make sense as there will never be an account instance, but an admin user reference.
The consequence is that a few more things need to be refactored to make the MVC code even more generic. It also means that it is now time to reorganize everything under the lib directory into shared and individual code for storefront and admin.

All this, or course, implies that storefront and admin stay within a single application – more to think about…

One feature requested for integration with ZenMagick is the admin profiles mod.

I think it is a really useful thing to have, in particular if the project is going to target not just one-man shops.

Since the admin UI will be based on the ZenMagick MVC code, I would suggest that access control is integrated there. Of the top of my head this is the list of requirements to get this implemented:

• display/hide top level menus according to groups/roles
• disable all pages unless explicitely enabled for group/role
• assign admin user to role/group
• implement using ZMSacsManager

So, I think the requirements are pretty much the same as for the existing mod. There would be one improvement, though: It will be possible to set up roles. Roles are a group of predefined permissions. Then a user can be assigned to one (or more) roles and automatically have the permissions of those roles. Permissions would be or’ed, so if one role gives permission to a particular page while the other doesn’t, then permission is granted.

Additional suggestions/improvements welcome…

I’ve been slowly preparing things for a new admin UI for all ZenMagick admin pages. The biggest step has been to remove all individual admin pages (zmInstallation.php, etc) in favour of a single point of entry zmIndex.php.

Within that file, the main_page parameter is used to dispatch the request. Right now this is done manually and the layout is included in zmIndex.php. Views itself are already working the same as in storefront, so there is a content/views subdirectory containing views for all ZenMagick admin pages.

Now, to get to state where zmIndex.php becomes the sibling of zenmagick/store.php, only two things need to happen:

1. A default_layout.php file needs to be added to admin/content
2. zmIndex.php needs to be changed to call ZMDispatcher::dispatch($request);

Right now this does work with one major exception: the included zencart header.php relies on globals (as does the whole init process).

I do hope that for the new admin UI the header will not have to contain a lot of code. All the stuff currently displayed above the navigation should move into the dashboard to make things more consistent. It would also be nice to have a dynamic dashboad where things can be moved around and enabled/disabled.

For example, the update check should be just another option in the dashboard. That would also mean that automatic checks will only happen on the index page and not on other pages. Furthermore, that should be doe via ajax to avoid delays loading one of the central pages.

Once we are that point, I’d really like to get the login process upgraded. Not only would that avoid some of the current code mess, but it would also allow to redirect after the login, just like the storefront does.

We’ll see…

Since I started using git (and github), i’ve struggled with the fact there wasn’t a single client that could matchexisting svn or hg clients.

I tried TortoiseGit – hoping that it would be up to par with TortoiseSVN, but that was not the case (I thingk that would have been somewhere around version 1.2.??).
So, I ended up using mysysgit like most of the other windows users, looking at the number of posts about that particular topic.

Then, recently I thought it might be interesting to see how TortoiseGit has improved. And I was impressed. Pretty much everything (at least the stuff I use) seems to be working. However, there still was the issue with using ssh. I didn’t really have the patience to get to the bottom right away, so ended up using TortoiseGit locally and mysysgit (bash) to push and pull.

Today I did some more research and while there is lots of stuff about how to download putty et al, there isn’t really a lot about TortoiseGit. Then, there is also the issue that the default is plink instead of openssl, which means different keystore structure etc.

Eventually, I figured I  should perhaps look at the help – and lo and behold – there it was. All I needed was:

1. To use puttygen.exe (comes with TortoiseGit) to convert my openssl private key to a .ppk file
2. Configure the remote with the newly created .ppk file

And now there isn’t a single reason to use anything else! After using TortoiseSVN for so long I feels instantly at home. Beside the push and pull I can use it pretty much the same like SVN. It’s perhaps not that simple, but it makes migrating from SVN to git a lot less painful.