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 just realized that it is time for my weekly update, so here it is.

Not much happening in the last 7 days. Lots of cleanup, helping out with a couple sites, fixing a few things, re-shuffling of roadmaps and some last minute changes. Things are down to three items on my todo list; I am afraid the remaining items on the 0.9.10 roadmap will most likely move forward to 0.9.11. [Incidentally, that is where most of the left-over items of the dev/admin todo list ended up ]

So, there are three things left, plus some minor tweaking of the full release install pages:

• Emails
  For some reason emails are defaulting to the zen-cart email templates – I swear it worked a couple days ago!
• The remainder of the languageId cleanup, although that might actually also move to 0.9.11 as it will require some bigger changes [something that just ocurred to me writing this!]
• sync the database mapping file between admin and store

I’ve added some steps to the build process that allow to enable/disable locale for a release build, so, seeing that the German translation is not yet ready the admin UI will most likely ship with en_NZ only.

A mixed week with some good results, too!

Testing is progressing, unfortunately it also uncovered a few things that need fixing first :/ On the plus side I’ve upgraded useo2 to the latest version and there is even a script that can patch the code so it runs in the new admin.

Most of the required changes are using ZMDatabase rather $db and a couple other things, for example support for the category urls.

I am also very close to getting a couple sites upgrade to the latest 0.9.9+, or, better 0.9.10RC. It will be good to get some real usage to see how good the code really is :0

Apart from that there are a few improvements that now allow to cache individual template files. For example, each sidebox can now be cached or not. The current caching code itself is rather simple, but it should be easy to make it as complex as required.

This is now enabled as default, as is support for PHP short tags. That is done as a custom filter that will change all <?= or <%= to proper <?php echo syntax.

Again, this is just to get some mileage, I do not expect that a lot of people will be using this initially.

Category caching now works properly, so even a couple thousand categories won’t slow things down too much on the storefront side. The backend/admin will need a bit more time. Again, template caching will make things a lot easier in those cases.

I’ve added a new APC based cache implementation. It does cache things, clearing the cache is still a bit buggy, but if you are keen you can always use the APC admin interface to clear the cache.

The cache admin page now properly shows all used caches and groups. I hope that will make it a lot more useful Outstanding here is some sort of central caching config for each cache type. This will be possible either with smarter settings or the still unused context code.

Some time ago I wrote about some changes to make large catalogs more performant. Today a second batch of changes got committed (sorry, forgot to push, though!).

What does that mean?

First of all, this was in collaboration with a developer facing issues with a large database, in particular categories. So, talking to me does occasionally help getting your problems solved faster!

Secondly, there is now a new interface ZMSavantCache and a also a simple implementation class thereof. There is also sample code of how to configure Savant to use the cache class and how to configure the cache class itself.

All there is to do is:

1. Change the bean definition of the default view class to set the caching implementation to be used
2. Set up a new setting that lists all the template filenames (for example: ‘boxes/categories.php’) that can be cached
3. Done!

Eventually this should be the default setup with some reasonable defaults (perhaps with a more sophisticated cache implementation, though).

This template file level caching is a great way to complement the existing page cache plugin. In the above example of a catalog with thousands of categories, caching the categories box cut of about 4 seconds of processing (measured inside a VM, to be fair).

In addition I finally managed to get APC working on my dev environment (Windows, go figure…), so there is also a shiny new APC cache implementation to go with that

And, again, all that just because someone started asking questions and suggested solutions and patches.

You are welcome.

Last week I wrote about including a WYSIWYG plugin as default. Since then I’ve extended this to more plugins.

I still think that managing features in plugins is a good thing. However, some plugins are quite essential, so it makes sense to include them in a default package so they are there – ready to be used after installing ZenMagick.

There are still a few open spots to be filled, for example SEO, etc but I am hopeful that those won’t be too hard to fill.

As it turned out, .po and .pot file generation based on the current string scraper code wasn’t too hard. In fact, the hardest bit was perhaps to validate the created files.

It’s not so easy to find usable gettext binaries for Windows.. I ended up using a package from CubicWeb. It does crash, but only after having done the bits I want it to do

So, now there is a new translation project ZenMagick with a component admin UI on trasiflex. So far I’ve created a (default) en_NZ and de_DE locale. Since ZenMagick uses default strings in the code the default locale is at a 100% – yay. German is at 0% :[

If you are keen to work on a different language, let me know and I’ll add it to the repository.

I should add that the code is still using the .yaml files that are also located in the locale folders. As long as there isn’t a useful translation I can’t really see any reason to switch yet.

The last week I have been mostly busy with four things:

1. private stuff
   Just as the title says…
2. testing
   I’ve done a fair bit of testing. Found a number of regressions, fixed them, found some more…
3. localisation
   I’ve added an experimental german transaltion for the admin UI, but it is both incomplete and not that great. Localisation is definitely something where the project will have to rely on volunteers.
4. paid work
   Sounds better than it is – the ratio of unpaid/paid is pretty sad. Having said that, the paid work uncoveres a surprising number of bugs/regressions and therefore is multi-purpose, which is not to be dismissed.

Apart from that I have continued looking into planning some proper translations for the admin UI. I have most of the work done to export strings as .po(t), so hopefully it is now mostly a matter of finding the right place to manage translations in an accessible way.

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!