Drupal Commerce

I posted on Optaros website (EN | DE). Here is the copy of the post:

Drupal has always been good piece of open source software for content management. We use it at Optaros as one of the core components of OCentric. However, Drupal could never stand its ground as a solid e-commerce platform. With the new Commerce module Drupal is moving that direction.

Background

It hasn’t been long since online businesses realized that there are a couple of buzzwords to stick to: social media and SEO. Indeed, social sites are very good place to be and engage with (potential) customers, not mentioning that these sites enable word of mouth (aka viral marketing). Search engine optimization helps to save money and still allow showing up high in Web search results; normally it goes hand in hand with quality content to please not only Web crawlers but (potential) customers as well.

Actually, what this implies is that e-shop owners have very special needs that go something like this:

“I want to create a website where I want to display my products. There I’ll have discount campaigns. The information about them should be sent to customers, but not intrusively (otherwise it goes to spam) rather in a friendly fashion, e.g. somebody tells to friends about it. Then we can introduce some sort of reward system for those customers who brought other customers. Also we want people to come to our website often, therefore we’ll have a blog and a lot of information about products and the field in general. People should have their profile page and see what their friends are buying. We also expect that the shop is something like Amazon.com where you have ratings, comments, and recommendations.” And so on, and so on.

I come across similar business requirements very often. What it comes down to, as far as technology is concerned, is the following:

• Shopping cart
• Content management system
• Social stuff (integration to social networks or local features)

In Optaros parlance it rounds up to the triple of Community, Content, and Commerce (aka C3C). In fact that’s what gave birth to OCentric.

Drupal 6.x and Ubercart

Drupal is a content management system that allows creating community oriented sites very easily. The last piece of the puzzle – commerce – for quite some time was the Ubercart module. I don’t understand why it got so popular. Even for the simplest shop there was something missing.

Ubercart is almost a framework on its own: you need to learn it and live with its limitations (or hacks). My overall impression about Ubercart is that it has many features you normally expect from an e-commerce platform, but as soon as you start working with it you realize that it is a big work around.

Ubercart’s approach is – sell nodes. A node (before Drupal 7.x) is a basic content type. Ubercart is implemented in a way that products are node types, but it’s very unnatural to treat a product as a content type. This is probably the biggest flaw of Ubercart’s architecture (not sure if this has been somehow addressed in Ubercart 3.x).

While in many cases Ubercart does the thing – you can sell stuff on your Drupal site – I stumbled on so many problems that I almost lost hope to have a cool e-shop with Drupal. Just to list a few:

• It’s nearly impossible to customize the checkout page without hacking Ubercart’s core.
• Internationalization doesn’t work, because in Drupal a new node is created as a translation, which means a new product gets created as well.
• Presentation is not well decoupled from data model, therefore theming any part of frontend is very tedious.

Drupal 7.x and Commerce

Drupal 7.x introduced a lot of enhancements both for module and UX developers. The most famous one is the Field API. Having realized the benefits that Drupal 7.x brings Ryan Szrama, the creator of Ubercart, has launched the Drupal Commerce project.

Drupal Commerce is the reimplementation of Ubercart’s featureset on Drupal 7.x. It’s not a port of Ubercart 2.x but literally a reimplementation. You can see the video of Ryan presenting his work on the module at DrupalCon 2010 in Copenhagen.

The Commerce module heavily relies on native Drupal 7.x features, therefore there’s barely any risk that it will become a framework on its own. While Drupal 7.x remains a content management system, it allows for more generic entities than just content. For example, products, order, order line items can all be first class citizens in Drupal 7.x. Therefore the Commerce module is architected in a way that e-shop owners can sell products, without pretending that a node content type is a product. Moreover, the data model is decoupled from presentation, and multilingual shop is no longer an issue as it was in Ubercart.

What makes the Commerce module even more powerful and flexible is that it depends on several great modules (Address Field, Entity API, Rules, Views). For example, Views – almost everything visible in Drupal Commerce is a view. That means you can switch it on/off or customize easily. This is invaluable for checkout and shopping cart pages.

Summary

In version 7.x Drupal has become quite a generic framework, sort of entity management system, that has built-in content and community features. The Commerce module plugs in very nicely into this framework and solves a lot of issues of its predecessor Ubercart. Given that many businesses need to have content, community and commerce in one, Drupal 7.x may become an option as it matures.

Magento and Drupal Integration

There are numerous ways to integrate Magento with Drupal. Here I will share my experiences while working on that with very smart people at Optaros. I don’t take credit for all the points in this post, because they are the product of the whole team.

The motivation for this kind of integration is the innovative look into where e-commerce is moving. To get a grasp of it look at OCentric. To keep it short, content is free advertisement for products. It allows customers to get more input about products and provides the meat for search engines to index.

Briefly, there are several main approaches to integrate Drupal and Magento:

1. let Magento be the main component, while leaving Drupal just as a subcomponent
2. let Drupal be the main component, and have Magento as an e-commerce  module
3. let  both Magento and Drupal be main components

These are general approaches and each of them have different pros and cons. They will be further detailed by usecases, complexity, technicalities, etc. in the following sections.

Moreover, we will release much of the code as open source, so it’s not only a theoretical discussion here:)

Magento as the Main Component

This is probably the most acceptable approach in terms of implementation complexity. Moreover you can choose different level of complexity to implement.

The straightforward solution is to integrate on the service layer. Meaning that whenever we are on the e-shop product page we have to call a Drupal service to bring related content, for instance blog posts. The same holds for category pages. How to do that:

• Create a Drupal module that allows you assigning categories and products  to a content node in Drupal
• Implement XML-RPC client on Magento side and use it to talk to services on Drupal in order to pull the content (e.g. using view.get or node.get funuctions)
• Rewrite the category and product controllers on Magento to take the content from Drupal into account

There are some challenges in taking this way. They are mainly for those who want to implement features in a generic way. Specifically, whenever you add a CCK field or a feature like rating to a content type, you have some work to do on the Magento side. Namely, you need to modify layout and write templates to handle this additional data coming from Drupal. Hence it’s pretty cumbersome to use Drupal community contributed modules as you need to do some coding on Magento side for every new Drupal feature. This is quite easy when the content from Drupal is read-only, but as soon as you want commenting, rating, flagging, etc. it becomes an issue, because you need to not only redo rendering on Magento but also map the functionality.

A more complex path to take  is to integrate the whole Drupal rendering engine into Magento, however, this means a very tightly coupled architecture… Still, if you plan to use many many many of the Drupal features it may make sense. This will require writing a Drupal module for Magento that will adapt every Drupal core function to Magento. Could end up as a very complicated solution.

We chose the XML-RPC because of the given time frame and specific requirements. Normally a product or a category will be associated with a very specific set of content types, and therefore the fully generic solution may not pay off.

By the way there is already a CMS module for Magento as part of the core. And the question is why would one want to struggle integrating Drupal instead of using that CMS module? Moreover, with enterprise 1.6 version of Magento the module offers quite cool features. Some things from the top of my head to consider:

• Drupal has a solid community, and it is more stable and feature-rich than the Magento CMS module will ever be (of course it’s good as soon as you make the Drupal-Magento integration reasonably flexible)
• There is the CCK module that allows to very quickly add additional fields to a content type and make it available to the content producing team
• Content versioning, workflow, etc. is easy in Drupal
• …more ?

Drupal as the Main Component

This approach has been already taken by others and you can start digging for it here. We’ve tried out the available modules but didn’t stick with them… Basically there the implementation is based on the notion of synchronizing Magento products, categories, orders, etc.  into Drupal using a cron job.

In general, although Drupal-as-the-main-component approach in the end may give a lot of  flexibility, it may be too complex to implement. Imagine that the whole Magento frontend functionality needs to be rewritten for Drupal. Magento would then only be an e-commerce backend (the admin part) accessible via Web services. Of course you’d be able to use plenty of Drupal modules as well as flexible templating without any hassle, have better performance, and many other goodies but it just looks too expensive to implement.

Still, bringing only a part of Magento into Drupal makes a lot of sense (as in that module that synchronizes products and orders into Drupal using cron job). In this case it’s a decision to make whether the site is more about content or about commerce. When it’s about content, then you don’t really care about SEO for products, fancy business logic, etc.

Both Mangento and Drupal as the main Components

This is reasonable when the content will be displayed on the Drupal site and e-shop on the Magento site. Meaning that no proxying for content happens behind the scenes. So if a product has a blog post attached, then on the product page you’ll have a link (maybe even the post itself loaded using Ajax call) and clicking it will open a Drupal page with that blog post.

One of the challenges here is to maintain two different themes in order not to harm user experience. So that when the customer clicks on the blog link inside the product page the blog is displayed with the same look and feel as the shop. For that you can’t avoid coding on two different frameworks. Apart from theming SEO will have to be also maintained on both components.

Another challenge would be the ability to mix content with product information on the same page. Some kind of communication on the service layer will be necessary for that, which means that it’s not really reasonable to use this dual approach with such a usecase present.

It may make sense, however, to take this path when there are only some of the things to be shared between both components, e.g. users, and everything else is completely separate. For example, when a company has an e-commerce site, a customer community site, and a corporate site.

Additional Points for Integration

The end user display is only one part of the story. When you integrate this kind of monster systems to work seamlessly you get trapped with other things besides templating.

One of them is single sign on. A good thing to do here is to use CAS. Drupal already has the CAS module. Magento, however, needs one (we’ve been writing one). The good news that all the low level protocol implementation is available for PHP as open source.

Another thing is search. Independently of the integration approach chosen eventually you want to search for products and content in the same search box. This may become pretty challenging but it’s not impossible. We’ve got a proof of concept for the store front in Magento, where we leverage Solr search. It performs really well for our suggest box functionality.

There are numerous ways to integrate Magento with Drupal. And here I will share my experiences while working on that with very smart people at Optaros. asdfa sfd

asdf adsfasdf asdfasdf

Content Maganement with the Delegated Features as Services

As a friend of mine pointed out:  there used to be a server and many terminals, currently we have a bit more sophisticated terminals – PCs – and our big server is the Internet, where the apps are “on the cloud”. Nice analogy, and for me it makes a lot of sense. Are we really coming back to the terminal-server age but in a more advanced, i.e. distributed version?

Anyway I think that every feature in a Web application should be a service. Not a service in a sense of a mashup or SOA, but in a bit different sense.

Let’s take a simple example – Drupal. It’s a content management system. The power of it is that it’s extensible with new modules that are normally contributed by the community. These modules implement different features, such as rate the content, comment, spam filter. One of the nice ones that I really like is made by the Drupal inventor Dries Buytaert, called Mollom. In fact it’s a gluing module for the Mollom service, the service does spam filtering for your site. Specifically, when a person presses the “Save” button, the post first travels to the Mollom service, and then is checked if it’s spam, in case it looks suspicious the user has to fill in a CAPTCHA in order to save the post.

Now consider that all the modules in Drupal had the Mollom nature. That is the module would just be the glue for the service which lives somewhere on the cloud.

A simple content driven site based on Drupal could be quite easily implemented with what’s available out there. Consider a site for video sharing, kind of YouTube but maybe not so generic. At the core is Node – the most primitive content type made of title and body. And now let’s add features as services:

• Comment the node – Disquss.
• Control the spam – Mollom.
• Let users send the feedback about your video sharing service – Zendesk.
• Rate the content – Outbrain.
• Share the content – AddThis.
• Video upload and related features – Kaltura.

What else? Well there is one more piece that I think is very important:

• Social graph management. There are many services available out there starting with Facebook and finishing with QQ. These services expose APIs so there are also gluing modules for Drupal available. There is one caveat with social graph management. What features one wants to map, is it only friending or also status updates, picture sharing, etc. The purest approach would probably be to have a gluing module in Drupal that only uses authentication and friending features of the social service.

All in all, I strongly believe that paying for a feature as a service is better than paying for (re)implementing and maintenance of that feature. So it’s like SaaS but on a feature level, not the whole application (feature set).