With the relase of ZenMagick 0.9.10 I hope there is no real need to explain what I did the last week, so I’ll skip this weeks update post.

However, there is a tiny bit of work left on the release and that is to open up the new admin demo. Yes, that’s right! The new ZenMagick admin UI does have support for a demo mode, just like zen-cart, although I am not sure how safe the ZenCart part it.

So, hopefully by the end of the week (or, more likely, after the weekend) there should be a link to the admin demo site. It’s something that has been requested (and searched for) a few times, so hopefully it will help people understand what ZenMagick and the ZenMagick admin app are.

I am very happy (and also rather tired) to finally having released ZenMagick 0.9.10.

The main focus for this release has been to get the new admin UI up and running. RubikIntegration have been generous with help on the design and part of the implementation and I’d like to say ‘Thank you’ for that.

Of course that is not all, but instead of repeating things over and over again, just a couple useful links:

Official Release Notes

Details about upgrading

Other than that there isn’t a lot to add, except for a link to the ZenMagick 0.9.11 roadmap. It’s already filled with all sorts of things. It will be interesting to see what we can mange to get done. If there is anything missing let me know.

mano

I’ve started a German translation of the admin UI that will be included ni the next release. It has become quite obvious that I am not a great translator. In fact, the german translation sounds a lot mor wodden and artifical to me than the english original. Go figure…

Anyway, it’s a start. Right now the strings are in a .yaml file, but in the long run I’d love to move to a web based translation tool and also move to the gettext based pomo code. If anyone is interested in helping with translations let me know.

In any case it will be good to have a second language to test switching and making sure all strings are covered.

Well, looking at the new snapshot I uploaded two days ago it should be easy for anyone interested to judge for themselfs

Having said that, since then I haven’t been idle. The catalog tree now actually reflects the category selected, editors are improved, the version check widget does some proper version comparison and a few funny things have been fixed.

Testing will start in earnest now and I expect the next snapshot really to be of RC quality.

Also, there is ongoing work on the website. I’ve started updating the wiki roadmap pages and even already created a new one for 0.9.11!

If you have any interest in a new shiny ZenMagick (and therefore Zen Cart) admin UI, now is the time to come aboard – any input is welcome and since I have no preference for what to implement next this could be your chance to decide what to implement next!

I think it has been quite some time that I complained about zen-cart, so I feel entitled to have another go: aaaaaaaaaaaahhhhhhhhh!

Actually, it’s not that bad, but I really wonder why all zen cart code uses require rather than require_once. Sure, there might be some performance issue (although I don’t think that really matters), but really: why??

Every time some custom code wants to use zencart classes that haven’t been loaded yet but will be later things screw up. So, the alternative is to wrap all classes in their files in if (!class_exists('class-name')) {}, but if it is about performance that is perhaps not much better.

Any chance to get that fixed??

Since the website update downloads have been very low. Doesn’t mean they are that hight to start with, but it seems the update has somehow made it less likely that people download ZenMagick.

I’ve added two explicit download links at the top of the main download page, plus some more text links for the various things that can be downloaded. Hopefully this will help people find what they are looking for. I’ll try to make the  main links look more like real download buttons, but I haven’t found any usable download arraw image that I could use. I am also not sure why the top corners look less rounded than the bottom ones, even though they all have the same CSS!?

I’ll give it a few days to see if things pick up again. I also still need to add a link to the snapshots folder because that is currently not linked at all and I hope to have some new packages ready for testing sometime this week…

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.

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.

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.