Looks like finally with WordPress 3.4 it will be possible to use the API by loading the WP code from within a class/function.
It is amazing that is has taken so long to get this done, but as I remember there used to be a lot more globals that depended on file being included from global scope.
Good news, though, as it will finally allow to write a ZenMagick WordPress plugin without using any hackery
After having published a first snapshot of the upcoming ZenMagick 0.9.14 it seems time to write about what is new and shiny in the next release.
Perhaps the biggest change is that zen-cart is now loaded on demand and ZenMagick is the main request handler.
What does that mean?
It means that for example, ZenMagick is responsible for session handling. It also means that no zen-cart code is loaded unless ZenMagick allows it.
Right now that *is* still happening, as there are still some missing bits in the ZenMagick request handling. However, we are nearing the point where this is no longer the case. At that point, zen-cart will only be loaded on demand, and only the bits relevant for checking out and ordering.
As a side effect of these refactorings, we have added a number of modified zen-cart core files into a bundle (the symfony plugin system), so file patches can be obsoleted. On the other hand it means that relying on zen-cart core file patches will not be that easily possible any more.
A second major milestone is the integration of yet more symfon2 components, as can be seen in the list below.
Other, biggish changes include:
- Full localisation support using gettext – po/mo files throughout all of ZenMagick; admin, storefront, themes and plugins
- Support for symfony2 routing; this task is not yet complete, but I expect to have almost full coverage of storefront urls via routing
- Simplified MVC components; again this is mostly compatible with symfony2, with the exception that controller classes always need to be declared using the full namespace (rather than a bundle name)
- The ZenMagick template system is now implemented as a symfony2 template engine. This was a precursor for allowing Twig as alternative template engine.
- Support for ZenMagick WISYWIG editor plugins in zen-cart admin pages
- Skelton for a separate ZenMagick installer application
- Separate main configuration file, independent of zen-cart’s configure.php
For a more complete list of all changes please check the roadmap for 0.9.14.
Last week I helped analyze a case where moving a zencart installation to a new server caused the dps payment module to break.
It didn’t take too long to find out that the redirect from the pxpay payment page back to the store was quite long. After some more digging it was then found (not by me) that suhosin has a restriction on get parameters of 512 characters. The urll in question was more than 3000 chars long, though!
Changing that in the PHP configuration easily solved this problem. Looks like suhosin is gaining popularity, IMO. The second time lately that I had to deal with this.
Might be worth adding a check to the installation script to issue a warning or check those parameters in order to avoid having to debug every time…
I have done some searching online, but despite multiple tries I can’t find a decent SQL (MySQL) parser in PHP. If anyone knows one I’d love to hear about that…
Just a little reminder for myself about how to set up memcache on XP:
- Start here
- Download the dll from pierre
- For stats and stuff listen to myself
Not sure what or when this changed, but there is now an error message at the bottom of my dev ZenMagick site:
‘Fatal error: Exception thrown without a stack frame in Unknown on line 0′
It seems to happen within the exit statement, so after some research I think it is related to error handler or shutdown handler code. Hmmm….
EDIT: Turns out that it is a bad idea to call
parent::__destruct(); if that method doesn’t exist…
One of the things on my todo list for ZenMagick is to review the different types of config/option/setting formats used. Right now there are:
- plain PHP with static code
This is handled via the loader and the most prominent special cases here are local.php files which are fine, though
- PHP code without the <?phph ?> tags
Used for the database mappings – this should/could be nicer I guess, in particular since it might get cached as serialized array anyway
- list of method calls in a single global function
Done for the sacs and url mappings. These could be a single array and perhaps should be. However, it would be nice to have a simple format that can easily be parsed
So, what do I want/need? .ini fileformat is too simple as there is some hierarchical data, although not too deep. Some nesting would be good too.
Of course, XML might be an idea, however I do not have any experience with XML and PHP and do not know what performance is like.
As mentioned before, I’ve started playing around with Savant3 as an candidate to complement the current view code.
So far I’ve got a simple subclass (plus about 5 lines of patching in Savant.php itself) to make it usable as template wrapper.
I appreciate that it is rather simple and I can’t really follow some of the complaints about code missing compared to Savant2 (which I haven’t looked at at all).
- Savant provides pretty much everything the current theme class has to offer. True, it doesn’t have a method to generate theme URLs, but that is easy to add by subclassing. Also, since there is a setting to configure the default view class it would be easy to switch between implementations.
- Another feature of Savant (as of version 3) is support for compiler. The default templating system (if you want) in Savant is straight PHP, sprinkled with some nice helper methods.
- However, there is support for compiler. Another word to describe this might be pre-processor. So, how is that good? Well, I guess it could be used to implement caching on block level. Considering that each sidebox is included separately, some could be cached, even if the page as a whole is not. I think Smarty does a similar thing, even though this migh be abusing the system a bit…
- I’ve mentioned that templating is just plain PHP. This would tie in with the current ZenMagick approach and could could be implemented almost transparently.
- Another nice thing is that theme inheritance is pretty much build in. Savant allows to configure as many search locations for templates as you want. Done in the right order, this behaves exactly like theme inheritance! And with much nicer code!
Beside the goodies above using Savant might have some positive side-effects on other ZenMagick code as well. For one thing, it would force me to really continue with my theme code cleanup. It might be a good time to get rid of the them info class altogether, perhaps in favour of a simple properties file?
So, I am really tempted. However, there will be more experimenting before I’ll be making a decision. Until then there is more code cleanup to be done. On the other hand I might put this into the mix while I am at it … stay tuned
I was recently asked if I’d be interested in reviewing a book about Zen Cart. Since I’ve never read a book about it I figured that that could perhaps be an interesting experience [Usually, I prefer to read the source].
The name of the book is Zen Cart: E-commerce Application Development, written by Suhreed Sarkar. It’s available from the original publishers site at Packt Publishing and also from the other usual suspects.
The book is mostly aimed at people considering starting an online business but also developers and existing Zen Cart users that want to improve their business. For my taste some of the book (in particular the introduction) are a bit to long winded for more experienced readers, but I guess that can be said of a lot of books.
Still, it will give beginners a good idea about what Zen Cart (and e-commerce) is about. Since there are so many different aspects to Zen Cart [and therefore this book] I’ll follow the book’s structure to organize the review, so here goes… (more…)
There is a reason that it has been quiet for a while around ZenMagick. I’ve got a new project:) Nothing too serious and most likely not even a real project.
I’ve tried adding some new features to PHPDoctor, the PHP documentation creator that I use to generate the ZenMagick API documentation. Since it turned out to be a lot messier and complex than expected (perhaps due to my inability to understand the code, I might add) I started re-implementing everything (but not from scratch).