It’s been a week of small things. Lots of polishing, going through the various roadmap lists, the admin UI todo, etc.

Also, thanks to some external testing a few small bugs got fixed. I’ve also started on the apidoc generation and at least the generic code is in a presentable state.

The biggest issue is that phpdoctor doesn’t support multiple source directories and I’d rather keep a single documentation tree – at least for this release. But even if things would get split, there is still code in more than one place. More thinking to do….

Apart from that I’ve been busy with other stuff and that is not necessarily a bad thing.

As for the next week – I’ll be looking into what features could still make it into the next release and what not. Not an easy task, but required to be able to move on.

I’ve started converting all ajax calls to using JSON-RPC as format. As it turned out the format I initially created wasn’t actually that different anyway.

The good thing is that there is now a central method to make rpc calls and that will actually look at the format and decide whether the call was successful or not. So far the call was considered sucessful if the actual request returned good.

This also means it will become easier to actually access and display ajax response messages which should make the UI even nicer.

There are a couple things that are currently not that great in ZenMagick. One of them is the search.

Now, with the new fulltext feature things might be a bit better, but there is still a lot that can be improved. One way to improve a site search is to use a 3rd party. There is, of course, something like Google, but there are alternatives.

With my recent change of jobs it seems quite natural to recommend SLI Systems. I should also add that mentioning or recommending SLI doesn’t gain me anything (other than perhaps a slightly more secure daytime job).

So, one of the things about SLI is that for simplicity the search results page is hosted and generated by SLI. To avoid breaking domain borders, this can be done on a subdomain, for example something like search.mysite.com.

I am toying with the idea of actually writing a new plugin to make using SLI simpler for ZenMagick sites. Beside the obvious advantage for sites interested in using SLI I think there are a few areas to cover that I haven’t touched yet, so it might be an interesting exercise no matter what.

Another thing to consider is that SLI offers a extensive set of tools to analyse search traffic, some SEO options and, one of my pet issues, the ability to not only search products, but the whole site. In particular for sites that make use of reviews, etc this could be interesting, IMHO.

Any other suggestions for improving the site search are, of course, most welcome.

Time for another update, although if you are following ZenMagick development chances are that you’ve seen most of what I am going to write about already.

The most notable thing that happened in the last week surely was the website refresh. It’s been a long time coming and I kind of had given up on it. So it is even more satisfying to see it now in action.
I am currently going through all the spelling mistakes that get found and I will also try to add things as I notice them missing.

Related changes happened on the wiki and forum with new favicons and logos finally making their way online. In particular the forum will need some more work to get the header look a bit nicer. I generally don’t mind blue, but that is perhaps a bit too much.

Another thing is, of course, the ongoing work on the admin UI. rubikintegration have done a great job so far, despite that fact that I have ignored a big chunk of the HTML/CSS they have produced. OTHO, I think I’ve gone a bit further with the dashboard than was originally planned.

In fact, things are still moving. I just updated the screenshots to show the recent changes. The dashboard now supports 4 different layouts – symmetric 2 columns, unbalanced 2 columns (small column left or right) and 3 column.

The screenshot on the website shows the unbalanced 2 column with the small column on the left.

BTW: If anyone knows some good icons that could be used to select any of those layouts I’d love to get them

I guess the next step would be to add more widgets – any suggestions welcome. Update check, etc are planned for somewhere around the second next release, so that might be an idea.
It is also worth pointing out that dashboard widgets are just simple classes implementing an interface, so every plugin could add to that list too!

Admin standalone releases are now part of the build process, so that is something to look out for. New snapshots should be out soon.

Another milestone was to integrate pomo – the PHP gettext implementation also used by WordPress – into ZenMagick.

The default behaviour is to load language strings from .yaml files (everything most things are YAML in ZenMagick these days). However, a simple setting change and .mo files will be used.

So, the list of things to do is getting shorter, which means the next release is finally approaching.

With the MVC code now finally in shape to handle something like the new ZenMagick admin application I wonder if it is time to split of the MVC code into its own project.

I know this would mean more admin work, etc. but I also think there would be some serious advantages:

• People could use and test the code independently from ZenMagick
• Things would be easier to document

In particular the second point is something I am interested in. Documenting ZenMagick is hard – there is so much stuff all over the place. To be able to step back a bit and concentrate on the underlying architecture without the relevance for a particular application (store/admin) would make things a lot easier, IMHO.

On the other hand, reading the MVC docs would be of immense value to people trying to understand how ZenMagick works.

Perhaps a first step could be to create a separate area in the wiki to start documenting the generic MVC code. Something that would have to be done anyway and to be honest I’d rather do that than documenting the store itself…

Also, I guess a separate release package would be a good idea. That way it can be used separately and hopefully a lot more testing is done.

The good think about the splitting up I’ve done over the last few releases is that now it it a lot easier to identify new features the MVC code needs in order to help make the store/admin development easier. That way the application development is driving new features in the base code and sometimes this also results in refactoring to make the base code simpler.

I’ve finally finished the reorganization of the language/translation code. Yay!

So, what does that mean, you ask? Fair questions:

• ZenMagick now can support the same locale file structure that gettext requires. It is not mandatory, though.
• Translation strings can be stored in either .yaml or .mo (compatible with gettext) files.
• Translations may be split into many files. However, in that case it is your problem to load those. The default behaviour is to load just a single translation map.

That means you can use the homegrown system just like before (with the only change that translations are not store in PHP code anymore, but as YAML hash map).

The code to handle .mo files is named pomo and is used in glotpress and also WordPress. So far it has lived a quit live as plugin in ZenMagick, but today it moved into core for all to see and enjoy.

I haven’t decided what to do about the new admin UI. Right now the priority is to get it going at all. Once that is sorted it might really become an option to use a place like transifex to mange translations. In that case pomo would come in very handy, indeed.

Another week and a half gone and the work on the new admin UI continues.

The catalog manager is working now – perhaps not as intendend by the design, but at least it is on par with the old code. That should be enough to aim for a release. As a distraction I’ve implemented something I called application context (ZMApplicationContext). It is available via the method ZMRuntime::getContext() and is losely modelled after the application context as found in the Spring IoC container. Nothing to worry about for now – I’ll write more about it later.

I also now have a process to create standalone admin releases. That means it is possible to use the ZenMagick admin UI without affecting storefront at all!

With the admin closing in on something that is usable, the focus now shifts to cleaning up all the lose ends – and that is not a small task either.

In no particular order:

• Figure out how to build the apidocs from multiple locations
• Add the store app lib folder as option to the translation helper
• Redo the translation helper options from being code centric (where things are) to user centric (what things are); ie. have options like ‘All storefront strings’ rather than folder xy
• regression testing
• some more general design tweaks
• dashboard tweaks
• add user prefs dialog to allow to switch UI language and WYSIWYG editor (if plugins available)
• finish form validation code upgrade
• tweak UI font size for dialogs and some other screens where things get too big
• some cross browser testing
• Create appropriate readme files for each build type (mod, full, admin)
• Add proper status handling to all ajax code (use json-rpc 2.0??)
• Some more cleanup work related to i10n

Finally, there are some admin tasks that I still need to do. First of all, the new website design. I had a serious go at that over the weekend and I hope the new stuff will be live by the end of the week. Part of that will be to move the release notes into the wiki. That should benefit both readability and hopefully give them more exposure.

Just a heads up that as of 0.9.10 it will be possible to show off the admin UI in a demo mode just like Zen Cart. I’ve added code to all relevant places, so demo users shouldn’t be able to do anything harmful.

With the new admin UI being almost at par with the old code it is about time to think about the next release to get those changes out.

It certainly will be a few more weeks to cleanup a few things, feed out any old code that is now used any more and generally test and fix regressions. Stil, it looks like there is finally something to aim for.