I decided that the SQL bug is annoying enough to justify another release. This might be inconvenient for people that already installed 0.8.6, but for newcomers it will be much easier to have a version that works without any manual fixes…
Happy Christmas everyone.
EDIT: Turned out the uploaded version on sourceforge was corrupt (again), so I uploaded again and it seems now ok.
Phew – it’s out, just in time before Christmas (as promised!)
I am quite pleased (no bugs found yet , for a number of reasons. I really like the way plugins can add to the core. They also make it easier to concentrate a particular set of functionality so it’s easy to find what you are looking for.
This release is also interesting since a lot of the changes concern code that already existed in one form or another. For example, the code in the phpBB plugin is now a lot simpler as the original code. It also helps that it now actually works!
The most interesting aspect for myself was, that lots of things popped up while working on the init plugins (not included in the release). In combination with a new, simpler bootstrap they might eventually replace zen-cart’s
There is a large number of small changes that are a direct result of playing with that. It really helps to find places in the code where there are assumptions that work only because zen-cart has taken care of things already.
In other words, there are still plenty of dependencies on zen-cart that are not that obvious. So, this is something I will continue to do as it definitely makes the code more robust and reliable.
Another side effect of this release is that I eventually upgraded the demo site to zen-cart 1.3.8.
One strange bug that I found that way is that the demo database is missing the banners_history table. Not sure what this is about – as it turned out I couldn’t access the database using the ISP’s admin panel…
Edit So, found the first bug! The ZMBanners class has the banners_history table name hardcoded in a few SQL statements. The easiest way to fix is to use the ‘zen_’ prefix, or, to edit the file manually to fix the prefix until the next release…
Still, all in all things went very smooth, so I hope at least some sites will upgrade to keep up with the fixes.
Happy Christmas, mano
One probably less well know feature of ZenMagick’s pretty links is that it is possible to create URLs that have the model name in in. This is similar to having the id or manufacturer in the URL, but much simpler to remember and easier to spell that SEO URLs
It is, of course, also possible to create links using the traditional URL parameter syntax.
I’ve had some conversations around utf-8 and generally other character sets using ZenMagick.
I’ve done some (not enough) research and based on that a few changes that should improve the situation. In particular, the configured HTML_CHARSET will now be used in templates and for html encoding.
ZenMagick still needs a full review to evaluate if and where multi-byte handling support needs to be added to be completely on the good side.
It had to happen and finally the first 3rd party plugin is available. I just updated the wiki with a (very) short description and a download link. w00t!
The demo site hasn’t been upgraded yet to 0.8.5 and seeing that 0.8.6 is near it seems pointless to do. It’s not forgotten, though, and it will be done.
Same is true for the API docs which are still at 0.8.4! This is easier to bear, though as not much changed …
I have just checked in a change that converts the current page caching code into a new plugin. This might perhaps be a good time to explain the reasoning behind my shifting code into plugins.
Having build a reasonable effective plugin architecture I think it’s worth using it for several reasons:
- It shows that it works!
This is perhaps not a very technical reason, but I think it is important to show that a lot of different things can be archived by writing reasonably simple plugins
- It keeps the core small
While this is true it is also true that critical stuff should probably stay in core. However, this offers the opportunity to build your own caching code and easily integrate it into ZenMagick.
Another example of a plugin that actually contains/modifies some very elementary functionallity is the Smarty plugin that completely changes the way templates are evaluated; still, it’s good to have this ability to plug in different templating systems without having to modify core.
- Besides being useful it can be used as sample code
Again, not very technical, but probably crucial when trying to motivate other people to write plugins of their own
In addition to the above, plugin performance is not far off from core code performance. This is especially true when using core.php. In that case, all code is back together in a single file and the only overhead is the creating of the single plugin class.
I just found an annoying bug in the zm_useo2 plugin. During installation the plugin would create two configuration settings (status, sort_order) and then execute a patch to install useo2 and modify a couple admin pages.
However, the USEO2 installation code will check for existing settings and delete them all – unfortunately using SQL wildcards ‘%SEO%’. This, in turn, removes the plugin settings, thus leaving USEO2 installed, but the plugin not!
Repeatedly installing the plugin usually fixes this, still it’s quite confusing. Luckily, the next version of ZenMagik will fix this (it will require upgrading a couple plugins, inclusive zm_use2, anyway…)
I’ve been using the new zen-cart 1.3.8 release now for almost two weeks without any problems. The only glitch I had were some SQL problems upgrading on one of my installations. There also seems to be a typo in <em>class.smtp.php</em> – at least I had to fix a missing ‘>’ in every upgraded instance.
Other than that, it work just fine with ZenMagick – exactly as I hoped it would. Re-running the patches worked fine and that was all to do!
So, nothing special for 1.3.8 in the coming ZenMagick release. Should you run into problem, though, please let me know!!
As for the next ZenMagick release (0.8.6), it will contain a number of bug fixes and some nice improvements. Hopefully, it will be out before Christmas so you have something to tinker with should the holidays be too boring
There is a fundamental performance problem with ZenMagick and very large categories. Since ZenMagick does all it’s sorting and filtering in PHP, rather than SQL, it’s easy to see why.
Main reason for this design decision was that it seems to be easier to add new filter and sort options this way. Another side effect is that price sorting is done on the actual calculated prices rather than the internal cost price.
To get around some of these limitations I have started on a new plugin that will use zen-cart’s default_filter code in combinations with it’s split_page_results class. This should make category pages perform more or less the same in both systems.
Filters are not implemented right now but should hopefully ready for the next release.