One feature requested for integration with ZenMagick is the admin profiles mod.

I think it is a really useful thing to have, in particular if the project is going to target not just one-man shops.

Since the admin UI will be based on the ZenMagick MVC code, I would suggest that access control is integrated there. Of the top of my head this is the list of requirements to get this implemented:

• display/hide top level menus according to groups/roles
• disable all pages unless explicitely enabled for group/role
• assign admin user to role/group
• implement using ZMSacsManager

So, I think the requirements are pretty much the same as for the existing mod. There would be one improvement, though: It will be possible to set up roles. Roles are a group of predefined permissions. Then a user can be assigned to one (or more) roles and automatically have the permissions of those roles. Permissions would be or’ed, so if one role gives permission to a particular page while the other doesn’t, then permission is granted.

Additional suggestions/improvements welcome…

I’ve been slowly preparing things for a new admin UI for all ZenMagick admin pages. The biggest step has been to remove all individual admin pages (zmInstallation.php, etc) in favour of a single point of entry zmIndex.php.

Within that file, the main_page parameter is used to dispatch the request. Right now this is done manually and the layout is included in zmIndex.php. Views itself are already working the same as in storefront, so there is a content/views subdirectory containing views for all ZenMagick admin pages.

Now, to get to state where zmIndex.php becomes the sibling of zenmagick/store.php, only two things need to happen:

1. A default_layout.php file needs to be added to admin/content
2. zmIndex.php needs to be changed to call ZMDispatcher::dispatch($request);

Right now this does work with one major exception: the included zencart header.php relies on globals (as does the whole init process).

I do hope that for the new admin UI the header will not have to contain a lot of code. All the stuff currently displayed above the navigation should move into the dashboard to make things more consistent. It would also be nice to have a dynamic dashboad where things can be moved around and enabled/disabled.

For example, the update check should be just another option in the dashboard. That would also mean that automatic checks will only happen on the index page and not on other pages. Furthermore, that should be doe via ajax to avoid delays loading one of the central pages.

Once we are that point, I’d really like to get the login process upgraded. Not only would that avoid some of the current code mess, but it would also allow to redirect after the login, just like the storefront does.

We’ll see…

I’ve started looking at resurrecting the product_music_info plugin. Not only is it defunct as far as the recent changes to plugin conventions are concerned, it is also the last remaining piece of code that still uses zencart’s $db.

Apart from that I think the plugin should contain a lot more than it does right now. For example:

• Controlling the admin menu items – without the plugin the extra menu should not be displayed at all!
• admin pages – currently, those come as part of zc-base
• SQL to create/drop the music specific tables – that is actually quite a lot and without that the database would be a bit cleaner, IMHO

There might be more, but that is already more than I can handle right now…

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…

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?

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.

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.

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

I finally felt brave enough to release ZenMagick 0.9.8. I think it is a good time to do a release, seeing that there are so many new ideas coming from users and developers.

As usual there are release notes and also the beautified changelog. I think I’ve written enough about what is is in the release and so I’ll leave it at that for now.

One note about pugins, though. If you feel that a plugin is really missing (not all plugins have been released yet), drop me a line and I’ll see what I can do.

The freshmeat announcement will have to wait until tomorrow or perhaps even Tuesday, but I am sure will do it. Other things still to do are updating the apidocs (done!) and the demo store (which is still on 0.9.6, I think…) (done, except for the pretty links plugin)