Seeing that ZenMagick is stuck with sitting on top of Zen Cart for a bit longer [unless I find someone to rewrite all shipping and payment modules for me ] it might be worth spending a bit of time on a new concept for getting around some of the limitations of having all configuration options as defines.

Defines, for those that are not in the know, are somewhat like global constants – once they are created they don’t go away and they definitely can’t be changed. Well, you say, that’s good. Isn’t that what configuration options should be?

I guess the answer is not that straightforward. It seems like a great idea – until you get a project that depends on making one changeable. And then another one. And another one.

So, coming back to the title of this post, multi site is a zencart mod/ZenMagick plugin that allows to use different domains (so potentially different stores) with a single ZenMagick installation. The main issue is that this requires to change some unchangeable settings on-the-fly, depending on the hostname used (mostly).

Right now the mod does this by utilising zencart’s build in support for loading custom settings. There, without changing core files it is possible to create defines based on request data before zencart does. So far this is a fairly custom process that involves having write access to folders and files during installation and generally is quite fragile.
Another issue is that at that point of execution, none of ZenMagick is loaded yet. This makes coding a bit of a pain.

So, I wonder if it would be possible to change all of that by moving the ZenMagick bootstrap code into the optional local/configure.php. To be clear, not all of it, just a single line to load the basics. Sounds great? Uhm, but what about database access? Yeah, true, what about that?

Well, the idea would be to get ZenMagick up to a point where the only things required from the main configure.php are database access details. Those could easily be extracted from the file without loading it and then all other configuration would be available from the database.

From an UI point of view this could mean to have a site/store management page where a new store can be set up and any of the existing configuration options could be set for each store. It could also mean that a lot more zencart code could be not loaded at all and thus saving more processing time. I know it sounds a bit crazy but from a purely coding point of view it seems doable.

After almost 9 years I am today leaving my current job at the Noel Leeming Group. It’s been a good time and something that took me a long time to decide. I’ve met a bunch of great people there and I sure will miss them.

NLG has been a great place to work at and the support when the kids were born was phenomenal.

Now I am looking forward to starting at SLI. It will be a different style, different work but still a lot of people I know from my first job in New Zealand.

Work will still be mostly Java, but this time with some official bis of PHP on top, so just what I want. Not sure how that is going to affect ZenMagick, but development might slow down for a while…

I’ve got some requirements for a potential new project. It’s a multi store setup and while that in itself is ok (although the multiSite plugin is currently still defunct) there is one more requirement: multiple catalogs.

More precisely, one store is intended to have only a subset (subtree) of the full catalog.

Now, I know that zencart does have the option to set an effective root category for the category tree displayed, but that is currently not possible in ZenMagick. Also, this is display only AFAICT.
Now, if this project goes ahead I’d be keen to consider implementing proper multi catalog support incl. separate product mappings for each catalog. (Here catalog means category tree).

I am sure that has been done before, so it would be nice to not having to re-invent the wheel from scratch. Any pointers, ideas?

I’ve uploaded a new snapshot – the first 0.9.9+ that includes the current state of affairs of the new admin UI.

Details can be found in this forum post.

In addition it is worth noting that the the mailer code currently only works with SMTP. Others to come – how important are the other options actually?

Tonight I checked in some changes that allow to configure one or more filters for Savant. Just for the fun of it I also added a PHP short tag filter that allows to use short tags even if they are disabled in the PHP installation.

I guess there isn’t that much to report for last week – looking at the changelog, that is. Most of my activities were around the new admin UI. That included re-creating some of the things that already exist in the storefront code, just a little bit more generic. In the medium term those changes will replace some specialized storefront code too.

So what is to report?

• PHP packer
  The new code is now in use and working great. It closes a few gaps the old code had. In particular the new analyzer class will correctly handle multiple interfaces, multiple classes/interfaces per file and generally is more entered around PHP structures that files.
• PHPMailer
  I now have a working PHPMailer class that is just a wrapper around SwiftMailer. Should there ever be support for more than one mailer things might have to change slightly, but not too much.
• Fixes
  I fixed a couple issues around method level authorization in Ajax calls. Nothing to worry right now, but it is good to have that sorted.
• Upgrades
  I’ve upgraded the includes Cache_Lite class and also upgraded the unit tests plugin to using a trunk snapshot of the upcoming simpletest 1.1 release.
• Admin UI
  • Fixed the sesison timeout bug in the session handler
  • Added some fancy jquery dialog to handle plugin options
  • Added a few more views like ‘orders’, ‘order’, accounts’, ‘account’ (those are display only, though)
  • Added view to change user settings (name, email, password)
  • Got the reset password form working, incl. sending of email (although no email view yet)

So, all in all the new admin UI has expanded quite a bit even though there are still huge gaps. Still, great progress and a lot of fun to be able to just use the MVC code without having to invent everything again

UPDATE: One side effect of moving the admin files underneath the zenmagick folder is that it reduces the number of files in the zencart filre structure to 7! Once the new admin UI includes all existing ZenMagick admin functions this could be further reduced…

With the final shuffling of code and splitting up into shared, storefront and admin code I need/want to reorganize all phpdoc package names.

I think for lib/core and lib/mvc I will leave the current org.zenmagick.core and org.zenmagick.mvc packages as that is what they are.

For the actual application code I currently plan to use something shorter like:

• zenmagick.store.core
  The shared code
• zenmagick.store.sf
  Storefront specific code (located under zenmagick/apps/store/lib)
• zenmagick.store.admin
  Admin specific stuff (localted under zenmagick/apps/admin/lib)

BTW: I did some testing with the new admin code and renaming the admin folder works as-is, so no further changes needed. This for all the folks that feel renaming the admin folder makes things more safe.

Another side effect of the restructuring is that it allows to copy the app/store folder and have multiple stores running on the same codebase with just the store specific stuff different, although there might be a few more things to do before that works properly…

The above changes also mean there will be most likely two separate apidocs packages. One for the actual core/mvc code and one for the store application (strorefront/admin) code.

I’ve had quite a bit of fun with the latest version of jquery and the jquery UI widgets. Slowly things are coming together, so after the fold there is a screenshot of the current state of the improved Plugin Manager.

(more…)

To keep the number of files low I started compressing quite early on to compress used 3rd party libraries into a single file.

This is true for all libraries that are bigger than a couple files. The additional benefit is that it makes it easy to include those libraries into the core.php file that can be created from a working installation. That single file then includes all used files except for theme stuff like templates, etc.

So far compression was handled by individual PHP scripts that would break every time I moved code around. Despite the fact that those libraries are pretty stable and rarely change its still not a very desirable situation.

To remedy that I’ve started converting the scripts into separate classes that implement a small interface (one method). A single (stable) PHP script now knows how to load and execute those classes. And even better its all possible using Ant and the existing build script environment!

So far I’ve converted the Savant3 script and also added one for SwiftMailer. In fact, that was the test candidate.

An additional bonus is that a single Ant property now controls whether the code in the created single file is compressed (stripped, actually) or not. That makes it quite easy to switch to a non compressed version to debug.

But best of all, there is now a reliable method to re-create programmatically generated code.

ZenMagick has, for a long time, included creole, a PHP database layer. It was the first proper implementation of the ZMDatabase interface.

Now, seeing that is has been dead for about 4 years and I do not know anyone actively using it I wonder if it is time to remove it from  ZenMagick.

For the generic code this means the only database layer left is based on PDO. Now I do not know how common PDO is with ISPs, so I wonder if just relying on PDO is enough?

If there is information about that it would be great to know…