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!

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!

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.

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.

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@…

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.

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!

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.

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!