I just checked in a couple changes that fire new events in case of a new account being created. The really nice things is now that event listener have a chance of modifying the account directly without having to change a single line of core code (or globals!).

For example, the following code would change the default authentication status for all new accounts:

class Blocker {
public function onZMCreateAccount($args) {
$account = $args['account'];
$account->setAuthorization(ZM_ACCOUNT_AUTHORIZATION_BLOCKED);
}
}

ZMEvents::instance()->attach(new Blocker());

I guess it couldn’t be any easier than that (other than re-defining the default authentication value

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.