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.

I’ve decided I’ll revive the random notes/facts posts. Every so often I see search keywords in the logs and think: Ah, people are looking for that – perhaps I should tell them it’s already there!

So, for today there are two things:

1. Language support for ezpages
   Since ezpages were added to Zen Cart the database table included a language id column. However, the admin interface never supported that. In ZenMagick there has always been a setting to enable/disable using the language id. I don’t think anyone ever used it – mostly because people tend to use the UI to manage ezpages, not straight SQL…
   Now, in the new admin pages there is language support for ezpages. It doesn’t look good yet, but it works!
2. Another thing are RSS feeds.
   Again, there has been RSS support in ZenMagick for a long time. However, during the last few days it has become a lot easier to add new feeds. Not sure how many will be included as default, but there will be a new one that will contain the full catalog – categories and products.
   The main reason is that a new client needs this to drive the site search. The search will be provided by SLI Systems and usually is hosted on their side to make things easier (typically on a subdomain of the main shop site).
   So, again it happens that the requirements of a single user drive innovation for all to enjoy.

Let me finish by adding that the next ZenMagick release will be build on top of whatever 1.3.9 version is available at the time unless there are concerns that the code is still too buggy. However, I guess 1.3.9b – 1.3.9d should have squashed all the bad bugs.

The guys at rubikintegration have been really busy working on a design for all the new admin pages in ZenMagick. And finally, the design is approaching a stage where it is worth sharing it with the world

Of course, it will be a while before this will become reality, but it’s definitely moving and as soon as we have a static HTML/CSS version I’ll be starting to add the layout to the new admin templates.

Thanks for all the hard work (so far and still coming…)

Seeing that ZenMagick is stuck with sitting on top of Zen Cart for a bit longer [unless I find someone to rewrite all shipping and payment modules for me ] it might be worth spending a bit of time on a new concept for getting around some of the limitations of having all configuration options as defines.

Defines, for those that are not in the know, are somewhat like global constants – once they are created they don’t go away and they definitely can’t be changed. Well, you say, that’s good. Isn’t that what configuration options should be?

I guess the answer is not that straightforward. It seems like a great idea – until you get a project that depends on making one changeable. And then another one. And another one.

So, coming back to the title of this post, multi site is a zencart mod/ZenMagick plugin that allows to use different domains (so potentially different stores) with a single ZenMagick installation. The main issue is that this requires to change some unchangeable settings on-the-fly, depending on the hostname used (mostly).

Right now the mod does this by utilising zencart’s build in support for loading custom settings. There, without changing core files it is possible to create defines based on request data before zencart does. So far this is a fairly custom process that involves having write access to folders and files during installation and generally is quite fragile.
Another issue is that at that point of execution, none of ZenMagick is loaded yet. This makes coding a bit of a pain.

So, I wonder if it would be possible to change all of that by moving the ZenMagick bootstrap code into the optional local/configure.php. To be clear, not all of it, just a single line to load the basics. Sounds great? Uhm, but what about database access? Yeah, true, what about that?

Well, the idea would be to get ZenMagick up to a point where the only things required from the main configure.php are database access details. Those could easily be extracted from the file without loading it and then all other configuration would be available from the database.

From an UI point of view this could mean to have a site/store management page where a new store can be set up and any of the existing configuration options could be set for each store. It could also mean that a lot more zencart code could be not loaded at all and thus saving more processing time. I know it sounds a bit crazy but from a purely coding point of view it seems doable.

I’ve got some requirements for a potential new project. It’s a multi store setup and while that in itself is ok (although the multiSite plugin is currently still defunct) there is one more requirement: multiple catalogs.

More precisely, one store is intended to have only a subset (subtree) of the full catalog.

Now, I know that zencart does have the option to set an effective root category for the category tree displayed, but that is currently not possible in ZenMagick. Also, this is display only AFAICT.
Now, if this project goes ahead I’d be keen to consider implementing proper multi catalog support incl. separate product mappings for each catalog. (Here catalog means category tree).

I am sure that has been done before, so it would be nice to not having to re-invent the wheel from scratch. Any pointers, ideas?

I’ve uploaded a new snapshot – the first 0.9.9+ that includes the current state of affairs of the new admin UI.

Details can be found in this forum post.

In addition it is worth noting that the the mailer code currently only works with SMTP. Others to come – how important are the other options actually?

With the final shuffling of code and splitting up into shared, storefront and admin code I need/want to reorganize all phpdoc package names.

I think for lib/core and lib/mvc I will leave the current org.zenmagick.core and org.zenmagick.mvc packages as that is what they are.

For the actual application code I currently plan to use something shorter like:

• zenmagick.store.core
  The shared code
• zenmagick.store.sf
  Storefront specific code (located under zenmagick/apps/store/lib)
• zenmagick.store.admin
  Admin specific stuff (localted under zenmagick/apps/admin/lib)

BTW: I did some testing with the new admin code and renaming the admin folder works as-is, so no further changes needed. This for all the folks that feel renaming the admin folder makes things more safe.

Another side effect of the restructuring is that it allows to copy the app/store folder and have multiple stores running on the same codebase with just the store specific stuff different, although there might be a few more things to do before that works properly…

The above changes also mean there will be most likely two separate apidocs packages. One for the actual core/mvc code and one for the store application (strorefront/admin) code.