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 just updated the wiki. Sorry for the long downtime – I am still not sure about what actually happened.

Anyway, the wiki is now running 1.15.1 and the upgrade was rather easy. I haven’t exactly followed the upgrade docs, but I think I prefer to not have the message about re-installing show on the main site.

So, what I did was:

• Upload the new version into a new folder
• Set the main site to read-only; this is done by adding a line $wgReadOnly = "Down for maintenance."; to LocalSettings.php.
• Backup the database.
• Run the installer from the uploaded new version
• Once complete, move the new LocalSettings.php as required.
• Edit again to change the var $wgScriptPath to reflect the path of the live site (empty string)
• Edit/configure whatever else needs to be done
• Rename the current wiki folder to wiki.old
• Rename the uploaded new version from mediawiki-1.15.1 to wiki

While at it I also installed a new extension to handle the Google Analytics tracker code and the site is now using a custom skin. This is currently just an empty skin extending monobook, but now the wiki is prepared for a re-skinning once the main site has been updated with the new design.

Should there be any issues please let me know.

The bad news is that the wiki is currently not responding. I’ll try to get this fixed tonight, however I do not have a clear idea as to what is wrong right now :/

The last week was again filled with even more discussion on the forum. The more this progresses the more things seem to pop up that need attention and I am really starting to struggle for time. Finding at least some sort of business model to help me allocate more time for ZenMagick would be really good…

Right, what happened in the last week?

• Completed the toolbox refactoring to remove the $echo parameter from all methods.
  My apologies to all theme coders – most of the work is to find method calls without echo and add that. But be aware that the reverse happens as well – the return value is used in zm_l10n or in string operations. In that case, typically the last false parameter needs to be removed.
• More work on the full release build script
  • I’ve added code to drop the media, docs and upload folder as well as SQL to disable attribute uploads (the wiki is kind of updated, but the section about full release installation should get redone at some stage)
  • Added more SQL to select the ZenMagick default theme as active template (in zencart)
  • Dropped the welcome screen from the installer
  • Dropped the phpbb configuration screen from the installer
  • Added basic branding to the installer and admin UI
• Worked a bit more on a new EZPage admin UI
  The basic list of pages is working, all boolean options are handled by Ajax calls, so nice and fast. I plan on extending that to numeric options too (toc, sort order) so pretty much all except for the content can be changed from the list view rather than editing a single page.
  This is not hooked up in the admin UI yet; if you want to try it, the URL would be zmIndex.php?main_page=ezpages
• Lots of posts on the forum and discussion about the framework, licenses, business options, etc.

I expect to have time for a new snapshot before or on the weekend including all the recent changes to themes. For people still preparing a new store it might be a good idea to work on that to save a lot of work later on…
In that context it is also worth pointing out that it is possible to configure a different default theme. That means if you are planning on having multiple themes (or variations for seasons, etc.) it will be worth building a base theme with all templates up to date and then the actual theme with all the images, CSS on top of that as separate theme.

I thought I’d give everyone a heads up that I’ve finished the toolbox code refactoring that removed the $echo parameter from all methods. With the exception of l10n and i18n that should be the last big change to templates.

I also fixed the Language Tool – sorry, I think it must be broken in 0.9.8 already. Seeing that hasn’t been a single complaint so far I assume it’s not widely used

I’ve also started working on some basic branding of the installer and admin pages. If this gets released it definitely makes ZenMagick a separate product – at least the full installation release.

I checked in the last batch of changes to templates (and other code) relating to the removal of the $echo parameter that was still left in toolbox methods.

According to the number of vim temp files generated this affected a total of 206 files, 82 within the default theme. I’ve documented all methods affected in the changelog, so it is just a matter of finding all calls and depending on the context where the method is used to:

• Add echo in front of the method call; for example: echo $net->url('index');
• If the method is used as part of string concatenation, remove the last false parameter; example: $url = $net->url('index').'?foo=bar';

As some consolation I’d like to add that this is most likely the last major change to templates, unless I’ve missed something. I might still shuffle toolbox classes around a bit and see if things can be merged, perhaps macros and utils? We’ll see.

I recently had a request to replace display of hotsellers, featured, etc products with something more customizable. What we ended up doing was the following:

1. Create a new category in zencart admin and disable (ignore the warning about products being removed – its a new category so there can’t be products)
2. link products wanted into the new category
3. In the template, load products with ZMProducts::instance()->getProductsForCatetgoryId(). The category id needs to be hardcoded here, so if you are using the templates across several installations (for example a QA site!) you might want to configure the actual categoryIds as settings…
4. Manage the products displayed by linking/removing products in a special category

I didn’t get a lot of coding done this week – mostly due to increased forum traffic (good!) and working on the site redesign (also good!).

It’s nice to see the number of active users in the forum slowly grow. So far the forum has generated more feedback, input and inspiration that its sourceforge sibling has done in the past four years!

The coding I did get done was mostly cleaning up the toolbox classes. I finally decided that since I wanted to do that anyway it would be best to get themes more or less stable ASAP.

I also fixed the core.php generating code. As a side effect it should now also be possible to drop the trailing ?> of all ZenMagick core files [hear that,  Raine;)]

I also started working on creating a zenmagick skin for the wiki. So far this just means it looks like the default monobook, just with a lot less code I also found a new analytics plugin, so I don’t have to remember to update the skin file any more – yay!

Beside that I, like many others, I guess, struggled with the recent Firefox update. It’s been a bit bumpy to start with, but slowly the add-ons are getting their act together and don’t crash any more (I do not know any specifics, but it suddenly stopped again after updating like mad).

Finally, as I write this I am uploading a new snapshot with all the stuff that changed since 0.9.8. Be aware that themes are still work in progress. The changelog has details about all methods and other bits and pieces that changed. In particular the theme info class got removed and replaced by a yaml file (theme.yaml for all themes). The default/demo themes should be example enough to figure out what to do. Alternatively, creating a new theme with the theme builder should also create a new theme.yaml file that can be used for existing themes (unless, of course, they to special things in the theme info class; I doubt it, though)

Today is one of the rare occasions where I will include an image in one of my posts. Unfortunately, there isn’t that much opportunity to do so more often, but I have this inkling there will be more to come.

The reason is that Matt from malevolent.com took some spare time and created one! Thanks a lot!

It might not be to everybody’s liking, but I like it. So, here it is:

The other good news is that we’ll soon have a redesigned website to go with that logo! Who knows, we might even have ZenMagick T-Shirts soon if we aren’t careful

Once the new design is up we can also tackle creating integrated themes/skins for the wiki and forum. That should be fun and I am sure the result will be a much more usable system. Ultimately, that will hopefully also lead to more useful contents

It’s been an interesting week – not straight forward, but still productive.

I started by converting l10n chunks (those text files in the theme’s lang folder) to static/define pages. That removes the need for the chunks l10n code. This is part of the still undecided plan to move to gettext or perhaps some other l10n tool for localisation.

Next I thought about where to put the code that handles loading/writing static page contents (the files under lang/[language]/static). At that point I had a discussion about define pages and EZPages and I guess in the long run it will be better to drop static/define pages altogether and only have EZPages (or, even better, proper CMS integration).

So I looked at re-implementing the EZPage admin UI for ZenMagick and adding the missing language support. I added create/update/remove support to the EZPage service and now I am ready to tackle that.

This is where the not so straight forward bit comes into play. Around the same time it became clear that the static page editor in 0.9.8 is broken. While looking at fixes I realized that some of the pain is caused by zen cart’s WYSIWYG support code. Next thing I knew there was a new, improved version with support for no less than three different WYSIWYG text editors (CKEditor, TinyMCE, Xinha). It’s not perfect, but absolutely usable.

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)