I’ve been distracted again by a bug in the static page editor in 0.9.8. After some investigation it became clear that this wasn’t just a small issue, but the editor is, in fact. unusable.

Looking back it is clear that moving to a single point of entry for all ZenMagick admin pages (via zmIndex.php), while being a good idea, has caused all these problems. In short: there is a lot of JavaScript missing.

Looking at the code and all the hacks around WYSIWYG support in zen cart (and the same code in the ZenMagick static page editor) I decided that ZenMagick could do better. So, after a couple days of hacking I present a new and simple API (well, just a matter of three settings) to easily add WYSIWYG support in ZenMagick.

Things are really looking good. I’ve used CKEditor and TinyMCE as two candidates to create editor plugins. It’s always good to verify new things with at least two different implementations as that usually really shows if there are any shortcomings. Each plugin took so far perhaps 3 hours. Most of that time was to figure out how to create the JavaScript required to make things work.

Then, after a suggestion, I added a plugin for xinha. That took about 1 hour

Nothing it perfect, of course, and these plugins are no exceptions. ALthough they are all three usable, there are a few things that could/should be improved:

• Add support for the save button that exists in all toolbars
• Add support for ‘basic’, ‘advanced’ and ‘expert’ level with increasingly blown up toolbars
• Make all work with multiple instances in a single page (I haven’t tested that at all, but at least for xinha its clear that some work will be required to get that working)
• Add an option to each plugin to make it the default editor; right now plaintext is the default and you need to set the default manually

As for the title of this post – I updated the roadmap, so it really isn’t a distration (any more)

I am really excited about a new project to write a vBulletin integration plugin for ZenMagick. I can’t really give any more details, but it looks like it might end up full blown two way syncing of user data and perhaps even single sign on!

I’ll write some more once this there is some progress to talk about…

Doing the dishes is a great time for me to ponder various things. Yesterday I had a couple ideas for new plugins. Nothing too exciting, but prbably worth trying…

1. A redirect/forward plugin
   The idea would be to allow to configure mappings via an UI to be able to redirect/forward default pages that are not needed. One thing in Zen Cart and ZenMagick is that even if a page is not linked anywhere it is still possible to get there if you guess the URL. And once you know it’s a Zen Cart store that is easy enough to do.
   The plugin would allow to redirect to other pages (homepage, error page, etc) for any page that is not needed.
2. A generic surcharge order total plugin
   This would be the first plugin to implement module functionality. I do have some ideas about how that could work, but that will need more investigation.
   The plugin would then add an order total with an additional surcharge if specific conditions apply (right now that would be specific payment modules selected and/or specific credit card types [AMEX, MASTER, etc/]).

Any more ideas and suggestions welcome.

Last night ZenMagick 0.9.5 was finally released! I am quite excited about this particular release, because it includes a couple things that make ZenMagick a lot more attractive to existing Zen Cart installations.

For one thing, there is a new patch that allows plugins to access the final HTML content of Zen Cart templates. This has been around in ZenMagick (for themes) for quite a while and proves to be very powerful.

A lot of the storefront plugins (page stats, page caching, google analytics) depend on this feature and now they can be used with Zen Cart templates too!
If you head over to the demo store you’ll see that the HTML generated by the default Zen Cart template is caches like any other page, following the same rules!

Another quite surprising thing (at least  for me!) is the new PDO based ZMDatabase implementation. It seems to be the fastest implementation so far and the demo store seems to do fine using it, so I might make it the default implementation for the next release.

There are also improvements to existing plugins and, of course, a couple new ones. The most interesting one is probably the phpBB3 plugin. It provides the same features as Zen Cart’s phpBB support, just for phpBB3.

I also really like the new theme toggle plugin that allows to switch between Zen Cart and ZenMagick. Probably not very useful for a production environment, but good to compare features, displayed values, etc.

Of course, this is not the end, and I’ve already started working on the next version. In that context a reminder that with 0.9.6 I’ll be removing a lot of the deprecated stuff. Also, the deprecated API support will be removed before a 1.0.0 release, but most likely not before 0.9.8.

I happened to notice a  search ‘when is zencart 2.0 actually coming‘ in today’s log. It’s a good question. Unfortunately I do not know the answer, but I do know that the next ZenMagick release is not far!

Today I checked in the final changes to make the category pages use the new sql based pagination code that hopefully will be on par with the way Zen Cart handles it [(except for being a lot more complex, of course ].

That means that the last bit I was hoping to get into the next release is actually in place. I’ll be doing some more testing and try to figure out which plugins need updates. That should hopefully get me to a point where I can write release notes and build ZenMagick 0.9.5 next weekend!

I think I really need to do something about the plugins. Ideally, they would all have their individual changelogs, but right now with core changes that affect pretty much all plugins that seems to be overkill. I guess for 1.0 that might be something to look into, though.

Coming back to the search mentioned above: Of course there is no need to wait for Zen Cart 2.0 in order to enjoy things like:

• Plugins that do not require file changes
• A simple template structure that does not need include/require
• A database API incl. DAO’s, transaction control and support for different database providers
• A MVC based framework
• Flexible form validation with rules to change both JavaScript and server side validation in a single place
• Guest checkout aka. checkout without registering
• and a lot more

Just start using ZenMagick today!

There is constant interest in my last post about phpBB support. Seeing that phpBB2 is getting a bit old and phpBB3 the way to go I decided to have another stab at phpBB3 integration.

Rather than write just some straight SQL I’ve played a bit with using phpBB code directly from a plugin. Had I seen earlier that phpBB3 also uses a global $db (same as Zen Cart) it might have saved some valuable time :/

Anyhow, I am happy to announce that some critical progress has been made and a solution is within reach. There is working validation code (email address, nickname) and yesterday I managed to get the create account code to work.

The trickiest bit was actually to get the password hash to work. Since the phpBB code needs database access (no, no, $db!) I had to find another way.

Luckily, the hash code in phpBB is based on phpass without any major modifications. So, I’ve added phpass to core (just the one class PasswordHash) and added a generic new authentication provider using it.

The new phpBB3 plugin will have its own implementation,. though, as it needs to generate hashes with a different identifier. Yay!

Next on my list are updates and logoff. In the long run there might also be code to handle session timeouts and auto login to phpBB, but I haven’t done any research on that yet.

So far, like most integration mods/plugins, this is one way only (from ZenMagick to phpBB). If anyone could point me to a phpBB mod that tracks user actions (registration/modification/logoff) that I could use to implement the reverse (profile changes in phpBB) that would be great.

Yesterday, I wrote about the new getBean(..) method in ZMbeanUtils. Today I checked in the changes to allow bean definitions in url mappings. This required some restructuring of the parameters (incl. renaming of some of them, plus dropping the parameter parameter, which is no longer used now that parameters can be specified as part of the class).

(more…)

Last week I was asked if it would be possible to use the CSS click-show-hide menu mod in ZenMagick. After some quick testing it turned out that only some minor changes are required in order to get it working.

Of course, there are some things that could be nicer. With product counts enabled the generated category tree uses an additionl 260 database queries (even thought that is not really news).

I changed the mod to using the ZenMagick API which kind of fixed that problem. One minor issue remained, though. The original Zen Cart code calcualtes the product count on a category sub-tree, not just the actual category. So the numbers are not quite the same. I might fix this, even though I doubt that this is a major showstopper.

The really interesting question now is how to wrap up the resulting files. All there is are the original javaSript, CSS and image files (CSS image path adjused to suit the ZenMagick file structure), the class that generates the HTML and the sidebox template file.

(more…)

Thinking about events yesterday made me wonder why there is actually a very specialised method filterResponse() for plugnis. One of the reasons was that I thought it would be nice for regular code to be able to modify the response, too.

One example of why that could be useful is CSS. In contrast to importing JavaScript, CSS needs to be imported/references in the <head> section of a HTML page. That means if the code that generates the HTML needs some special CSS this needs to be handled way in advance of where the code is actually executed.

One idea is to have some sort of resource manager that is able to access the final HTML and inject all the CSS [either explicitely or by linking .css file(s)]. That way the fact that new CSS rules are required would not need to be known in advance.

One obvious use case would be the new widget class, of course!

Looking at the code I remembered the real reason why this is so special: the HTML contents is passed into the method as parameter and the modified contets returned used as parameter for the next plugin, and so on.

Currently, events do not return values. The only parameter is a hash map that may contain any type of data.

So, to cut to the point, I changed the fireEvent() method to optionally handle return codes. The default behaviour is compatible to the current use, however it is possible for event subscriber to return a changed array.
Strictly speaking this is not really necessary as it is possible to modify the parameter array due to the reference handling in PHP5. Still, should special events require a contract where the parameter is not an array things should be ok.

So, as o f the next release [0.9.5] content filtering will be available to every piece of code that whishes to do so.

Zen Cart does have an extensive event system. One thing I feel make it not very useful is that most events are specific to a particular page. For example there is a different NOTIFY_HEADER_START_XXX event for each different page.

In ZenMagick there is the generic controller_process_start event with the actual controller instance as event parameter. In particular plugins that need to run on each page this needs some additional work. (Not much, but there are worse examples).
So, one other outcome of my work to make plugins work (better) with Zen Cart templates is to convert Zen Cart events into ZenMagick events to tigger the same event callbacks from within a Zen Cart template.

Seeing the events using the page_stats plugin is acutally quite impressive. For example a product details page (demo DVD product) looks something like this in Zen Cart:

Compare that with the same page using a ZenMagick theme:

Again, both pages where rendered without any sideboxes.

You can spot the artificial ZenMagick events in the Zen Cart event list as the keys are lower case. The differences are even more impressive with products that have lots of attributes.