Not sure if everyone is following wiki changes, so I’ll just repeat here the last entry that has been made to the reference sites list (been a few weeks already):
Party Market Online
Party supplies/costumes – simple deployment of ZM, but stress-tests ZM code on a over-19,000 item catalog with 1000+ categories.
I have to admit that I am quite pleased with the final performance of this store. There are a number of levels of caching (page/template) using memcached and also a number of improvements/fixes to the category related code to make this work properly.
Last night ZenMagick 0.9.5 was finally released! I am quite excited about this particular release, because it includes a couple things that make ZenMagick a lot more attractive to existing Zen Cart installations.
For one thing, there is a new patch that allows plugins to access the final HTML content of Zen Cart templates. This has been around in ZenMagick (for themes) for quite a while and proves to be very powerful.
A lot of the storefront plugins (page stats, page caching, google analytics) depend on this feature and now they can be used with Zen Cart templates too!
If you head over to the demo store you’ll see that the HTML generated by the default Zen Cart template is caches like any other page, following the same rules!
Another quite surprising thing (at least for me!) is the new PDO based ZMDatabase implementation. It seems to be the fastest implementation so far and the demo store seems to do fine using it, so I might make it the default implementation for the next release.
There are also improvements to existing plugins and, of course, a couple new ones. The most interesting one is probably the phpBB3 plugin. It provides the same features as Zen Cart’s phpBB support, just for phpBB3.
I also really like the new theme toggle plugin that allows to switch between Zen Cart and ZenMagick. Probably not very useful for a production environment, but good to compare features, displayed values, etc.
Of course, this is not the end, and I’ve already started working on the next version. In that context a reminder that with 0.9.6 I’ll be removing a lot of the deprecated stuff. Also, the deprecated API support will be removed before a 1.0.0 release, but most likely not before 0.9.8.
One of the new features in the upcoming Zen Cart 2.0 version is going to be a reduced number of database queries for price lookup. Most of those queries are attribute related and therefore do not affect all stores/products.
Due to the current work on making ZenMagick properly available for Zen Cart templates, I’ve had the chance to do some easy comparisons. (more…)
I’ve been pondering whether to have another release before Christmas for a while now and I think it would be a good idea. As far as releases go this is going to be a pretty minor one.
I spend a some time fixing some small things that croped up and als refactored a lot defines away (making them consts in service classes mostly). Some theme related defines about directory names got removed completely as they do not really change a lot (and shouldn’t either).
On the plus side there are going to be two new plugins. Firstly, the already annourced form handler and also the code I’ve been using on the demo store to switch themes.
There is also some new code in the form of new cache implementations and also a new ZMDatabase implementation using PDO.
The only real downside is that I’ve touched every single plugin. That in itself is probably not a bad thing, however the sourceforce file release interface requires to set platform and file type for each separately and that is a real pain.
I’ve been playing around with implementing new ZMCache provider. xcache is nice and easy to test, in particular since it comes with a simple admin interface to dump the cache entries.
I just found something similar for memcache and it was really a big help.
Besides being able to verify that adding/removing from memcache worked, it helped figuring out how to retreive the stored items and, more importantly, the cache keys.
Since ZMCache supports grouping of entries the only way to handling this is to iterate over all entries and compare prefixes.
Initially I implemented some internal tracking. However, I wasn’t sure whether that would stay in sync over time. Iterating over entries might not be the most performant operation, but considering that this is ever going to happen from within the admin interface of ZenMagick this should be fine.
EDIT: I’ve started moving this article to the wiki and will not update this post any more!
In my last post I started a list of things to do before the magic 1.0.0 release. I’d like to keep this post as a reference for things to do. Hopefully, I’ll be adding (and removing!) things often as I go.
After spending quite some time on fixing regressions from my refactoring madness its finally time to get ready for the next release.
Rather than reiterating the things that have been changed/added/fixed/improved I’d like to talk a bit about what is coming next. I am aware that I never much of a roadmap for ZenMagick. One of the reasons being that there was just too much to do and I never had real priorities. With the changes coming in 0.9.1 there isn’t a lot left to be done for the templating side of things until we’ll eventually hit ZenMagick 1.0. The API, on the other hand, still requires some work.
While the API is pretty much complete as far as the storefront functionallity is concered, it lacks quite a bit when it comes to the admin side. What I mean is the ability to create and update data. While there has been some work in that area, there is still a lot left. As a general rule, create/update functionallity is available where it was needed.
With the introduction of the new database code I hope to finally get this big gap filled and make ZenMagick even more attractive for integrators and people interested in extending zen-cart.
There is also going to be some more work in refactoring the core code. While this is not strictly necessary, I have the urge to do that just to make myself happy (I hope that is reason enough
Parallel to all that there are plans for a lot more work around plugins:
- admin – maintenance
There are a few plugins that I started, but never finished. Those would make the Catalog Manager a lot more useful. However, those will most likely depend on the missing data access features of the API (namely, creating and updating date like products, categories and other)
This is something I started as a reaction to some discussion about alternative ways to navigate the catalog. Eventually, I hope this will be good enough to replace and improve the current result list/filter code (not sure about the sorter, though). It should be more performant (using some form of caching) and generally smarter.
There are a couple other plugins I can feel coming. This might include some more support plugins for zen-cart mods, but also some new features for the storefront side of things.
Finally, there is more need to trim the code and make it perform better. I plan to have a look at what other PHP based apps do for that and see what seems useful. Suggestions welcome.
So, again, not much of a real roadmap, but I think that a version 1.0 is finally (far, far) far away becoming visible. If you feel I have missed anything important, please, please comment or write me an email.
Happy weekend, everyone
I am (again, again, again) agonizing over ZMCategories.
As part of the database code changes I am reviewing all services and model classes and there is heaps that could be improved (from a coding point of view, most of this work won’t be visible to regular users that just mess with templates).
There are actually two things that make this rather tricky:
- Internal caching
The current implementation does a lot of internal caching in order to be fast.
- The active flag on categories (via applyPath(..))
Initially caching was not a big issue until I added support for multiple languages. Now that I want to add support to create and update categories (for admin tools) there is a second dimentions: the status. Further complications are that the code builds a tree structure to support the category tree navigation.
The second is actually just something I’d rather implement differently as it depends enirely on the cPath request parameter and that shouldn’t interact with a service.
So, I plan to change two things:
- The meaning of the method isActive() in ZMCategory will change and be similar to the same method in ZMProduct.
Active categories are visible in the store, inactive aren’t.
This should actually not be a big issue as this method is used only in the default categroy rendering method
- The whole logic currently done by ZMCategories::applyPath() will have to go somewhere else. Again, potentially the only code affected is
Any objections? – let me know…
EDIT: As it turns out, changes are really confined to
zm_build_category_tree_list(). That means unless your theme uses a custom version of
zm_build_category_tree_list() there is nothing to fear
Not sure if anyone remembers that some time ago I moved all the caching code into the zm_page_cache plugin. That is, all code but the class ZMCache. I was reluctant to move that class as ir provides some basic caching for everyone to use.
However, right now I am in the position to need some caching and it turns out things are not that simple. Well, maybe they are, but it’s not as nice as it could be.
There are mainly tow reasons:
- If each plugin is responsible for it’s own caching only, there will be a growing number of Cache Manager plugin pages, one for each plugin.
- Should there be different caching options (file, memory, etc) there is no easy way for a cache user to take advantage of that. Even worse, it means ZMCache is right now bound to doing file caching.
To remedy this situation and to bring caching more in line with the service infrastructure I’ll be adding another service ZMCache (unless the plural of cache is caches!). This is going to be a cache service that can be queried to get a cache instance that will be what is now ZMCache. I would expect the current ZMCache class to be renamed into something like ZMFileCache.
Another advantage will be that there is no need for individual cache manager pages and it will be much easier to show more cache stats without having to modify each and every plugin that uses caching.
Also, this might be a good way to use more caching in ZenMagick core. For example, some of the more time consuming things like validation rules, etc could be serialized and cached, rather than building them from scratch for every request.
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.