With the number of sites using Ajax growing it might be a good time to review some of the Ajax code in ZenMagick.

In particular I’d like to review the returned JSON structures. Right now, all of the demo code just assumes that the data returned is good, as long as there is a successful response. Obviously, that is not always the case.

So, I think it would be good to have some global structure that allows for things like a overall status flag, 1-n messages, plus the actual data (if any).

I do not know if there are established patterns for things like this, but if so I’d like to hear about those – obviously, all other suggestions are welcome too!

I realized only yesterday that I completely missed last weeks update. So, I guess I should have twice as much to write this week

However, things have slowed down a bit, so there isn’t really that much to report this time.

• Meta Tags
  Added support for product meta tags – this was overdue, I think
• Category display
  Fixed a bug that would allow to display disabled categories
• Added code to allow plugins to add to the extras menu
• music product_info
  Upgraded and improved. The plugin now includes code to add/drop the extra menu entries. This means without the plugin installed the extra menu is hidden!
  Also, added SQL to create/drop the relevant database tables. The only thing left are the actual admin pages which still ship with zencart.
• hoverbox3
  Upgraded
• fualSlimbox
  Upgraded
• admin
  Started working in getting the admin MVC code working properly. Right now there are still a few unsolved issues regarding code sharing with storefront. I have, however, already added code to access the admin user. Also, group/role support has been added to the already existing code. The authorisation code doesn’t handle that yet, though.
• Last, but not least, I’ve added the option to configure additional url mappings via theme.yaml!

With my current investigation of using the ZenMagick MVC framework for admin pages I’ve finally hit the point where sharing all code (and configuration) hits a wall.

For example, url and sacs mappings have to be different, so there is no point loading the storefront mappings in admin (and vice versa).

Also, there is reason to have separate implementations of some classes. For example the current ZMController class uses $request->getAccount() to validate access. However, for admin requests this doesn’t make sense as there will never be an account instance, but an admin user reference.
The consequence is that a few more things need to be refactored to make the MVC code even more generic. It also means that it is now time to reorganize everything under the lib directory into shared and individual code for storefront and admin.

All this, or course, implies that storefront and admin stay within a single application – more to think about…

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…

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.