In this installment of my ramblings about ZenMagick I’d like to explain some of the somewhat unmotivated API changes.
If you look at the checkins of the last couple week you can see a number of changes to allow creating and updating of database content. It also becomes clear that those changes are not too generic as they allow only a limited set of data to be changed. (In the case of orders, for example, only the status!).
The reason for those changes is that I need them for my current (paid) work on zen-cart/ZenMagick. There - I said it! Companies paying to make changes to ZenMagick! I am really excited about this fact and would like to reiterate that there is always room for more (clients).
So, as a rare case of self promotion, I’d like to announce (again) the availability of commercial ZenMagick/zen-cart support and development. Any inquiries please to martin at mixedmatter.co.nz.
In a unrelated matter of ZenMagick development I’d also like to add that the admin changes process well, although slowed down by my other activities. Still, expect some new stuff in the next couple weeks (or so).
I am still looking for some good designs that I could convert into ZenMagick themes. Ideally, they would be free or under a Creative Commons license so they could be used commercially. If you think you have one or have seen one, please drop me a line.
I am also still looking for a new design for the ZenMagick homepage. This would be actually quite motivating to convert the rest of the current site to either the wiki or something new and shiny. Again, suggestions are more than welcome.
For now, I’ll keep scanning OSWD and Open Designs…
Another installment of my where posts. This time it’s about the short and middle term future of ZenMagick.
As some might have noticed, there is a certain concentration on jquery and plugins at the moment. This is no coincidence. The storefront is working fine (as far as I know) and apart from the occasional update due to API changes not a lot has changed for quite some time.
For me, plugins are the way to go. They are quite powerful, simple to install/uninstall (in contrast to mods using a merge tool…) and allow you to do almost anything. In that respect, working on*real* stores is quite helpful as it makes you more aware of what is actually needed.
In the medium term the plan hasn’t changed a lot. There are still a few things left to do before moving to a 0.9.0 release. Right now the focus is on three main areas, with moving priorities:
- Improving the admin pages
This is something I have put off a few times, but now with the decision to use jquery, things are starting to move again.
- API improvements
With more activity on admin related tasks, it becomes more obvious that the API is lacking a lot in terms of creating/updating database content. In that context it’s probably more a side effect of the admin work rather than something of it’s own.
- Plugins
Since some of the new admin features are based on plugins (surprise!) there will be even more plugins. Also, I am constantly on the lookout for new features that could be implemented as plugins.
This is where suggestions are most welcome.
I have also started thinking about some separate code to handle installation/upgrade. This is perhaps overkill, but on the other hand the only way I can see right now to make sure that old code is not crashing the installation procedure. However, this is in the early planning stages, so don’t expect anything soon.
There is also my pet project - creating some more themes. I think that is something that would make ZenMagick a lot more attractive, in particular if the designs are OpenSource and well tested!
Despite my good intentions, the next release is still waiting to happen. As usual, at the point in time where you think you are ready something pops up.
The worst case, however, is this new feature you’ve been tinkering with for a while and suddenly it seems you got it nailed and it’s working. Of course, you drop everything else and manically try to get it into a production-like state (and while doing this burn all the bridges…). Needless to say that this almost never is successful in a reasonable amount of time!
So, as you might have guessed, I fell for this new feature. What does that mean? Well, the release will be coming, but it might take another week or so to get everything together.
For those curious about the feature, it’s a new Catalog Manager interface. It’s going to use a bit of jquery (who would have thought that!), and support plugins to add functionality.
Looking at the calendar I realized today that is is already time for a new release!
Although there isn’t really a lot new - thanks to the holidays, I decided that I will build a new release soon. At least that will make all the latest bug fixes available and add some nice admin features.
I’ll try to concentrate on some more admin stuff over the next few month, as I would really like to make some progress there. Not sure where this is heading, but there should be some good looking thingies coming your way.
I’ve written about define pages (static pages in ZenMagick lingo) before and, despite being around for quite a while in zen-cart, it still seems to be a hot topic.
So, to make life easier (at least for ZenMagick user), I have added a new Static Page Editor to ZenMagick that will become available with the next release.
The editor is not going to replace the existing one, but will show up under the ZenMagick menu. Also, it will only be available if the option to lookup static pages in the theme is enabled. This is done by setting the ZenMagick setting isZMDefinePages to true.
The editor will let you select the following:
- Theme
…so no need to switch templates to edit a page from a different theme!)
- Language
Select from any configured language
- Editor
Select from any configured editor
So, you might think ‘What’s the big deal?’
The point is that using this editor will let you keep all your files, even the define pages, in one place (the theme folder). And if that wasn’t enough, the editor will let you create new pages by just typing in a new filename!
Another feature I still plan to add is a preview. This would include the contents being displayed and also the page title as it would show up on the site (the title is derived from the page name, so this might be good to figure out good filenames…)
I thought I might let you know what is happening with the new toolbarmode version…
The recently updated version of toolbarmode, 0.7.1, was rejected on UMO this week. The reviewed complained about toolbars created with the customize dialog loosing their settings after a restart. Even though the extension doesn’t claim to to do that I think it’s fine as that is something that should work (admittedly I completely forgot about this feature!).
So, I’ll be reviewing this issue and hopefully fixing it. It might prove a bit tricky, though, as it seems that custom toolbars are created by the toolbox and get set the mode/iconsize of the toolbox. Not sure how to get around that, but I’ll try…
I just released a new toolbarmode version. It’s in the review queue on UMO, but if you are keen you can download the new version from the toolbarmode homepage.
Actually, this HowTo does not just apply to checkout pages, but is a general principle in ZenMagick. Still, a lot of e-commerce systems include much simpler checkout pages to make the process as simple as possible and therefore to increase the conversion rate.
There are two fundamentally different ways of customizing the layout of individual pages.
- Custom layouts
Custom layouts are a basic feature in ZenMagick and implemented in the ZMThemeInfo class. This means changes will apply to individual themes only. (Strictly speaking this is not quite true, as a theme might inherit those theme settings under the right circumstances)
In your ZMThemeInfo class all you need to do is to add some lines like this:
$this->setLayout('checkout_shipping', 'checkout_layout');
$this->setLayout('checkout_billing', 'checkout_layout');
$this->setLayout('checkout_confirm', 'checkout_layout');
...
This will make ZenMagick look for a layout file named checkout_layout.php in the themes content folder for the configured pages. The downside is that you’ll have to add a line for each page you want to change, but usually this should be simple enough.
- Programmatically
The alternative involves a couple lines of real PHP in either the global or the theme’s local.php file. It’s also a bit more limited as it will just disable the sideboxes.
Here is what you would need to add:
if (zm_is_checkout_page(true)) {
$zm_layout->setRightColEnabled(false);
}
This will hide the right hand side column and, depending on the HTML/CSS give the page content more space.
The same can, of course, be done with the left hand column, too.
There is no strict rule which way to go. A lot depends on the amount of customization required. If it is just about hiding the columns, #2 would perhaps be better as most of the layout file would be just duplicated code and be prone to the classic cut&paste errors.
On the other hand, if the checkout pages are supposed to be rather different (different crumbtrail or funky Ajax thingies springs to mind) , a custom layout file might be best.
Some might have wondered if there is ever going to be news about my Firefox extensions. So, take a deep breath and relax - things start moving again.
As a first step I finally found the time to try to find out why the current toolbarmode version does not work in FF3b2. And what can I say - it’s fixed. There should be a new version sometime soon including a fix for that, some new locale and a bumped version number to allow using it with FF3b2.
I’d also like to wish everyone a (belated) Happy New Year.