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

It’s been a week of small things. Lots of polishing, going through the various roadmap lists, the admin UI todo, etc.

Also, thanks to some external testing a few small bugs got fixed. I’ve also started on the apidoc generation and at least the generic code is in a presentable state.

The biggest issue is that phpdoctor doesn’t support multiple source directories and I’d rather keep a single documentation tree – at least for this release. But even if things would get split, there is still code in more than one place. More thinking to do….

Apart from that I’ve been busy with other stuff and that is not necessarily a bad thing.

As for the next week – I’ll be looking into what features could still make it into the next release and what not. Not an easy task, but required to be able to move on.

With the new admin UI being almost at par with the old code it is about time to think about the next release to get those changes out.

It certainly will be a few more weeks to cleanup a few things, feed out any old code that is now used any more and generally test and fix regressions. Stil, it looks like there is finally something to aim for.

Time for another update – not the weekly one but just about the catalog manager refactoring.

The last few days I finally had a serious stab at getting this to work and I think I’ve got the basics done (screenshot at the end).
Things do not look spectacularly different from the old code, so don’t expect too much right now. However, it looks like we’ll be able to get the main layout done properly in the next week or two.

Finally, I’ve just added the task ‘Create standalone admin installer’ to my list and I’d like to mention that to hopefully get some feedback on that.

Since the new admin UI is completely separate, it is absolutely possible to run that without any other storefront/templating code. I wonder if that would be attractive as a first step to migrate to ZenMagick (should someone wish to do so). Also, no matter what, the more the merrier, so even if people would just use the admin app it would mean a lot more exposure (and finding bugs

It’s good to finally see some light at the end of the tunnel. The trip is far from being over, but at least there is now a degree of certainty about whether things will work or not.

Once the admin is stable (not complete, just everything working) it will be a lot easier to work on adding features, etc. Also, at that point there will be some more changes to the store code to catch up with all the good stuff that got created to make admin (and the MVC code in general) better.

And, once all that is done it really is time for a 1.0 release! Way to go, but it doesn’t look as impossible as, say, 6 month ago.

Things have, again, been revolving around the new admin UI. I’ve made substantiel progress with the nagivation, although it is not final. Also, there is no actual design applied yet which means unless elements are created by jquery there isn’t much style at all.

On the plus side it looks like it might be possible to style most of the UI using the jquery themeroller.

As usual there have been some improvements and additions to core and store code along the way, however nothing substantial this week with perhaps one exception: I’ve added support for user based authorization. That means it is now possible to control access to admin pages by granting permission to a role (group) or individual users. (Still no UI to manage this, sorry).

As far as UI content is concerned I’ve done lots of small improvements and prepared almost all content for translation.

The biggest chunk of work this week was spend on providing a way to manage all zencart configuration options in the new admin UI. As it turned out, using widgets to render the form elements was really as easy as I had hoped! That means no need to load additional zencart code at all. For the technically inclined, the code parses the set function value and then it’s more or less just a switch to select and populate the appropriate form widget.

Finally, because I am a bit proud a nice new screenshot:

With the ongoing progress in the new admin UI I’d like to step back for a moment and review the current template organization.

So far, the templates use a similar approach as the storefront code. Meaning there is a central layout file that controls the overall page structure. The actual variable page content is rendered by an individual view template for each request.

There are some obvious advantages in this system:

• Central layout
  Changes to the general page structure are done in a single place
• Simple views
  All a view has to do is to create HTML for a rectangular box – the view. That content then gets stuffed into the right place by the layout template – done.

However, there are also downsides:

• No control over anything outside the actual view
  Beside the actual view contents there are a number of other elements on a HTML page that are also request specific. Typical examples are: page title, meta tags, crumbtrail, custom CSS and JavaScript.

I am sure there are more, but the above is what I’d like to look at in this post. While there are reasonably well working tools to handle custom CSS and JavaScript, there isn’t really a great solution for some of the other elements.
Of course, I could write even more tools classes to manage each and every element outside the view, although that looks like a lost case as there will always be new things to consider.

So, what’s the alternative?

The other extreme, of course, would be to code the full page structure on each view (and drop the layout, which can be done). It is hopefully clear that this can’t be the answer. I still have to see a project where this approach, over time, hasn’t lead to diverging page layouts between pages.

So, the question is: is there a middle way?

One thing that would become clear quite easily when trying to code each page in full is that common elements would be extracted and stored in separate template files for all to (re-)use. An technical alternative would be to wrap common content in functions (or macros, depending on the template engine).
This would allow each page access to all relevant page elements while minimizing the duplication of code/markup [basically reduced to html, header and body tags).

Perhaps something worth experimenting with before committing any further to the current system. I am willing to spend some time to investigate this in practice before the work involved to change all templates becomes too big.

It’s certainly going to be interesting and I will post more about it as I go.

I am at a point in the admin refresh where I would like to integrate existing zencart configuration options (and groups). Pulling that out of the database and displaying the groups and related options is not so hard. However, there is the big question about how to make the stored zen_cfg_xxx functions work.

Since the new admin UI will not include more that the absolutely required zencart config files this is somewhat tricky. So far I have considered the following:

• Custom loader
  A custom class/code loader that would load zencart code on demand. A lot of hardcoding might be required. However, it won’t solve the problem of missing functions.
• Re-impementing required functions
  This would work, although it would be a pain. Hmm…
• Mapping zen_cfg_xxx() methods to ZenMagick widgets.
  I hope this is is going to work as my gut feeling is that it will require the least work and remove any dependencies from the UI itself.

If there are other options please let me know.

Another week flying by… According to the changelog not much has changed, but that is not the whole truth. At least as far as changed files are concerned this was a most sucessful week! I’ve updated all of ZenMagick to using the new locale l10n functions. Luckily a lot of that was scriptable, but all cases involving parameters had to be done by hand…

Apart from that most of the things happening have been already documented in the previous mini-update.

There are two more things worth mentioning, though.

Firstly, I fixed a long standing (although unknown) bug that prevents product view count updates. So if you’ve ever wondered about that – this is why :<

The other thing is an issue around products with attributes on 1.3.9.x. Not sure why, but if you have a product with attributes in the cart and try to check out you either get a timeout (the default 30sec.) or out of memory – whichever happens to be first.
I haven’t managed to figure out what is going on, though. Once that is fixed I’ll do another snapshot and move back to the admin UI.

As far as the 0.9.10 release is concerned, I’ve just moved all things open from the 0.9.9 roadmap to 0.9.10. Not sure how much I’ll actually manage to do, but at least things are not forgotten. Currently the plan is to finish the new admin code up to a point where it provides at least as much functionality as the current code. At that point I think the next release will be ready. It is perhaps one of the biggest changes ever, although templates are luckily not that much affected. Yay!

I think it might be a good time to write a bit more about the new admin UI we are working on right now.

This is not just a facelift for the existing zencart admin, but a completely new application. It is using the same code as the ZenMagick storefront does to handle requests and most of the code is shared between admin and storefront.

However, there are a couple important differences.

1. The new admin is not Zen Cart.
   Now, you’d think that is obvious, but there are certain implications. First of all, this means with the exception of the includes/configure.ph and a couple others, no other Zen Cart code will be loaded. It follows that existing Zen Cart admin code will not work [and there won't be any attempts to try this - at least not from me!].
2. The code is not under admin.
   In fact, the new code will be under zenmagick/apps/admin. Right now there are already three different apps: admin, sample, store. The names are perhaps not that great, but they do work.
   Now, store does contain storefront only stuff, while admin contains admin only stuff. [sample is, as you might have guessed, a sample app and not included in release/snapshot builds]
   The biggest chunk of code will be in zenmagick/shared and contain all the code used by both admin and storefront.

One of the interesting aspects of this breakup into separate apps (while sharing code and avoiding code duplication) is that the folder names are pretty variable.
Changing the admin folder name does work without any other changes (unless you move it up/down in the file hierarchy, of course!).
Another aspect to this is that it is possible to point an entirely different domain name to the admin folder directly. (If done for security reasons, it should be accompanied by some .htaccess rules that forbid all access from the main store domain, though).

So, the way I see it the new and old admin will have to coexist for quite a while. Although a lot of the existing admin pages can be re-done relatively easy, there should be given time to get them right. Also, you can expect a certain amount of Ajax to make things fast and slick.