With the number of sites using Ajax growing it might be a good time to review some of the Ajax code in ZenMagick.

In particular I’d like to review the returned JSON structures. Right now, all of the demo code just assumes that the data returned is good, as long as there is a successful response. Obviously, that is not always the case.

So, I think it would be good to have some global structure that allows for things like a overall status flag, 1-n messages, plus the actual data (if any).

I do not know if there are established patterns for things like this, but if so I’d like to hear about those – obviously, all other suggestions are welcome too!

I’ve just checked in some changes that add a new menu item to the ZenMagick admin menu: EZPage Manager. I know that my use of ‘Manager’ is a bit inflationary, but those names might change with the new admin UI, so it will do for the time being.

The new code is not 100% finished, but functional. The overview looks very similar to the zencart page, but there are differences:

• The ZenMagick EZPage editor supports languages.
• The HTML content edit widget supports WYSIWIG editors via ZenMagick plugin, same as the static page editor.
• The details layout is a bit different and in a separate view
• All boolean flags (green/red images) in the over can be toggled via AJAX
• Right now there is support for paging long lists of pages
• The editor doesn’t redirect after an update
• The editor is not selectable (the current editor is used, which is either the default or the last selected from the static page editor)
• There are no sorting options in the list view
• There is no ‘Are you sure’ confirmation dialog when deleting pages

With this a could general questions arise for the admin UI:

1. Should each page have a separate language/editor selector it needed or should those be somewhere in the layout and apply to each page? Or perhaps just be in a admin options page/popup/whatever?
2. Are JavaScript based confirmation dialogs sufficient?

I’ve been looking at potentially replacing the current string array based translation code with something more mainstream. One obvious candidate is gettext.
gettext has been around for a long time and is used in many applications. One particular downside is that it generally works with a single file for a given language/locale. Now this is great for an application where you have control over all strings. Obviously, this is not the case for ZenMagick. Looking a bit around showed that there are various solutions to handle this.
One particular good solutions is pomo. pomo is a thin layer on top of gettext. It allows to have multiple translation sources (which can be merged). Furthermore, and that might be the main benefit, it is pure PHP, so even works on systems where gettext is not installed.

One prominent application using pomo is Wordpress. I’ll have a play with it and try to write about any progress.

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 finally felt brave enough to release ZenMagick 0.9.8. I think it is a good time to do a release, seeing that there are so many new ideas coming from users and developers.

As usual there are release notes and also the beautified changelog. I think I’ve written enough about what is is in the release and so I’ll leave it at that for now.

One note about pugins, though. If you feel that a plugin is really missing (not all plugins have been released yet), drop me a line and I’ll see what I can do.

The freshmeat announcement will have to wait until tomorrow or perhaps even Tuesday, but I am sure will do it. Other things still to do are updating the apidocs (done!) and the demo store (which is still on 0.9.6, I think…) (done, except for the pretty links plugin)

Instead of waiting until the last minute I’ve started rather early with the release notes for 0.9.8. I do hope this reflects in the quality (eventually).

So far this makes up for some impressive reading, IMHO. One indicator that the pace has increased is the fact that I do not have the usual release blues. What’s that, you ask?
Well, usually it gets to a point where I am not motivated to add anything else any more (because I run out of things to do?). Then nothing happens for a week or two and after that I just write the release notes and build a release.

Not so this time! However, having promised a Christmas release I do have to restrain myself and leave some time for (hopefully) enough testing. I did have some hope that the snapshots would help with that, but no luck so far. I am sure this will happen over time, though.

(To be fair: all this means is that I haven’t received any feedback on snapshots so far. Given that I found and fixed a few bugs in the meantime could mean that I do test more than I think or that others do test even less!)

Either way, the release will happen and that is good.

Seeing that I am too tired to do anything else I figured I might as well write my weekly update a bit sooner (for a change!).

Although, I have to say it really feels like Thursday…

Anyway, so what have I done?

• YAML
  I added spyc, a YAML library to be used for future and existing configuration files. Perhaps I should say configuration data, because the url mappings, etc haven’t been in a configuration file, but wrapped in a function!
  So, url and sacs mappings are converted, including refactoring of the url mapper as a bonus! More to come.
  I have to say it’s an easy exercise, mostly because you can also dump arrays as YAML, so dumping existing internal array structures in YAML allows to convert things in minutes, provided there isn’t anything else to change in the structures.
• Full release build
  Main thing here was that the build process will move the extras folder into install_zc, so it is more likely to be removed or at least inaccessible than now.
• Plugins
  Converted a few more plugins, which lead to further refinements in the way plugins use the MVC code. I think I’ve got working examples for all possible combinations now!
• Fixes/regressions
  I fixed heaps of stuff, mostly things I broke on the way. However, there have been a few things that must have been broken since 0.9.7, so I am not sure about the amount of thrashing the snapshots actually get…
• blockHandler
  On request of a certain person I wrote a new plugin, including some small changes to view code to allow to map arbitrary contents to HTML comments (if they follow a given syntax). There is no UI, so usability is limited so far. I hope that is going to change soon (wink, wink).
• admin
  Well, converting all ZenMagick admin pages to using the MVC code felt so good, I decided to see what happens if I just take any existing zen cart admin file (I took stats_customers.php and customers.php, btw) and try to convert that into a view template (although keeping all the logic in the file for now).
  Turns out that is really really easy! Just remove all common HTML like the <head> section, the common footer code (including application_bottom.php, etc.), add one or two global $db; and there you are – zen cart code served by the ZenMagick default admin controller!
  Obviously there is more than that. Forms still point to the wrong URL and hidden main_page elements will be needed for POST forms, but it’s a good start and it looks like it will pave the way to being able to change the default layout of the admin pages soonish.

Of course, all that is more than I wanted to put into this release, but why stop when it is so much fun

I’ll try to get a new snapshot uploaded tonight or the weekend as the latest. Unless there are major complains that code will be the promised Christmas release.

I’ve refactored the url mapping code and also added code to load YAML formatted mappings. This is working great and beside the fazt that the default mappings are now in a config file and not a function the new mapping is a lot more efficient and fixes a couple bugs/limitations as well!

Other places where YAML could/should be used:

• default sacs mappings
• database mappings
• Settings
• other suggestions?

… yes, YAML to the rescue!

A while ago I was asking for alternative config file formats. I finally seem to have found a strong candidate: YAML!

It’s readable, flexible, supports hierarchical structures and best of all there are pure PHP parsers available!
I’ve picked spyc for some experiments and, in fact, already added that to the repository! spyc seems a very active project and does have good speed.

As a quick test I wrote some debug code to dump the url mappings as YAML. Then, I modified the url mapper to load that mapping using spyc rather than using it’s own mappings. And – voila! It works!

Now I can work on the YAML formatted mappings without having to create nested arrays or anything – what a relief!

While refactoring existing plugins I’ve taken the time to think about which ones to keep and which ones to drop (for now? ever?). Right now I am looking at the dual pricing and the price group plugins.

Two thoughts:

1. The price group plugin should be moved into storefront. There are two good reasons for this. First of all, it would mean not having to subclass ZMProducts. Secondly, it is useful and opens the door for more improvements in that area.
2. #1 actually means that the dual pricing plugin is more or less obsolete.

Opinions?