Last week I looked at an issue regarding the PayPal Express payment module in one of my clients websites.

The issue at has seems to be quite popular common, in that the user is returned back to the store’s payment page and an error message that the provided address does not match the address associated with the credit card (that backs the paypal account used to pay).

While, according to the zen cart developers, this appears to be the intended behaviour, there is a funny side effect – each unsucessful payment resulted in a new empty entry in the users address book! Not sure what’s going on here, but my guess is that the module attempts to create an address with data coming back from paypal or something, but that doesn’t seem very logical to me, considering that matching addresses are part of the ‘security‘ checks PayPal performs…

Either way, my client most likely is not going to use PayPal Express at this stage…

Time is flying and lots of things are happening.

Last week I did some major restructuring of the layout of the github repository. The main reason for this is a very pesky developer that needed this to allow his own code to work with ZenMagick. OTOH this is something I meant to be doing anyway at some stage. Eventually, one day, the zenmagick folder will be the docroot (or even the apps/xxx/web folder as already possible for admin), so we are already prepared for that

This moving around of folders caused a bit of work on the build scripts, but by now I an reasonably sure that all is working again.

I’ve had the pleasure of messing around and helping to debug a few new installations and as the result there are a number of bug fixes and improvements that will be available in the next release (of course!). There should also a new snapshot be available sometime this week, for all to enjoy.

So, what else is new?

• Fixed the last known issue in the new shipping providers code. This means the new shipping providers service and the new wrapper class around zencart shipping modules is now active in a default setup. I have done testing with all default shipping modules, it would be great if more could be tested…
• The PDO ZMDatabase implementation is now the default. Additional code changes mean that it is now possible to reliably change this from the global local.php file.
• ZMFormData has been stripped of a lot of code, so adding custom fields to forms using a ZMFormData based form container should now be good as-is.
• theme.yaml now allows to configure theme settings, so if all you need are settings, but not code, there is no need for a theme local.php any more.
• login/logoff redirects have been improved. In particular the login redirect will return you to the page you came from, and the same for logoff (unless you were on a protected page, of course).
  Logging in to checkout will return you to the shopping cart, hopefully this will help conversions a bit.

Just a quick heads up to say that  I moved lots of stuff around in the git repository. The content of the zenmagick folder moved into the root folder and the folder itself was removed.

That means that if you have checked out ZenMagick directly into your zencart installation, you’ll need to change that. The best way (for dev) is perhaps to completely remove the checked out old code (.git, etc, zenmagick) and checkout into a zenmagick folder.

Of course, you might need to backup your custom changes / theme code and copy that back into the newly checked out folder.

There has been some other moving around too, but nothing that anyone except me should need to worry about.

Due to the move all ant stuff moved into the zenmagick folder too, so it needs to be run from there.

With the worst of the earthquake hopefully behind us, work on ZenMagick is slowly picking up again.

As usual, a lot of the work is driven by demand. One of the best things I’ve done in quite a while was to rewrite the payments service. Not only does it now work everywhere, it also:

• does not depend on zencart code or globals any more
• introduces a new wrapper class for zencart payment modules that should make migrating to some new checkout code a lot easier

Apart from that there have been a few teething issues with the new admin code and also emails. I thought I had that sorted – obviously, as otherwise I wouldn’t have released the code.

However, it looks like there is still some weirdness, so I hope to find some time this weekend to investigate that.

More good news this week related to themes. RubikIntegration have kindly donated a new theme, re-implementing the RubikIntegration007 Zen Cart template. It needs a bit more polish, but is starting to looking really nice.

And perhaps even better, there is possibly time for more

This week I looked at an issue with the new admin UI. It took a wee while, but eventually I found that the server, while having PDO installed and enabled, lacked a MySQL POD driver.

The current code does expect PDO to talk to the database and there isn’t really a lot I can do about it (or want to). Still, there is a (non trivial) workaround that takes advantage of the fact that the Zen Cart based ZMDatabase implementation can be used bu the admin UI.

To get to that point requires a few modifications and also means that now the default database code used is the Zen Cart based.

So, as of the next release if you have PDO and want to use it (recommended), please add the following line to the global local.php (you might have to create one):

ZMSettings::set('zenmagick.core.database.provider', 'ZMPdoDatabase');

If you are lazy you can also just rename local.php.in to local.php and start editing…

UPDATE: Looks like the best is to clearly separate the storefront and admin settings, so the above is most likely not going to work in 0.9.11 – stay tuned…

It appears that the full version of ZenMagick 0.9.10 includes zen cart 1.3.8a rather the intended zen cart 1.3.9f.

This is rather embarrassing and I’d like to apologize for this.

I’ve removed the full download package to avoid further people downloading it.

An updated version should be available later today or tomorrow.

It’s been over a week now since the 7.1 earthquake that shook Christchurch. Since then we’ve had more than 500 aftershocks (and counting), some quite strong. Checking right now there have been two 4.1 since I came into the office…

Of course, we haven’t felt all of those – thanks! but enough to keep edgy for most of the time.

This week will hopefully allow most of us to get back to a more normal life. Some schools, kindergardens and playcentre are open again and I am back to work too. I might go home early for a few more days, though. Sitting on the 10th floor still feels not to be the best place to take aftershocks…

The image in the link above is take just a block away from the office. Luckily the quake affected mostly old buildings with no earthquake protection. All the over engineering of buildings has really payed off!

Still, the news are talking about 5000 homes not suitable for living – I guess that gives an indication of how lucky we still are.

Well, due to special circumstances there hasn’t been an update last week and, unsurprisingly, there hasn’t been anything to report either.

Download numberss are slowly growing and so far at least there haven’t been any major issues. Looks like the default url schema for the new admin UI does not work that well with some servers, so I’ll be changing that for the next release.

Should your new admin behave strange or show 404 errors, try editing the file zenmagick/apps/admin/config/defaults.yaml and change the line:
zenmagick.mvc.seo.type: realpath
to:
zenmagick.mvc.seo.type: default
I’ll be doing some more contracting this week with some of that going back into the next release, so things are starting to move again.

There is also renewed interest to contribute and as it happens a new default theme is currently being worked on, so, again, lots to looking forward to.

Lastly, there have been a few issues with new installations, but it is not clear yet if there is a real problem with the code or just different factors coming together.

Ijust ran into an interesting problem where I do not want to expand three consecutive tilde ‘~’ chars to be expanded as user name in mediawiki. Furthermore, those chars where in a code section.

Does anyone know how to suppress signature expansion in mediawiki?

Not sure if you’ve heard about the earthquake in New Zealand on Friday night.

Let me tell you I have and despite the fact that our house is still good and water is back (power hopefully tonight) I’ll be a bit more offline that usual….