So, as usual, upgrading the demo site pciked up two minor issues with the new release.

• The quick edit admin plugin contains a custom field config file that will break the site.
  This is a test file I created and that was not intended to be included in the release. Deleting the file fixes the problem (even though it’s a nice example of how to customize the fields
• The product info view in the demo theme does not display attributes.
  This is a regression caused by the theme changes in this release and all that is missing is to actually echo the attribute HTML.
  Line $53 should look like this: <p><?php echo $option ?></p>

I’ll update this post if I find anything else.

Astute readers might have already found the hint about OpenID in my tasklist. I have been pondering support for OpenID for quite some time, but decided to wait until 0.9.1. is out before diving into it.

Actually, that is not exactly true, as I did spend some time preparing for it. In particular, the code changes to extract the PHP compressor and the new PHP packer were already done with this in mind.

So, I manager to compress and pack the excellent PHP OpenID library by JanRain into a single file. Add some inspiration and code bits from Saeven OpenID and you are almost there

Unfortunately, the plugin will require code changes to ZMAccounts (well, not really changes, but upgrade to using the new ZMDatabase layer). But hopeully the next release will not take as long as the last one.

Note to self: Upgrade website with new API docs for 0.9.1 and also the demo store!

Yes, I finally did it. Quite possible the biggest ZenMagick release ever (and not just the file size!).

In time I will have to update the wiki to reflect the new way to access services and also the template examples.

For now I am just happy that the code is now in the wild so people can start playing around with it and hopefully let me know what they do like and dislike.

Meanwhile, I will try aiming for a 1.0.0 release. There are going to be a few more 0.9.x releases, to be sure, but getting the template changes (well, most) out of the way feels very good.

As always, feedback is very welcome.

I have written before about how I managed to compress Creole into a single file. Now, I have extracted the more generic bits of code into a single utility class. The class has a couple callback methods to cope with custom handling. Actually, I implemented those callbacks exactly the way I needed them to implement the creole specific code, but it should the typical exceptions.

To use this, I added the first CLI script to ZenMagick. I do not expect a lot of user to require to run it, but it makes for a nice example of how to use the class.

For those interested in all the gory details, here is the source of the script:


// load ZenMagick core
$coreDir = dirname(dirname(__FILE__)) . '/core/';
require $coreDir.'ZMLoader.php';
ZMLoader::instance()->addPath($coreDir);
ZMLoader::resolve('ZMObject');
ZMLoader::resolve('ZMPhpPackagePacker');

/**
* Custom class for Creole specific dependency handling.
*/
class CreolePacker extends ZMPhpPackagePacker {
/**
* {@inheritDoc}
*/
public function isResolved($class, $level, $files) {
// Record does have circular references
return (’Record’ == $class && 1 == $level);
}

/**
* {@inheritDoc}
*/
public function finalizeDependencies($dependencies, $files) {
// there is no explicit include/require for this
$dependencies['DebugConnection'][] = ‘Connection’;
return $dependencies;
}
}

// pack; ideally path/version should be CLI args…
$creoleVersion = ‘creole-1.1.0′;
$packer = new CreolePacker(’c:/temp/’.$creoleVersion.’/classes/’, ‘c:/temp/’.$creoleVersion.’.packed.php’);
$packer->setDebug(false);
$packer->packFiles();

The script extends the generic package packer class to implement custom callbacks. Creole is actually a quite easy to analyze, as almost all (except for one Connection) dependencies are covered by include and require statements.

So, executing the scirpt will result in the new file creole-1.1.0.pack.php which is about 187kb large and, at least for the default drivers, makes the custom class loading in Creole obsolete.

long term I hope to be able to extract the generic MVC code out of ZenMagick and compress is using the some similar code. This will require some more work, though, as the current class does not look at extends and implements of classes. Since all code depends on the loader, rather than import/require, analyzing those will be required in order to build a proper dependency map.

Should anyone use this for their own project, then it would be great to let me know.

In my last post I started a list of things to do before the magic 1.0.0 release. I’d like to keep this post as a reference for things to do. Hopefully, I’ll be adding (and removing!) things often as I go.

Of course, suggestions are highly welcome…

• admin - maintenance
• facets
• other plugins
• make ZMPluginView more useful and start using it (this will require changes to a few plugins that do funny things like loading files and eval’ing them…)
• review email templates and integration (plus perhaps a new email service?)
• review the remaining template functions (l10n, i18n)
• alternative shipping/payment/order total modules
  NOTE: This is actually not to replace or reimplement any existing code. However, should plugins wish to implement new modules, that should be possible without relying on globals (in particular as those might not be available using ZenMagick in the first place)
• review the security code - for one thing it’s not possible to have multiple authentication sources (one alternative could probably be OpenID)
• Review and perhaps improve the price/attribute lookup code (reduce database queries)
• Convert all code to using the new ZMDatabase API (this has evolved quite a bit since 0.9.1)
• Review all code that creates files with a focus on file permissions
• Review and either justify or change the use of model classes to populate forms

Also, there are some things that are beyond 1.0.0, but nevertheless worth writing down:

• Start using the alternative bootstrap code (alpha at most at the moment) for all non checkout pages to further reduce the init code
• Redo session handling to start sessions only when really needed (any form of login, cart action, language change, etc)
• Complete template review - refactor some of the view classes, access views and (side-)boxes (and others) via the same view access code. That should allow more fine grained caching. A possible implementation could have a PageView to access the full page and FragmentViews to access smaller bits like boxes, views, etc. However, rather than re-inventing even more wheels it might be more effective to improve the Smarty plugin and probably complete the smarty default theme.
• Have some more themes

Right!
After spending quite some time on fixing regressions from my refactoring madness its finally time to get ready for the next release.

Rather than reiterating the things that have been changed/added/fixed/improved I’d like to talk a bit about what is coming next. I am aware that I never much of a roadmap for ZenMagick. One of the reasons being that there was just too much to do and I never had real priorities. With the changes coming in 0.9.1 there isn’t a lot left to be done for the templating side of things until we’ll eventually hit ZenMagick 1.0. The API, on the other hand, still requires some work.

While the API is pretty much complete as far as the storefront functionallity is concered, it lacks quite a bit when it comes to the admin side. What I mean is the ability to create and update data. While there has been some work in that area, there is still a lot left. As a general rule, create/update functionallity is available where it was needed.

With the introduction of the new database code I hope to finally get this big gap filled and make ZenMagick even more attractive for integrators and people interested in extending zen-cart.

There is also going to be some more work in refactoring the core code. While this is not strictly necessary, I have the urge to do that just to make myself happy (I hope that is reason enough

Parallel to all that there are plans for a lot more work around plugins:

• admin - maintenance
  There are a few plugins that I started, but never finished. Those would make the Catalog Manager a lot more useful. However, those will most likely depend on the missing data access features of the API (namely, creating and updating date like products, categories and other)
• facets
  This is something I started as a reaction to some discussion about alternative ways to navigate the catalog. Eventually, I hope this will be good enough to replace and improve the current result list/filter code (not sure about the sorter, though). It should be more performant (using some form of caching) and generally smarter.
• other
  There are a couple other plugins I can feel coming. This might include some more support plugins for zen-cart mods, but also some new features for the storefront side of things.

Finally, there is more need to trim the code and make it perform better. I plan to have a look at what other PHP based apps do for that and see what seems useful. Suggestions welcome.

So, again, not much of a real roadmap, but I think that a version 1.0 is finally (far, far) far away becoming visible. If you feel I have missed anything important, please, please comment or write me an email.

Happy weekend, everyone

Right, I am just about to check in some new code that makes will make it very easy to import/prepare Creole for the ZenMagick loader architecture. The new (mostly unused) class ZMPhpCompressor also allows to squezze a full Creole release (everything under classes) into a single 188kb file.

I am actually not sure if I should include that already with the next release, as right now there are probably about 3 or four queries per request done by the new API and I might as well stick with the existing code a bit longer - we’ll see.

The code depends on two other ZenMagick classes, so it’s not very portable (if anyone is interested), but apart from that it works fine

The actual code to do the magic looks like this on my XP box:

$creole = 'creole-1.1.0';
zm_creole_import('C:/TEMP/'.$creole);

$comp = new ZMPhpCompressor();
$comp->setRoot(’C:\Program Files\Apache Group\Apache2\htdocs\zen-cart\zenmagick\core\ext/’.$creole);
$comp->setOut(’C:\Program Files\Apache Group\Apache2\htdocs\zen-cart\zenmagick\core\ext/’.$creole.’.php’);
$comp->setTemp(’C:\Program Files\Apache Group\Apache2\htdocs\zen-cart\tmp’);
$comp->compress();

Not sure how often I’ll be using this, but it’s nice not having to try to remember these things once they are needed again!

The only caveeat is that compressing into a single file breaks the Creole ‘dot-path notation’, so in order to use the MySQL driver you’ll need to do something like:

Creole::registerDriver('mysql', 'MySQLConnection');

to avoid errors about missing drivers. Since all database access in ZenMagick is handled by a single database provider class that’s not really an issue, though.

That means the last open issue is to write some proper release notes - oh, well, babysteps

I’ve been trying to get a release together for quite some time now, but as laid out before, I was unable to resist to add this ‘last new feature’ before releasing.

Due to the massive amount of changes (even though old themes will be good with a handful of small changes) I think I’ll actually have a release candidate before doing a proper one.

There are currently three remaining issues, though:

• Creole
  The script to “import” the Creole code (read: fiddle around to make it work with ZMLoader) is still custom and ideally I’d prefer to have a single compressed creole.php file rather than the single files. This will require splitting the core compressor code into a generic bit and the ZenMagick specific parts. Once that is done I’ll be able to compress individual folder and subtrees just as needed.
• Release notes
  My old nemesis. With the growing number of changes it’s becoming imperative to have some good release notes so people can make an informed decision about whether they want to upgrade or not.
  Also, it should contain enough details to make theme migration an easy task
• Time
  As some of you might have noticed I am not online a lot at the moment. There are some good, personal reasons for that so expect this continue for a while.

If anyone is interested to give the current code a try let me know and I’d be happy to put a custom build together for you (there is also the option of accessing the trunk code directly at sourceforge.)

I feel it is about time for a new release. I have been quite busy and actually I am quite pleased with the results so far.

The work on this release has not been very structured - I think I should perhaps start making plans for new releases and at least try to stick to that.

On the other hand, there have been so many changes and dependencies that it would have been very hard to follow that plan for 0.9.1 to be.

I am now in the final stage of actual changes - thanks to Matt who opened a whooping 21 tracker in on session this has proven to be a bit longer than expected It’s great to get feedback and there are a few really good observasions in those bug reports and feature requests.

The last thing to be added is something called toolbox. The original bug that started this is about inconsistencies in when and how text is HTML encoded/escaped. Another issue that came up a few times lately is the fact that it is not very easy to customize the code in the html and html.defaults packages.

To solve both of these issues there is now the new toolbox. Basically, it allows to register objects (via local.php or similar) that then will be available for all templating code to use.

Most code in core that generates HTML or any other output that is used in templates is now available in two different ways:

1. There is a new variable $_t that can be used to access all registered tools.
2. Tools will also be available via their name (see examples further down)

The toolbox contains 4 build in tools that are going to replace the current set of html (and related) functions:

• html - Everything that actually creates not just text, but actual HTML (single tags only)
• net - All href helper
• form - HTML Form specific tools
• macro - Container for all functions that are currently under html.defaults

The advantage of using classes is that now it is possible to replace existing methods rather than having to copy and rename functions.

For example, rather than writing:

<?php zm_secure_href(FILENAME_LOGIN); ?>

one can use now:

<?php $_t->net->url(FILENAME_LOGIN, '', true) ?>

or:

<?php $net->url(FILENAME_LOGIN, '', true) ?>

Explanation: I have merged zm_href and zm_secure_href into a single url(..) method (same for zm_form and zm_secure_form). That explains the additional two parameter (params and secure/unsecure flag).

It is also possible to register new tools by doing something like:

<?php

$mytool = new Foo(); // or ZMLoader::make(’Foo’);

ZMToolbox::instance()->set('mytool', $mytool );

?>

In templates the object $mytool is now available as $_t->mytool or directly as $mytool.

I also reviewed all converted code with an eye on HTML encoding and improving the documentation. My tests do not show neither loss nor gain in performance, so all should be good.

All existing functions have been marked as deprecated and are converted to using the toolbox. That means even when not upgrading an existing template to use the new variables, the new code will still be used.

Only thing left is to convert the default and demo theme to using the new code, but I think I can do some automated rewriting that should help a bit.

I am (again, again, again) agonizing over ZMCategories.

As part of the database code changes I am reviewing all services and model classes and there is heaps that could be improved (from a coding point of view, most of this work won’t be visible to regular users that just mess with templates).

There are actually two things that make this rather tricky:

• Internal caching
  The current implementation does a lot of internal caching in order to be fast.
• The active flag on categories (via applyPath(..))

Initially caching was not a big issue until I added support for multiple languages. Now that I want to add support to create and update categories (for admin tools) there is a second dimentions: the status. Further complications are that the code builds a tree structure to support the category tree navigation.

The second is actually just something I’d rather implement differently as it depends enirely on the cPath request parameter and that shouldn’t interact with a service.

So, I plan to change two things:

1. The meaning of the method isActive() in ZMCategory will change and be similar to the same method in ZMProduct.
   Active categories are visible in the store, inactive aren’t.
   This should actually not be a big issue as this method is used only in the default categroy rendering method zm_build_category_tree_list().
2. The whole logic currently done by ZMCategories::applyPath() will have to go somewhere else. Again, potentially the only code affected is zm_build_category_tree_list().

Any objections? - let me know…

EDIT: As it turns out,  changes are really confined to zm_build_category_tree_list(). That means unless your theme uses a custom version of zm_build_category_tree_list() there is nothing to fear