2009/10/02
Email templates for osCommerce 3
I was browsing the osCommerce issue tracker recently and came across a request for an email templating system. This is an interesting concept. I looked at it a bit, and noticed that there were two issues. The first issue is that the email layout is currently hard coded in includes/classes/order.php (as reported in that feature request). Thus, to change the layout requires editing a core file, which makes the layout changes fragile in the face of future changes that might be required to that file. It would be easy to either overwrite the layout changes or to miss a required change when updating the file.
A second problem is that the order information generation is hard coded into the layout. In other words, the layout and database access are intertwined. Further, the function unsets all the generated variables as it goes, so it would not be simple to refactor this to separate the data generation from the layout. It’s not impossible, but it would require a complete rewrite of the data generation — possibly even an interface to provide functions that can handle the looping efficiently.
Another option would be to generate something like an XML file with the order information. Then that could either be parsed to generate the email or transformed with XSLT into the email.
This issue is rampant throughout the osCommerce 3 codebase. There is still a great deal of content (e.g. HTML or email) embedded in code. The template system is better than what existed in the 2.2 series, but it still leaves a lot to be desired.
I can’t help wondering sometimes if osC is going backwards instead of forwards – before using it my php usage was mainly confined to forums and SMF in particular. SMF (Simple Machine Forums) grew from YABB (Yet Another Bulletin Board) which was cgi based. Anyway the SMF forum is so easy to use with contributions added by uploading and installing from the admin – there are rarely any bad installations (unless you do a manual install of a out of date contribution of course
) Coming to osC after that was, what can only be described as, a big shake up to my system. The only real plus is I’m learning a lot more php now 
Comment by Xpajun — 2009/10/05 @ 07:49
If you only install modules (in 2.2, this would be shipping, payment, and order total; in 3, there are several more), then I think that you will find that the installation is very similar to your previous experience. The “problem” is that osCommerce also allows code modification contributions that are not self packaged. I think that this is actually one of the osCommerce strengths — that it allows for deep integrations by developers. However, a side effect of this is that many contributions aren’t really designed for installation by a store owner. Many store owners compensate for this by learning just enough to install contributions.
The issue at which I was aiming in this post is that 3 is supposed to be better about separating the various logic portions, e.g. layout from data management. Unfortunately, this separation is not complete. I still see direct database calls in content and I still see HTML in files that are concerned with data management (an example is the attributes replacement, which has a table based layout embedded into it). The problem that I see in generating the order email is that data is being fetched just in time and then is immediately discarded (in the case of products, each product is discarded before the next product is loaded). I would rather a system where the data was loaded into an order object and then the template would access the order object.
As you may have noticed, this is how Checkout Redux works. It loads an order object either from the cart object or from the database (depending on the type of payment module) and then the notification module uses that object to send the email. Because the email layout is in a separate module, it is easy to replace the default one with one that you like better.
All that said, the current email generation system is certainly no worse than the previous system, which also required editing code. The only steps back are the quickness with which the data is discarded and the direct integration of the database calls with the content generation. These seem intended to solve a problem. However, it is unclear to me what problem that might have been, and therefore I am having difficulty in thinking of a solution that does not reintroduce that problem and that allows for making layout changes to the email without having to touch core code files.
Comment by eCartz — 2009/10/05 @ 19:16