The Next Step in Small-Business Web Tools – Open Source E-commerce/CMS Hybrids
Posted on 18. May, 2009 by Fred in Web Development, e-commerce
For those of you who are involved with e-commerce development, isn’t it about time we started talking about this? It seems like the modus operandi has become bridging apps these days. For me, that just isn’t cutting it anymore. It reminds me of Chang and Eng, the first well-known conjoined twins, who shared a fused liver. Sure, it would have been neat to see these two guys coexist in that state, but it sure wasn’t improving upon their quality of life. I feel this is analogous to e-commerce packages that bridge to existing CMS packages. They work together, with varying degrees of success, but they aren’t meant to work together inherently.
The difference between bridging and hybridization
By definition, Bridging occurs when two applications with separate code bases and two separate database schema share a link that allows them to exchange data and synchronize to each other either in real time or via scheduled processes such as a CRON job. The major drawback is that you are dealing with two packages, two code bases, and two database schema. Double the updates, (potentially) double the server overhead, and double the fun headaches.
In contrast, a hybrid app is one that is tightly integrated. It should share the same code base/framework and it definitely shares a common database schema. In fact, I would hesitate to call a hybrid solution “hybrid” if you were dealing with more than one code base or framework. In fact, why don’t we just put our foot down on this right now. If it doesn’t share a framework or code base (and someone is actually trying to make it coexist in the same package), there will be hell to pay and souls to eat. No, that’s not a threat, it’s a promise.
What will it look like? How will it work?
All jokes aside, the next logical step is to visualize a truly hybridized e-commerce & CMS system. Here are a few thoughts on what you might get.
- One code base for both tools
- One database for both tools
- One back end interface for both tools (and any modules that comprise the back end functionality).
- All E-commerce tools/assets manageable within the context of the CMS, implemented in a normal CMS fashion
E-commerce tools should not monopolize a page’s functionality
There is a reason that I italicized the sentence fragment above:
…within the context of the CMS, implemented in a normal CMS fashion
A CMS controls the structure and content of a site. So to shall it (as I’m wielding my stone tablets here) control the implementation of the e-commerce tools. This is really a big departure from the traditional way of thinking about how to structure an e-commerce site, and therein lies the problem. A traditional e-commerce site has little or very limited CMS functionality, and usually it is added as an afterthought. For example- in a traditional e-commerce application, there is a single page dedicated to all product listing functionality. Essentially, this page becomes a dedicated controller but will be wrapped in a template with some static or near-static content. You may have some includes which get dropped in left, right, header and footer, but essentially if you want to take things further and place a listing somewhere else (perhaps within another page), you are out of luck. The same goes for any other piece of the e-commerce tool set. The checkout is defined by the code in the page, rather than being one component in the page.
To solve this issue, you need a CMS that emphasizes modular design and allows you to manage where tools go in the front end, not as pages but as components on pages, and it also should seamlessly fit into the existing templating architecture. I know, it sounds like a lot. I’m awful demanding, aren’t I?
There are always naysayers…
I’m hoping that this article stimulates a hearty debate. I’m sure e-commerce purists will find fault in my assessment of what should be when it comes to bringing these tools together, for example, that in some way we may be sacrificing some sort of feature set or overcomplicating things for the end user admin. Just remember, I don’t like hearing myself type as much as I like hearing you type!


nomad-one
18. May, 2009
I’m waiting for this type of integration to make it’s way into wordpress, though have successfully used worpress & wp-ecomerce to setup an ecommerce site for a client recently and it was a great success for my first.
wp-ecommerce is set to release a major upgrade soon making it easier to integrate a wordpress site and online store.
For me the pair worked pretty mch the way ou described, though deeper intregration and more flexibility would be welcome.
Fred
18. May, 2009
I’m eager to play with the latest big WP e-commerce upgrade actually. There are many other facets of a great e-commerce package that I’ll be writing about in the near future, specifically talking about what I call the “operational footprint” of an e-commerce toolset as well as addressing other common issues. For example data migration (this is a huge one for me as a web developer), emphasizing media (video, audio) integration, as well as interface design considerations. That’s just a slice of what I have discovered being in the trenches and need to discuss with others.
Thanks for the comment and your read time!
Camilo
18. May, 2009
I haven’t really test it completely but I think Magento (http://www.magentocommerce.com/) could be one of this hybrids as it integrates CMS funcionality along a product catalog and ecommerce platform. Maybe I’m missing the point
A thoughtful post and great site.
Fred
18. May, 2009
Hi Camilo,
Interesting that you should mention Magento. Having had many, many hours of experience with it, I can tell you that it does not fall into that category. It has a rudimentary CMS, but it can only be bridged to other CMSs. It is still a standalone e-commerce package that basically has only the most basic tools to drop content in here and there. By design, (like other conventional e-commerce packages) it essentially dedicates individual pages to certain functionalities by design versus the true CMS approach which would be to accommodate content elements and modules irrespective of their latent functionality. Sure, it accommodates widgets on the sides and in other places, but the primary function remains the same – it is purpose-built for e-commerce.
You aren’t missing the point, and I appreciate your comments! I hope you keep posting, Thanks!
andrew smith
18. May, 2009
Perhaps the relative complexity of the 2 fields needs to be analysed to determine the starting point. Magento is a beast of a system, and it’s still got many years to go. The core wordpress is a handful of tables. A basic shopping cart is very different to an enterprise ecommerce system.
I’m not sure your suggesting starting from scratch, and so if you’re going to extend one system to incorporate the other, I would definitely say it has to be to start with Magento and beef up the CMS. It is a “modern” and well stuctured platform based on Zend Framework, easily extensible and with a rapidly growing community.
Fred
18. May, 2009
Hi Andrew,
Thanks for your thoughts. I’m not suggesting starting from scratch, so you being not sure is exactly correct. The approach I’m suggesting is to build e-commerce in the context of a CMS, so based on that it would be scratch-building the e-commerce portion but maintaining the approaches taken in the CMS in question.
I have some issues with Magento from a developer’s perspective that would lead me to a differing opinion on that, as well as the recent licensing changes, but perhaps that’s the fodder for another article.
Thanks for writing!
Liz
25. Jun, 2009
Hi Fred — I read with interest your comments; I am working with a wholesaler moving to ecommerce for the first time, and we are looking for a robust solution that will scale with our large consumer product line (footwear) and also enable us to be very brand-driven, and continue to support our retailers. Oh, yes and international site development as well, to move to ecommerce in a few years.
We are looking at combining Magento as our ecommerce engine and product content management with Expression Engine for content CMS and front end brand identity. the developers are talking about buildng a bridge (yikes) between the two, and having the admin tool for EE to run all of the product and content management, including the e-commerce.
What do you see as the limitations of this strategy? Any good things about it? And do you have other recommendations for a mid sized company like my clients that would enable us to grow into the potential we have as a direct to consumer player? A tall order, I know, but love your thoughts.
Fred
26. Jun, 2009
Hi Liz,
Thanks so much for the thoughtful comments! Regarding the bridging approach, I would just reiterate the unwieldy nature of working with two code bases and two completely different schema. Also, the typical bridges that exist out there for Magento are mainly limited to the exchange and synchronization of user account data, and so you would likely be heading into uncharted levels of integration to want to bring product management into EE. Are you biting off more than you can chew? Does the budget allow for the extra resources needed to bring this level of integration together? And of course, moving forward, how much support will be needed to maintain the package? I’m sure you are asking those questions already, otherwise we may not be discussing this
The good thing about this strategy is that in terms of project turnaround, it may be the only solution in the next several months that you can offer, and would at least allow you to get the brand in front of customers.
Here is an important question – has anyone on the dev team worked with Magento? If they are familiar with it and comfortable, then that is another advantage you have, but let me forewarn you that Magento in terms of packages is about as bloated and over-engineered a package as I have ever dealt with (and I have dealt with it for many frustrating hours). Put plainly, it is over-hyped and not developer-friendly. The database schema itself prints out to 9 pages and is extremely difficult to work with.
The major problem is this – is there an alternative in the open source arena? The answer is “not yet” but there is a tool in development that does exactly what I outline in this article. It is not in production yet but I can tell you that it will be within the year. For starters, take a look at http://www.typolight.org – this CMS is as good as (or better) than EE, but that is just my personal opinion, having worked with it since June of 2006. There is a full-featured e-commerce package coming out that is a seamless integration with TYPOlight this year and will have international support out of the box, just an FYI.
feel free to email me if you have further questions – fred@…
Plotting a Path To Killer Open Source E-commerce and CMS tools | The Head of Fred
03. Jul, 2009
[...] I was engaged in a wonderful comment by commenter “Liz” regarding my post “The Next Step in Small-Business Web Tools – Open Source/E-commerce Hybrids“. She left me some great comments and one in particular seemed better suited to an actual [...]
Marcin
05. Aug, 2009
Hi fred,
I’m big fan of TYPOlight and nice to hear that will new e-commerce system for this CMS. Can you describe little bit more about this? Is it based on any existing module like Catalog? (German e-commerce solution for TYPOlight is based on Catalog that’s why I’m asking). Or is it modul (modules?) writing from scratch by you? I’m really looking forward for this. What about licence?
Sorry for my english.
Fred
06. Aug, 2009
Hi Marcin,
Thank you for reading and commenting! Your English is excellent, it is better than my Polish, trust me on that!
The system does share some code with the Catalog module, but only in one backend tool. It does not need Catalog to run though – it is completely stand alone. It has several backend and frontend modules to it, for example
- shipping and payment module management on the backend
- email template and configuration management tool (contributed by Andreas Schempp (www.iserv.ch)
- store configuration tool for general store settings
- isotope file manager for product images and other media
- tax management module
- order management module
Frontend modules include
- shopping cart (mini and full)
- product lister (more on that later)
- product reader
- product options, completely configurable by site admins
- checkout
- customer address book mgmt
The license is LGPL for these. We’ve spent a lot of time making it designer and developer-friendly, and we’ve spent a lot of time making sure this integrates seamlessly with TYPOlight itself. Product categories are actually pages, the reason we did that is because we could then have categories integrated as part of navigation, as well as letting categories enjoy all the benefits that regular TYPOlight pages enjoy such as protection, etc.
In addition, we’ve done a lot of work with the GD library and image scaling is done when needed.
There is more to come as well. We have scratch built everything but the catalog code we started with (Andreas Schempp and I, and the project has been primarily sponsored by where I work, Winans Creative).
Other modules in progress are second-tier items such as pricing rules, we have a gift registry module that is a derivative of the base shopping cart model, and we also have payment gateways for Authorize.net, Postfinance (swiss payment tool), and Paypal.
There is much more in terms of features that I can’t cover here, especially when it comes to media management and our general integrative approach. If you know how to use TYPOlight, there is nothing new with Isotope E-commerce to learn.
So, we are VERY excited about this, it is a paradigm shift for e-commerce and will present more flexibility that we can forsee at this time by virtue of its design. The skills needed to use it are no more than what you already have. Although you can go deeper into it, the most common items are right at your fingertips, so to speak.
Marcin
12. Aug, 2009
Hi Fred,
It’s sounds very promising! Today i saw on Twitter that Beta will available in September. Great! I’m waiting for this.
Best regards and keep your good work guys!
Mark Aaron Murnahan
19. Aug, 2009
Oh, you mean like … oh, what do that call that terrible beast … Miva? ROFL Kidding!
I have a good buddy who always preaches the benefits of Plone and Zope … I call it “Plope” just to razz him.
The fact is that these things can co-exist, far beyond using WP for content and osCommerce for ecommerce … or throwing an instance of TinyMCE into the mix of some random shopping cart.
It can happen … and it does happen. It just requires an organization who cares more than to hear the first guy who raises his hand and says “Here is a good way to make it look cool without spending too much money.”
Companies are cheap these days, and very short-sighted. When they look at a huge return like the old days of a Dot Com Lamborghini and a huge ROI in the first quarter, they kill the chance of doing something right, sustainable, and future-oriented.
Now, a system that handles idiots in the boardrooms, geeks who want to take pride in their work, and CFOs who can “get it” enough to produce the budget for it … then we have something.
That is my rant. Cheers!