One of the things I was looking really forward is currently happening: the ZenMagick admin pages are morphing into a real separate application on top of the ZenMagick MVC code.

Most of the code is shared with the storefront project, which, in turn, is becoming more and more of a real application too!

However, the real difference is that now the admin pages work without zen-cart’s application_top.php! In fact, the only zen-cart files used are (in that order): configure.php, filenames.php and database_tables.php.

I have to admin that this is one of the best things I’ve done within the ZenMagick project for a long long time. It’s great to see all the different pieces suddenly working together, exactly the way it has been planned all along.
Of course, not everything worked out-of-the-box, but expecting that would have been just a bit too much.

Along the way there have been numerous improvements to the MVC code itself, in particular to the areas that haven’t had any real usage so far. And all the things customizable worked like a treat, so while most code is shared between admin and storefront, the things that make each unique have unique implementations.

I am not saying all is done, but looking at my tracking page for this job there isn’t a lot left either and all the fundamental issues have been address as far as I can see.

Some of the more fun bits included:

• Implement a db session handler compatible with the current zencart admin code
• An authorization handler that supports roles (this does work, however there isn’t any infrastructure (read: table) or UI to manage that)
• Getting the session code to work for real
• Finding out how much zencart code is actually still used deep within the codebase (at least for the admin side)
• Seeing that a (practically) independent app can make use of the ZenMagick API
• Implement things that were still missing in the MVC code. Some could have been done earlier, but without a real use case it’s hard to get that done and to get it right at the same time.

One of the things I might have to do now, though, is to go through all sources and come up with some better package names that reflect the new order. Also, I might re-think the idea of splitting off the MVC code into a separate project. Perhaps it’s not worth it, but it is really independent code, so it might be worthwhile.

Stay tuned…

Last night ZenMagick 0.9.9 was released. It took me a while, but I am pleased with the result. As usual, the actual release process was the most painful step! I don’t know – somehow these admin tasks do not appeal to me

I think changes to theme files have been reasonable and there is a good chance that this is going to be less and less with each coming release.

The changes to the MVC code make up most of the release. I think it’s been like this for a few releases now. Just as well that this time a couple new plugins have found their way into the release.
The productGroupPricing plugin is perhaps the biggest news. It allows to configure individual prices for each product and each customer group. Since prices can be either discounts (absolute or percent) or absolute prices, its possible to use this to implement price tables, based on user group. Furthermore, each price/discount can have a start/end date and may also be excluded from being used for other discounts.

The other plugin is the productTags plugin. It allows to tag products. Effectively, this may be just used for a tag cloud or, perhaps more interesting, to create relationships between products.
It is possible to query products for given tags or all products that share tags with a given start product.

With the work on a new default theme somewhat stalled, work on the next release will focus a lot on admin improvements. However, there is also a lot of other interesting stuff in store, so worthwhile to keep an eye on the development and this blog
If yo feel there is anything important missing from the roadmap/feature list, let me know.

In preparation for the upcoming ZenMagick 0.9.9 release I’ve updated and added wiki pages for all plugins available for at this time.

The content is very basic, so if you find anything you think should be added, please do not hesitate.

Testing is pretty much complete, which means the main blocker is currently to find the time to put everything together and ship. I still plan to release sometime this week, so check back later.

In ZenMagick there is a setting named ‘isTaxInclusive‘. Its boolean value follows the Zen Cart setting ‘Display Prices with Tax’ in the My Store configuration section.

Now, this is working correctly, however I am not quite sure (any more) if the name of the setting is correct and the description of the Zen Cart config option is not really clear, IMHO:

“Display prices with tax included (true) or add the tax at the end (false)”

So, with a value of true, tax is added on top of the configured product price. Ok, perhaps it is clear and the displayed price is now tax inclusive. Hmm.

I think the issue here is that the ZenMagick setting is from the POW of the product price while the Zen Cart setting is from the POW of displaying the price. I guess it will be clearer if there is the basic assumption that product prices are always excl. tax, no matter whether they are displayed with tax added on top or not.

So, I guess the solution to the current ambiguity is to rename the setting (its used only in two places anyway..). I’ll take suggestions, but for now I think ‘showPricesTaxIncluded’ is as good as anything.

EDIT: After digging a bit more it appears there are some more issues around this setting.

1. ZMTaxRate is looking at it and only applies tax if set. This is not really transparent and, in fact, possibly wrong, because the same code is used to calculate tax for shipping.
   ZMTaxRate is definitely not the place where this decision should be taken, so that will have to change.
2. Pretty much all calls to the tax rate calculation have include/exclude tax as parameter somewhere further up the call stack. In the majority of cases the default of true is used, thus leaving the decision about tax adding to the setting (in ZMTaxRate).
   It would be a lot cleaner and easier to grasp if the setting either is limited to templates or at least moves further up into business logic rather than the current lower level API code.

Definitely something to change for 0.9.10. With the proposed changes the name of the setting would also be closer to the truth than it is now…

For the sake of an exercise I’ve started installing IIS (5.1) and PHP 5.3.2 (fastcgi) to see if ZenMagick, and in particular the MVC code, will run without problems.

So far I’ve done the following (pretty much following these instructions):

1. Installed IIS (on XP Professional – I know it’s old but it works for me…)
2. Downloaded PHP5.3.2 nts VC6 (zip file)
3. Downloaded and installed fastcgi 1.5
4. Failed to be able to configure fastcgi using the scriped approach, so did some bits manually (registering fastcgi as handler for .php)
5. Added a new virtual folder in IIS Admin pointing to my local ZenMagick installation
6. Configure PHP to use a custom logfile to be able to see errors :/
7. Run the Permission Wizard on the created virtual directory (right click -> All Tasks -> Permission Wizard) and configure permissions for a public access website
8. Re-enable Default Documents and add index.php to the list

Right now I am at a point where things start to load, but Savant is unable to find the template file – I guess some of the code in ZMRequest that controls the various paths is not working in IIS, but I’ll have to debug that first.
I’ll update this list once I have found out more…

UPDATE:
So far I’ve found one compatibility issue and one regression! The regression was using ZMLangTools instead of ZMLangUtils, so that was easy to fix. The other issue was that in IIS $_SERVER['REQUEST_URI'] is not what Apache thinks it should be :/

UPDATE2:
I’ve also installed a self signed cert to test SSL. This is pretty simple:

1. Download and install the IIS 6.0 Resource Kit
2. Open the SelfSSL shell and run something like: ‘selfssl.exe /N:CN=ZenMagick /V:365′

UPDATE3:
Next on my list, but not yet done is enabling some sort of URL rewriting to allow to use some of the seo stuff. This mod looks quite promising…

I’ve created an experimental plugin to play around with PHP Rules this week. It’s small, nice and easy to use. In fact, since its rule class can be configured using setter methods, it would be easy to write simple wrapper classes that translate ecommerce related rules. Examples could be promotional rules like ‘is product xyz in the cart’.

OTOH, once you’ve written that much code to convert the rule ‘is xyz in the cart’ into a boolean value, it becomes trivial to add some and/or logic to tie this up with other ‘rules’ and evaluate that.

Now, it might be possible to leave a lot of the evaluation part to PHP Rules, but then I am not so sure about performance (not so much because of the PHP Rules code, but just because it unnecessarily increases the complexity of the ‘rule’ to evaluate).

Either way, this is probably the kick off for a new plugin to allow to set up and apply promotions based on rules, conditions and such. Still some way to go, though.

Another busy week  and a lot of good stuff.

• Regressions
  There have been heaps of regression fixes last week. A lot of those I found thanks to automatic tests, but also by following my release plan and the (basic) testing.
  • getallheaders() does not work in a CGI env.
• Rearranged files within lib/store to follow the expected MVC folder layout
• Set ZMDefaultSeoRewriter as default default seo rewriter
• Dropped Runtime::finish and replaced with call to $request->closeSession()
• Added decode() method to ZMSeoRewriter and implement
• Added ZMConfig::loadAll() – this can be used to load (and define) all database config options (just like zencart)
• Shuffle plugin related contents/resources around
• Changed the installation sidebox dummy patch to create dummies for **all** themes and **installed** plugins
• Allow sideboxes in plugins (under [plugin]/content/boxes); this required to drop the code that checks that the file exists – this moves the check into the tempate/layout
• remove obsolete ZMBoxPlugin class
• Move generic code from ZMToolboxNet and ZMToolboxHtml to utils classes and move those classes into store
• Upgrade googleAdSense and whoIsOnline plugins
• Removed zm_dual_pricing plugin as that is replaced with the improved productGroupPricing plugin
• Removed rss.in.php and rss.php boxes from the default theme
• Added rss.php as box to the demo theme
• pageStats: display total number of included/required files
• Cleaned up the override scripts; one actually is now obsolete, so needs to be deleted during upgrade (includes/init_includes/overrides/init_languages.php)
• useo2: replaced all code that uses references
• Added code to actually call the decode() method of seo rewriters
• Implemented path style url rewriting in the default seo rewriter class; example: index.php/products_info/products_id/14 instead of index.php?main_page=products_info&products_id=14

The great thing about the last item on the list is that this works transparently, so as far as server side code like controller, etc. are concerned, things are just the same.
I plan to add another mode that also drops the index.php. However, that will require at least a single redirect in a .htaccess file, just like most SEO plugins. However, a single rule will be enough, so extending the scheme will not require to upgrade .htacess and will keep things as simple as possible.
The only downside is that it moves logic from the webserver (processing the .htaccess rules) to PHP code. OTOH, that code is simple enough to not really add much load to request processing.

Seeing that I am close to releasing ZenMagick 0.9.9, it seemed like a good idea to have a quick look at  Zen Cart 1.3.9 (BETA).

Since there are no real changes to the structure, ZenMagick does work without any problems after a Zen Cart upgrade (although, I did a fresh install). So, after upgrading, all you need to to is re-run the ZenMagick file patches (via admin: ZenMagick -> Installation or admin: Tools -> ZenMagick Installation).

The only issue I had so far is related to my dev environment (I think). It might be more common, though. Loading the initial SQL during installation fails with an SQL error: “1366 Incorrect string value: ‘\xA3:&eur…’ for column ‘configuration_value’ at row 1”

Other than that, upgrading stores using ZenMagick will be just the same as upgrading a pure Zen Cart installation.

Seeing that the code is still labelled BETA,  I would expect that the full version of ZenMagick 0.9.9 will be still based on Zen Cart 1.3.8a. A one week public beta as announced by Zen Cart does seem a bit short, though…

Well, it’s been some active very busy days (and nights) and I’ve made some serious progress with a few things that were burning under my nails.

I’ve cleaned up the toolbox tools a bit more and now only the store is actually using tools – the mvc package, while still providing the toolbox infrastructure, does not rely on it any more.

I’ve also implemented the changes to the location of templates/resources in plugins and all the necessary changes elsewhere (that was actually more than expected).
As a bonus this meant it was finally possible to convert/upgrade some of the sidebox plugins. The nice thing is that they now are regular plugins just like any other one.

Finally, I’ve started writing the release notes. I think this release will see the longest list of notes for quite some time.

I would expect the release to be ready in the next 2-3 weeks pending on testing and other preparations.

There is one thing I’ like to get done before that, though, and that is fully grasp and handle admin MVC code. It doesn’t sound too exciting, however it is the foundation for the new admin UI and without that a lot of the admin work to come will be just patchwork – like it is now…

Right now plugins can and do include template files. Mostly those files are views, sometimes storefront related, most often admin views.

For a while now I’ve been postponing to update some of the remaining currently defunct plugins to the new plugin conventions and mostly because they include sideboxes.

The old plugins would create/copy sidebox files into the default theme during the installation process. This is not very nice on a number of levels. It’s error prone (file permissions), not intuitive and generally something I never liked at all

With the enhanced support for storefront views and resources in plugins it might be time to rethink the location of views within the plugin. Right now all there is is stored in a subfolder named ‘views‘. So, in order to keep plugin folders tidy, it would make sense to have a content folder, just like themes. That way all resources, views, sideboxes, etc. would be tucked away and not interfere with the actual plugin code.

Now, if you go that far, you might ask:  Why stop here? Add support for themes! Well, then things get a bit more complicated. In particular since the id of the default theme is configurable, it’s hard to anticipate that.

Of course, it would be possible to declare ‘default’ the name of the folder associated with the configured default theme, but then things, again, become less intuitive (although ‘default’ really really is a great clue!).

So, I think I’ll change the code to expect templates and resources relative to a ‘content’ folder within a plugin. That would mean existing views folder would move one level down to ‘content/views’.

If theme specific customization is required, it is still better to copy the files into your theme and customize them there. Files in plugins should never need to be modified.

Coming back to plugins that contain sideboxes. Since the (to be) content folder is automatically included in the template file lookup [via ->fetch(...)], there is no need to copy any more. To make those sideboxes show up in the admin page, the sidebox dummy patch can easily be modified to scan plugins too.