I’ve got some ZenMagick money to spend on Google Adwords. It’s a voucher that expires March 31, so there still a bit of time. Perhaps I’ll get 0.9.9 ready until then and we could try to do ‘some’ adverts in combination with the release. Any suggestions welcome…

During the last week I’ve been switching between a number of different things. Beside the (now) usual traffic on the forum there have been numerous changes to a wide area of code.

• SEORewriter
  I’ve moved the current net->url() code into a custom ZMSEORewriter implementation. That means that all urls are handled by a SEO rewriter instance and there isn’t any custom code left in ToolboxNet.
• Improved error handling for missing/inactive categories and products
  There are now mappings to handle missing products or categories with a custom template. There is still a bit left to try to give the template as much details as possible to allow to offer alternatives, etc. but it’s already an improvement as it is.
• refactored i18n code
  In fact, the current i18n got dropped completely. There is a minor template change (to pull the charset), but that affects only layout files, so not a big issue, I hope.
• Moved store config files into a config subdirectory
  This cleans up the store folder and also brings the directory structure in line with the envisaged structure of the generic MVC code.
• Plugins
  Some improvements to existing plugins, plus more work to convert bit rotting plugins (in the request directory)
• redirector
  A new plugin that allows to customize redirects when hitting non existing products or categories. It’s not finished, but already allows to map bad product/category ids to good ones.
• Dropped ZMPluginView
  This means that all resources/templates in plugin directories are available to all requests and pages

I’ve started working on the locale code again, in particular i18n. Also, I’ll have a serious go at adding support for gettext via pomo (also used in WordPress). It’s a bit tricky and will probably require changing everything at the same time, so this might not make it into the very next release.

Also, since the date handling in ZenMagick is currently somewhat esoteric, to say the least, I’ll be looking into using the newish (>=PHP5.2.0) datetime features. Should there be any know issues, obviously I’d love to hear about those…

For gettext I also ponder renaming the current zm_l10n functions to something like _zm and __zm – some people really dig short function names (and some are just  lazy).

Comments welcome.

With the move to github finally sorted, it’s now time to get back into coding. As usual I got distracted a bit, but that is also good – it just means I got other things done than expected!

• Improved template manager code to allow group processing of JS files.
  This means all related JS resources (top/bottom) can now be loaded in a single request via the minify plugin.
• Order total plugins
  I made a bit of progress here, in particular moved from a base class to interfaces.
• Refactored some of the request related code, related to further cleanup of the store agnostic code (mostly mvc)
• I finally dropped $zm_theme from the view vars. Access to static page content is now handled by $utils.
• I added the new ezpages admin page to the ZenMagick admin pages. Still a couple things missing, but fully functional.

There is also now a dedicated XMPP server running at conference.zenmagick.org. The cert is still broken/invalid. This will be fixed in the next few days.

Just a heads up that I finally moved the sources to github. That means sourceforge is only used for tracking things and downloads.

I guess in the long run we’ll have to find some other solution, but for now this will have to do.

The next step will be to split off all plugins as separate repositories, so it is easier to get other people involved in writing/committing code.

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?

It’s been a rather uneventful week. I started preparing the move of the source to github, but got stuck with an import process that is now running for 6 days!

The downside is that I am a bit reluctant to check-in anything into subversion now because the most likely case is that I’ll have to redo that once/if the import is complete.

The forum has been active as usual and numbers are still going up. The immediate result are a couple bugs fixed. This proves that having a growing user base does help improve things.

I’ve also just now created a roadmap/feature list for ZenMagick 1.0.0. This magic release has been talked about a bit and I think it would be good to have a nice list of things I would consider required for a 1.0.0 release.

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.