As of 0.8.3, ZenMagick includes native support for checkout without registering. I call it guest checkout as there are now three different types of users/accounts as far as ZenMagick is concerned:
The default state for new users.
All required is an email address plus the required information at checkout time (shipping/billing address, etc).
Fully registered (logged in) users
… is sometimes hard.
zen-cart has a function
zen_get_uprid(..) that converts the productId and attributes into a unique key for the given product variation. This key is used in the shopping cart to identify items.
This is a good idea. I am just convinced there is a bug that actually stops processing attributes if there is an attribute with multiple values (ie. the value is an array). Furthermore, attributes are not sorted or anything, so the key depends on the order of the attributes array. Why is that bad? Because it means it is practically impossible to guess that order. That is required, however, in order to be able to calculate the same key in ZenMagick. Or, the other way round, building the attributes in any other way, will result in two items in the cart that are actually identically.
This is not a very likely case for normal store functionality. However, things like the Ajax cart demo might actually use a different order. In fact, there could even be two templates that arrange attributes in a different fashion.
The main reason for my current trouble, though, is a feature that will build a set of default attributes (based on the default flag on attribute values) if a product is added that should have attributes, but hasn’t. This is actually the case in the new drag&drop demo where you can drag products into the shopping cart from the category product list – sigh…
Configuring page caching with a custom function
This is good for plugins or more complex code. Per default, the function
zm_is_page_cacheable() decides whether a page can be cached or not. The name of this function is set up in the setting pageCacheStrategyCallback.
So, setting the value of that setting to your function name will make the cache controller call your function instead of the default.
The wiki plugin is an example for the second approach.
Custom error logging
Since 0.8.1 there is are two new options to control all PHP and ZenMagick logging.
The first is the setting ‘zmLogFilename‘. If the value is not
null is the default), then all ZenMagick logging is written into that file. Make sure that the file is writeable and there is enough disk space!
The second, even more powerful setting, is ‘isZMErrorHandler‘, This is a
boolean flag. The default is
false, but when set to
true, a custom PHP error handler will be used to log all PHP messages.
Note that the error handler depends on a custom log filename, so just enabling the error handler will not work.
There is, however, still a small bug in ZenMagick that will make ZenMagick log messages not appear in the logfile! This is fixed in subversion and will be in the next release.
An example of how this can be used in
local.php would be the following:
Today was a good day for Ajax support in ZenMagick. I made a small but significant change to
ZMAjaxController::flattenObject($object, $methods=null, $formatter=null).
(If you are not into funny PHP programming you might want to stop reading now…) (more…)
People that are into Web 2.0 and all that will be happy to learn that I got sidetracked (again!).
It all started with cleaning up the Ajax demo page. After that things got out of control for a bit
Basically, I added
updateProduct(..) methods to
ZMShoppingCart and corresponding functionallity to the shopping cart Ajax controller.
The cart methods do currently not handle uploads or attributes, though – that will need some more time.
I will probably not spend too much time on fixing this for IE – at least the general Ajax demo does work.
BTW: I converted all Ajax to jQuery to make things a bit simpler (I always wanted to try jQuery…).
With the new subversion code repository on sourceforge.net it’s actually possible to keep track of what I am up to.
Since I usually check in my changes at the end of each day (or even more often), the changelog is updated too.
The latest version including my latest comments can always be found here. Of course, while browsing you can also see all the comments entered during checkins.
Looking at the last post about event handling and subscribing to them in ZenMagick, I realize that there is a bit of development that I haven’t covered yet. As I had the pleasure to describe those bits to someone via email I think it’s a good time to convert into a more visible post. (And, yes, the wiki is coming, I promise)
zen-cart’s way of subscribing to events is ok, however I do not like the autoload step involved. As we’ll see, in ZenMagick there are also two steps (and files) involved. (more…)
The new release it out – yey!
There is already a minor thing I noticed – the sample plugin is actually not included in the core release. I think this has actually never been the case since the build script removed all plugins…
This is definitely easy to fix, but in the long run I’d like to move the plugins somewhere else anyway. It would be nice if the authors of zen-cart mods could take over ownership and manage them. It would be a good exercise to structure the code in order to make it work in to different structures…
Overall, I am very pleased with this release. It is always nice if there is actually something to see and play around with
So, have fun!
Installation patches are ZenMagick’s way to avoid having to distribute modified zen-cart files. They are small bits of code wrapped in an implementation of ZMInstallationPatch. Each of those is designed to modify one aspect of zen-cart code in order to integrate ZenMagick functionallity into an existing zen-cart installation.
The main advantage is that:
- They are reversible
Where possible an undo option exists (even though the admin interface is still lacking some features). This makes it much easier to uninstall than manually reverting changes
- The patches work with other mods
So far there have been no reports of patches failing – except for missing file permissions to update files, but that I would not consider failing.
The descriptions in the installation screen are perhaps not the best ones, so I figured it would be nice to have some more information about the implications of each patch. (more…)
Today I finished restructuring the URL mapping. This is most likely concluding the changes and additions before ZenMagick 0.8.2 gets released. I still need some time for proper testing, though. (more…)