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!

One feature requested for integration with ZenMagick is the admin profiles mod.

I think it is a really useful thing to have, in particular if the project is going to target not just one-man shops.

Since the admin UI will be based on the ZenMagick MVC code, I would suggest that access control is integrated there. Of the top of my head this is the list of requirements to get this implemented:

• display/hide top level menus according to groups/roles
• disable all pages unless explicitely enabled for group/role
• assign admin user to role/group
• implement using ZMSacsManager

So, I think the requirements are pretty much the same as for the existing mod. There would be one improvement, though: It will be possible to set up roles. Roles are a group of predefined permissions. Then a user can be assigned to one (or more) roles and automatically have the permissions of those roles. Permissions would be or’ed, so if one role gives permission to a particular page while the other doesn’t, then permission is granted.

Additional suggestions/improvements welcome…

I’ve been slowly preparing things for a new admin UI for all ZenMagick admin pages. The biggest step has been to remove all individual admin pages (zmInstallation.php, etc) in favour of a single point of entry zmIndex.php.

Within that file, the main_page parameter is used to dispatch the request. Right now this is done manually and the layout is included in zmIndex.php. Views itself are already working the same as in storefront, so there is a content/views subdirectory containing views for all ZenMagick admin pages.

Now, to get to state where zmIndex.php becomes the sibling of zenmagick/store.php, only two things need to happen:

1. A default_layout.php file needs to be added to admin/content
2. zmIndex.php needs to be changed to call ZMDispatcher::dispatch($request);

Right now this does work with one major exception: the included zencart header.php relies on globals (as does the whole init process).

I do hope that for the new admin UI the header will not have to contain a lot of code. All the stuff currently displayed above the navigation should move into the dashboard to make things more consistent. It would also be nice to have a dynamic dashboad where things can be moved around and enabled/disabled.

For example, the update check should be just another option in the dashboard. That would also mean that automatic checks will only happen on the index page and not on other pages. Furthermore, that should be doe via ajax to avoid delays loading one of the central pages.

Once we are that point, I’d really like to get the login process upgraded. Not only would that avoid some of the current code mess, but it would also allow to redirect after the login, just like the storefront does.

We’ll see…

I’ve started looking at resurrecting the product_music_info plugin. Not only is it defunct as far as the recent changes to plugin conventions are concerned, it is also the last remaining piece of code that still uses zencart’s $db.

Apart from that I think the plugin should contain a lot more than it does right now. For example:

• Controlling the admin menu items – without the plugin the extra menu should not be displayed at all!
• admin pages – currently, those come as part of zc-base
• SQL to create/drop the music specific tables – that is actually quite a lot and without that the database would be a bit cleaner, IMHO

There might be more, but that is already more than I can handle right now…

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.