Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Selling Online with Drupal e-Commerce

samzenpus posted more than 6 years ago | from the read-all-about-it dept.

Programming 68

Michael J. Ross writes "Many Web developers wish to create e-commerce sites that also support collaborative editing of content, community forums, and other features that can increase traffic to the sites. But most shopping cart products do not include those capabilities, or, if such third-party add-ons exist, they may be quite limited in functionality. Similarly, most if not all content management systems (CMSs) lack native e-commerce capabilities. Yet that barrier is being overcome, because a handful of e-commerce modules have been created for the most popular CMSs. Perhaps the most promising pairing, at this time, is Drupal and the e-Commerce module — a combination covered in the book Selling Online with Drupal e-Commerce by Michael Peacock." Keep reading for the rest of Michael's review.This title was published by Packt Publishing on 31 March 2008, under the ISBNs 1847194060 and 978-1847194060, and is a recent addition to their growing lineup of books focusing on Drupal and Joomla. The firm hosts the book's Web page, where readers can download the sample code, submit feedback, post a question about the book, read an online excerpt, and download a sample chapter (number 8) on "Creating a Better Selling Experience," as a PDF file. In addition, readers can purchase the handy e-book version, which contains everything found in the print version.

The first chapter serves as an introduction to Drupal and the e-Commerce module, and also explains how to download the two of them, as well as the additional module (Token) upon which the latter depends. The author explains the purpose of each area within Drupal's "Site configuration" section, and what changes the reader should make, if any. Also, he provides the background story for the sample e-commerce Web site that is built throughout the book — in this case, a dinosaur model shop. It should be noted that the diagram on page 6 does an effective job of explaining the basic idea of how a CMS works (better than the similar figures seen in other CMS books), and it is followed by an explanation of what e-commerce is. However, it is doubtful that any developer who purchased this book would need to be told what are CMSs and e-commerce.

In the second chapter, the author briefly reviews the steps for adding content and navigation to a Drupal-powered site, by adding pages and menus, respectively. Also, some additional modules are enabled, for creating a contact form and a blog, for the sample site. Up to this point in the book, readers will have become accustomed to the author explicitly guiding them through the steps necessary for creating the sample site. Thus it may come as a surprise to such readers when they see the second figure on page 40, showing the navigation menu, including new sections for dinosaurs and the museum, and a link to a contact page. The two new sections were briefly mentioned three pages earlier, but the steps for creating them were not; the steps for adding the contact page link were apparently not mentioned anywhere. However, any experienced Drupal developer should have no difficulty figuring out how to add these navigation menu items.

With the third chapter, the book shifts focus from Drupal basics to implementing an e-commerce site. Aspects of running an online business — such as site accessibility laws, legal issues, and privacy laws — are mentioned, though readers outside of the United Kingdom will most likely not be pleased by the UK-centricity of the material. Other topics covered include product types, groupings, details, photos, and advertising, as well as customer service.

In Chapter 4, readers learn about the e-Commerce product types and their corresponding modules, and how to add products to the store catalog — including specialized types of products, such as apparel, services, and bundled products ("parcels"). Chapter 5 briefly covers users, rules, permissions, settings, rules, registration, e-mail messages to users, users' pictures, taxonomy, requiring registration, customer management, user orders, contacting users, and adding your business's staff to your site. It also touches upon taxonomy and how to use it for controlling user access to content. But the author fails to explain why this is needed for the online store. Providing such a rationale up front is especially important when asking readers to work their way through potentially daunting subjects such as taxonomy, and implementing them in their own test sites, if they are following what the author is doing.

The sixth chapter begins with an unneeded review of the themes built into Drupal version 5.x, with even more space taken up describing three red-based color schemes. This is followed by a discussion of how to modify whichever of those themes is enabled, and, very briefly, how to create a new theme. In this chapter and many others, the author frequently reminds us that the hypothetical client, Doug of Doug's Dinos, is "really pleased" with the "great looking site." Readers can judge for themselves just how great is the site's design. Admittedly, in a book such as this that does not focus on Web design, a sample site can be quite basic. But the constant praise is unwarranted.

Allowing customer checkout and payment are critical to any e-commerce site, and those topics are explored in Chapter 7. The topic coverage is fairly complete, though occasionally the author does not make clear where in the Drupal administration section the reader will find the particular topic under discussion, e.g., the global anonymous purchase policy. Chapter 8 offers a lot of valuable information, including how to: add shopping cart and search elements to every page, automatically create user accounts, add images to product listings, offer discounts based on customer role, provide coupons, allow bulk purchasing, set up auction and donation products, and automatically adjust charge prices based on various conditions.

Chapter 9 delves into the particulars of calculating taxes and shipping costs, as well as accepting payments through various gateways, including PayPal, which is explored in detail. The only part that will be misleading to readers, is the claim that PayPal's IPN "pings" your server for each customer transaction. Actually, their server does not ping yours, but instead posts transaction data that you can use for updating your online database.

Chapter 10 presents a number of modules and techniques for making an e-commerce site more secure, and also covers domain name, Web hosting, and site maintenance issues. The security modules discussed are definitely worth considering. Some readers may be confused by the Backups section of cPanel mentioned by the author, since not all cPanel installations offer it.

The last two chapters of the book address invoicing, CRM, and marketing one's site. The discussions of search engine optimization, viral marketing, newsletters, etc., are quite cursory, and readers interested in those topics would fare better by consulting books, online articles, and other resources that are much more thorough. The chapter's topic that will probably be of most value to e-commerce developers, is the demonstration of how to significantly customize the layout of invoices, using CSS. The book's sole appendix explains how to install WampServer.

All the chapters conclude with brief summaries, which, without exception, are a waste of space — especially considering the brevity of most of the chapters. The old oratory principle of "tell them what you're going to tell them; tell them; tell them what you told them" may be terrific for speeches, but not for books. That is primarily because someone in an audience listening to a live speech does not have the luxury of looking into the past to hear a portion of the speech again, nor of looking into the future to anticipate what the speaker will say next. Readers of books, on the other hand, can of course jump backward and forward quickly to review or preview material, as needed.

The quality of the book's writing is noticeably weak, with countless awkward phrases and run-on sentences. Some are downright puzzling, e.g., "Thanks for your custom!" (page 125); did the author mean "order?" Throughout the book, one finds a remarkable underuse of commas, frequent mixing up of "that" and "which," misplacement of commas and parentheses, misuse of commas in place of semicolons and even periods (e.g., page 124), semicolons in place of colons, and missing hyphens from adjective phrases. Most noticeable — and at times laughable — is the excessive use of exclamation marks, reflecting a common misconception that they jazz up otherwise dull material. For example, page 49 contains three completely unnecessary exclamation marks, not counting the two contained within a customer testimonial. In addition, the book contains several errata, such as: "loose" (should read "lose"; pages 8 and 195), "leads customers" (should read "leads to customers"; page 57), "products" (should read "product's"; page 62), "customers' role" (should read "customers' roles"; page 88), "to mentioned" (should read "to mention"; page 131), "its does" (page 159), "If a more" (should read "If more"; page 202), "businesses" (should read "business's"; page 221), and many more.

An additional blemish of the book, albeit minor, is that there is little consistency in how the author describes to the reader the navigation steps for going to a particular area of Drupal administration. Sometimes he presents a breadcrumb-style menu path, starting with the highest level menu item. (The majority of readers would probably find this to be the most logical format.) On other occasions, he reverses the order and describes it narratively. Least useful is his listing of the URL, such as "http://localhost/drupal-5.7/admin/users/roles," which may not even match the Drupal root URL that the reader has set up in their development environment.

Despite the aforementioned problems, Selling Online with Drupal e-Commerce is a welcome addition to the growing list of more specialized Drupal titles, and is currently the premier resource for anyone who wishes to use Drupal and the e-Commerce module for creating a virtual store.

Michael J. Ross is a Web developer, writer, and freelance editor.

You can purchase Selling Online with Drupal e-Commerce from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

Heh (0, Flamebait)

AndGodSed (968378) | more than 6 years ago | (#24278029)

Some of the grammar in this review looks like it came from a google translated page...

So.... (0, Flamebait)

dedazo (737510) | more than 6 years ago | (#24278045)

The book pretty much sucks then. What about the actual software? Is anyone using it in real-world situations?

I've never heard of this Drupal module, to be honest.

Already slashdotted (4, Funny)

will_die (586523) | more than 6 years ago | (#24278161)

The site http://localhost/drupal-5.7/admin/users/roles [localhost] , is already down and cannot be found.

Re:Already slashdotted (3, Funny)

Dekortage (697532) | more than 6 years ago | (#24278263)

And wouldn't you know it -- http://127.0.0.1/drupal-5.7/admin/users/roles [127.0.0.1] is down too!

Re:Already slashdotted (1, Funny)

Anonymous Coward | more than 6 years ago | (#24278697)

Thanks a lot assholes, my machine has been Slashdotted.

Re:Already slashdotted (1)

cvos (716982) | more than 6 years ago | (#24279823)

at times laughable - is the excessive use of exclamation marks, reflecting a common misconception that they jazz up otherwise dull material.

Maybe! Drupal! Ecommerce! Is! A! Fork! Of! Yahoo! Shopping!

So... (1)

omuls are tasty (1321759) | more than 6 years ago | (#24289195)

you're saying it's not because of the DNS vulnerability?

Re:Already slashdotted (1)

redGiraffe (189625) | more than 6 years ago | (#24279759)

works fine for me..

Re:Already slashdotted (0)

Anonymous Coward | more than 6 years ago | (#24282117)

Gasp! So is http://0177.00.00.01/drupal-5.7/admin/users/roles and http://0x7F.0x0.0x0.0x01/drupal-5.7/admin/users/roles !

Teh interwebs is being slashdotted!

Re:Already slashdotted (1)

theTrueMikeBrown (1109161) | more than 6 years ago | (#24289711)

I am prepared to be modded offtopic...

In response to your signature:

I am Michael Brown, you insensitive clod!

old hat (4, Informative)

ne0n (884282) | more than 6 years ago | (#24278191)

problem is, Drupal ecommerce (and ubercart, et al) don't run on Drupal's current stable release. And Drupal 4/5 leave a lot to be desired.
I question the relevance of a book written about outdated, unsupported ecommerce tech.

Re:old hat (0)

Anonymous Coward | more than 6 years ago | (#24278969)

Yes, but the Ubercart devs are working on getting it ready for 6.x and plan to have it available for Drupalcon. I haven't tried it yet, but apparently the development version (Bazaar) is working and running fine under 6.x right now. Of course it's not something I'd use on a production site.

All that info is available in the Ubercart forums.

Re:old hat (2, Informative)

-noefordeg- (697342) | more than 6 years ago | (#24279541)

What are you talking about?
Drupals current stable releases are 6.3 and 5.8.

I, and probably many others, would appreciate you mention at least some of all those missing features in Drupal 5.8.

I have been involved in several e-commerce sites developed with Drupal 5.8 and UberCart ( http://www.ubercart.org/ [ubercart.org] ) and we really don't find much functionality missing. Actually, the Drupal API ( http://api.drupal.org/ [drupal.org] ) and available modules is far beyond anything else I've worked with.
Drupal + UberCart is really really good. There is nothing else to say about that.
Developing multi-language e-commerce sites, which conforms to XHTML and CSS standards, with user friendly AJAX enhanced functionality, supporting large number of products (2+ millions) for a large number of visitors, with different payment options is pure joy with Drupal and UberCart.

UberCart is an alternative e-commerce solution for Drupal which is beginning to really stand out from the crowd.

Everyone is entitled to their opinion, but it wouldn't hurt to back up your opinion with some facts/observations.

Re:old hat (2, Informative)

e03179 (578506) | more than 6 years ago | (#24280199)

IAADF (I am a Drupal fanboy) and I've noticed that when posters in the Drupal.org forums suggest features that aren't found in Drupal core or in the 3rd party .module's, they are often told that "This is open source software. You want that feature? Go write it".

You've got to admit, posting in the Drupal.org forums is a crap shoot. Sometimes your post won't get a reply. Sometimes you'll get heckled and told to go back to WordPress or Joomla. Sometimes you'll get pointed to 3rd party .modules that do half of what you want and you are told to code the other half. And sometimes you'll get pointed to yet another feature request that someone has made years ago that may or may not have the solution you seek.

I wish Drupal.org was better organized. It's a mess. Heck, they've recently removed D.org's own SEARCH function and have been encouraging people to search D.org by using Google. There's no way to track threads (even though .modules exist to allow this) so people simply type "SUBSCRIBE" to feature requests and bug reports in hopes that they'll be able to follow the thread through the /tracker feature.

The Drupal CMS system is getting more and more robust and gaining more and more attention. I think it's time that the Drupal admins realize that they aren't just managing the Drupal CVS, but also the Drupal community...to include User Experience on their website.

It sounds like your interested in that. How about stepping up? ;)

Re:old hat (2, Insightful)

nostriluu (138310) | more than 6 years ago | (#24280247)

The whole problem with Drupal (well, the main problem, every popular software of any size is going to have lots of problems) is the project leads' refusal to make any kind of real API. With every major release of Drupal, modules become orphaned and existing sites get harder to support or upgrade. Because Drupal uses a "hook" system, and PHP (with no data typing), and there are no unit tests, it's really, really, really difficult to tell when things are broken. I've seen evidence of this again and again as even core functions aren't properly upgraded, with only passing warnings letting users know something is terribly wrong.

At least if they'd use an API for core functions this problem would be partially mitigated. They've been talking about an API for years, but no one wants to do it, and to be honest I think this suits the people at the top of Drupal (as opposed to everyone else) just fine - it's certainly not a high priority for them.

Re:old hat (1)

ben there... (946946) | more than 6 years ago | (#24284241)

The whole problem with Drupal (well, the main problem, every popular software of any size is going to have lots of problems) is the project leads' refusal to make any kind of real API.

At least if they'd use an API for core functions this problem would be partially mitigated. They've been talking about an API for years, but no one wants to do it, and to be honest I think this suits the people at the top of Drupal (as opposed to everyone else) just fine - it's certainly not a high priority for them.

What's this, if not an API? api.drupal.org [drupal.org]

The API is supposedly stable for each major version number, and even as a not-very-involved Drupal developer and Drupal user, reading the API changes [drupal.org] and updating other author's modules for them on the occasions they've needed the help has been a breeze.

Re:old hat (1)

nostriluu (138310) | more than 6 years ago | (#24287627)

That's documentation, not an API. In typical Drupal fashion, they've fudged terms. With the system of hooks, they've basically turned everything upside down, so everything becomes recursive (ones of those things people try to avoid in programming) and there is nothing like a simple oo or functional application programming interface. Most of the time when you're programming in Drupal, you're programming in a switch, which is another thing programmers like to avoid.

And it's true they have been releasing long lists of changes between releases (it's amazing how much they change between every single version), but as I said, with no real API, using an untyped language, and no unit tests, you're basically relying on eyeballing your code to make sure it's ok.

Re:old hat (1)

ben there... (946946) | more than 5 years ago | (#24301475)

With the system of hooks, they've basically turned everything upside down, so everything becomes recursive (ones of those things people try to avoid in programming) and there is nothing like a simple oo or functional application programming interface. Most of the time when you're programming in Drupal, you're programming in a switch, which is another thing programmers like to avoid.

I don't understand what you're trying to say about "programming in a switch". Nor do I know what you mean by turning everything upside down, so I can't comment on those.

Aren't "hooks" essentially "mount points", to borrow a term from plug-in architectures, which seems to apply just as well to Drupal modules? But instead of subclassing like you would with mount points, you have to create a function with a specific name. It's not ideal, and seems to be a limitation of the underlying language, PHP.

Django on Python is likely much more elegant, in that they use a very well defined Model-Template-View architecture and a much better OO-language, but unfortunately they do not have a mature enough project to have all the modules you need out-of-the-box like Drupal does. But compared to the PHP-based alternatives, Drupal is downright beautiful. A Python-based Drupal with many of the ideas from Django would probably be best, if it existed.

Re:old hat (1)

yelvington (8169) | more than 6 years ago | (#24286235)

API: http://api.drupal.org/ [drupal.org]

Unit tests: http://www.lullabot.com/articles/introduction-unit-testing [lullabot.com]

Upgrading cues: http://drupal.org/project/coder [drupal.org]

Re:old hat (1)

nostriluu (138310) | more than 6 years ago | (#24287673)

See my reply to ben there (http://slashdot.org/comments.pl?sid=620663&cid=24284241)

Re:old hat (1)

burbilog (92795) | more than 6 years ago | (#24286569)

Yes, that's the main problem. We had to retire one of our sites because it was made in old drupal and old custom modules became broken in version 5. We did not have manpower to modify them and it was easier to reimplement it in APEX. Also Drupal is not flexible enough, Oracle APEX could run circles around it. Yes, I know it's not open source, but we use APEX for some years and it's waaay better than any open source tool around.

Re:old hat (1, Informative)

Anonymous Coward | more than 6 years ago | (#24283195)

Ubercart just this past month released 1.0 and it will be available for Drupal 6 the next 2 months (I work with the core devs) once it passes all the tests. The problem has been that Drupal has kept up a very rapid core development pace and has broken a lot between major releases. There is chatter about Drupal slowing down core development pace which would help out 3rd party module developers.

I can't speak about e-commerce's progress towards Drupal 6 compatibility but Drupal 5 is not yet obsolete so this book isn't entirely outdated.

Re:old hat (1)

abandonment (739466) | more than 6 years ago | (#24284479)

Drupal 6 is absolutely unsupported by the rest of the community so far, so it's a nice 'playground' more than anything worth actually developing a site on. Until the majority of Drupal 5 modules work with 6, Drupal 5 will continue to be 'the way to go' for the vast majority of users.

Unfortunately I didn't figure this out until well after beginning to experiment with 6, but once we got rid of that and went back to 5, Drupal has been a HUGE improvement over the nightmare that zencart and open-commerce are.

Still not perfect, but a billion times better.

Re:old hat (1)

yelvington (8169) | more than 6 years ago | (#24286727)

Drupal 6 is absolutely unsupported by the rest of the community so far,

We are continuing to base our site development work on Drupal 5 at this point because a couple of key modules aren't ready for 6.

But there are more than 700 Drupal contributed modules with released versions for Drupal 6, and that's far from "absolutely unsupported."

The biggest barrier to Drupal 6 implementation has been the Views module, which many of us regard as a requirement. The developer chose to undertake a complete rethink/rewrite rather than porting the existing version. Views 2 is now at Release Candidate status. Everything will be better in the morning.

Ubercart (3, Informative)

future assassin (639396) | more than 6 years ago | (#24278193)

Never used the e-commerce module but I'm currently building two stores using Ubercart http://www.ubercart.org/ [ubercart.org] and even though its still a fairly new module its quite nice and usable for an e-commerce site.

Re:Ubercart (2, Informative)

gregmac (629064) | more than 6 years ago | (#24279505)

I've been using it for a small e-commerce site, and it's by far the best online store I didn't write from scratch. From and end-user perspective, it's very easy to use.

What made me initially choose Ubercart over Drupal e-commerce is the checkout process. Two easy features that really can make or break the store: shipping estimate on the cart page (BEFORE entering any personal information besides postal code/country), and not presenting checkout as having to "sign up" for an account (even though the only difference is really entering a password or not).

Drupal is a great platform to build an online store on. First of all, an online store is generally going to be linked into a bunch of content that should be part of the content management system. Maybe you sell widgets, and you have a content page describing the widgets. Doing this all in Drupal makes it dirt simple to have a section on all your widget-related content pages that show all your current widgets products that are on sale/featured/etc. It also lets you link from the widgets products back to a page that talks about what widgets do.

Secondly, it makes products very powerful. Using CCK, you can customize product nodes to have extra fields. For example, if you have a variety of widgets you sell in various lengths, you can create a new "widget" product type, and add a length field to it. Now when someone creates a product, they have a defined place to enter in the length. This shows up consistently on the product page template. It can also show up in product lists, and you can even make search forms that let you search for a specific value.

And the best part is this is all relatively easy. There is certainly a bit of a learning curve to it, but it is worthwhile to learn, as it is a heck of a lot easier to do than writing it by scratch yourself (I'm saying this as a 9+ year professional developer). It's also more flexible in some ways -- for example, if you also need a "width" field on that product, you can just add one with the GUI and then add a tiny bit of code to the product template (if you customized the template).

Yet Another Drupal Module Not Ready For 6.0 (1)

Electrawn (321224) | more than 6 years ago | (#24278255)

YADMNRF6 ? If I expended effort to come up with a funny acroynym. ... and congrats to the LDAP module for finally getting an Alpha out yesterday (July 20th) for 6.0.

Why is 6 so hard to code for? Why is the enterprise module development so lagging?

Re:Yet Another Drupal Module Not Ready For 6.0 (1)

eh2o (471262) | more than 6 years ago | (#24278775)

Drupal internals don't adhere to standard design patterns... its a mess and hard to program for at any version unless you have deep knowledge of the way it works.

My experience with D4 and D5 is that the contrib modules typically lag behind the core by about one year. I don't plan to touch D6 for another 6 months or so.

Re:Yet Another Drupal Module Not Ready For 6.0 (1)

Fred_A (10934) | more than 6 years ago | (#24279997)

Wasn't the module API supposed to be stabilised / standardised at one point (with 6.x or 7.x maybe) ?

This has been a long standing problem and was supposed to be addressed.

I don't care if it's good or not (4, Funny)

jollyreaper (513215) | more than 6 years ago | (#24278283)

I don't want to know anything about a product that makes me think of tall black drag queens.

Reminds me of a funny conversation with a friend who doesn't follow politics closely.

friend: Man, I don't think the Dems have any good candidates running this year.

me: Yeah, but i know you won't go Republican.

friend: Hell, no! But there's one guy they all seem to be going on about, who is it, Rupal?

me: I think you're thinking about Ron Paul.

friend: What's the difference?

me: One's a tall, black drag queen, the other is a fringe libertarian candidate.

friend: Heh. What are the chances of either of them getting the nomination?

me: About the same.

Re:I don't care if it's good or not (0)

Anonymous Coward | more than 6 years ago | (#24288009)

Damn. I've been working with this software for a year and never once thought it sounded like, or reminded me of, Rue Paul. I hope this isn't going to be one of those situations where you hear a very stupid song in your head for days. I hate you for this...

Honest question. (1, Informative)

AltGrendel (175092) | more than 6 years ago | (#24278317)

I've never heard of Drupal [drupal.org] before. Is this another flavor of the month software package?

Re:Honest question. (2, Informative)

vux984 (928602) | more than 6 years ago | (#24278643)

I've never heard of Drupal before. Is this another flavor of the month software package?

No, I wouldn't call it that.

Its one of the larger and more popular open source CMS systems.
It is fairly widely deployed and used, and usually shows up in any comparison or discussion of current CMS options from the last few years.

Re:Honest question. (1)

AltGrendel (175092) | more than 6 years ago | (#24278707)

Thanks. I'll have to look into it.

Re:Honest question. (1)

LWATCDR (28044) | more than 6 years ago | (#24278715)

No it is actually a pretty major CMS. If you have no interest in Content Management Systems then it is very possible that you wouldn't hear about it.

Re:Honest question. (1)

Mouse42 (765369) | more than 6 years ago | (#24279157)

I've never heard of Drupal [drupal.org] before. Is this another flavor of the month software package?

ha, no, certainly not. I for one have been using it as my main CMS since 2004.

Re:Honest question. (3, Funny)

amohat (88362) | more than 6 years ago | (#24280429)

I've never heard of this Google.com

Is it some sort of startup web directory?

Hrm, maybe I'll look it up on Alta Vista. No, that would be a waste of time, as I pay per-minute for AOL dialup access. Grr, if Granny would just get off the phone first!

Maybe post a embarrassingly lazy question on the newsgroups! I'll make other people do all this searching for me! There's an endless supply of well-intentioned fools willing to coddle me! There's no downside!

Integrated fraud? (1)

Animats (122034) | more than 6 years ago | (#24278353)

Social networking, content management, Web 2.0, and e-commerce in the same program! Think of the fraud opportunities!

"Creates a direct connection between your wallet and us!"

Don't buld your own e-commerce site. Just don't. (4, Insightful)

realmolo (574068) | more than 6 years ago | (#24278461)

It gets very elaborate, very fast. And there are TONS of security issues, and you will miss most of them. Not to mention that usability is a major concern, and will take a lot of time to get right.

Bite-the-bullet and pay one of the companies that specializes in e-commerce to do this for you. They have already worked out all kinds of issues that you don't even know exist. You and your customers will be MUCH happier.

Re:Don't buld your own e-commerce site. Just don't (1)

drinkypoo (153816) | more than 6 years ago | (#24278629)

ecommerce is one of the lumpier drupal modules. I'm not saying it's not possible to build sites with it, lots of people have done it. Just that it's not necessarily straightforward, and if you're not comfortable with PHP, you probably won't be doing much customization outside of theming. Which, come to think of it, depends pretty heavily on PHP too. It's been a long time since I played with the ecommerce module, so I won't comment on those experiences except to say that they were harrowing :)

Re:Don't buld your own e-commerce site. Just don't (1)

CastrTroy (595695) | more than 6 years ago | (#24278639)

I agree. Unless you want to be in the business of supporting and maintaining e-commerce solutions, this isn't the kind of thing you want to be building on your own. If you want to just sell stuff online, go with a package that's already made.

Re:Don't buld your own e-commerce site. Just don't (1)

dave420 (699308) | more than 6 years ago | (#24278757)

Or, you can split the store and the payment into two sections, letting someone else handle the actual payment side. There's nothing worse than an off-the-shelf ecommerce web interface.

Re:Don't buld your own e-commerce site. Just don't (0)

Anonymous Coward | more than 6 years ago | (#24279381)

As a webmaster (oh how I hate that title) who oversees three fairly busy (800-900 transactions per day)e-commerce sites and who has seen us go from build it ourselves to hosted solutions, I could not agree with realmolo more.

E-commerce is not one of those things that you want to be in charge of. Late night terrors, cold sweats, constant paranoia, if those things are your bag baby then go right ahead. E-commerce, like health care is a buy it don't build it sort of things for the saner among us.

Re:Don't buld your own e-commerce site. Just don't (1)

Tweenk (1274968) | more than 6 years ago | (#24280009)

In my country people prefer to pay by bank wire before the shipment. As such, there's no payment section in the stores. Another popular option is COD payment. The upside: web stores are straightforward. Downside: the e-commerce software written in the US is completely out of whack, because it assumes people will pay using credit cards or money transfer services. I whipped up my own web store, because removing things from Drupal or Magento or Zencart would take more time than writing it from scratch, and would probably be less stable. On top of that, localized versions of those systems universally use the shitty ISO-8859-2 encoding, which is supported neither by Windows (it uses cp1250) nor Linux (it uses UTF-8)...

Re:Don't buld your own e-commerce site. Just don't (1)

Bozovision (107228) | more than 6 years ago | (#24283895)

I think you will find:
- Drupal uses UTF8 by default
- Drupal has a robust multilanguage approach.
- Drupal includes a COD module and doesn't assume a particular payment flow.
- The Drupal developers are international. In fact this can be a downside since a good portion of the ec subsystem was developed in Australia (thank you Gordon), and at times it needs to be massaged. I'm thinking of tax issues.

IMO, having implemented Drupal-based ecommerce systems a few times now, I'd say that it's just short of ready for prime-time, and that this book is premature: a case of a publisher trying to climb on a band wagon. (I have no comment on the content of the book - I haven't read it.) I find that Drupal ecommerce is not yet slick enough that I don't worry about details that I shouldn't have to worry about, on the other hand I trust it enough to have implemented it for people who are not technical, and it does contain some really useful specialist product types.

The rate at which Drupal and subsystems such as the ecommerce subsystem improve means that the shortcomings will be fixed inside 18 months.

I'd say that the most important shortcomings are:

Drupal ecommerce does not yet have multi-currency options: it assumes pricing is in a single currency. There are modules which tell you pricing in alternative currencies, but the final bill is in the admin chosen basis currency. If you are in the US, buying from Japan, expect to see a bill in Yen on your credit card statement.

Drupal wants people to be logged in. Anonymous purchasing is a second-class citizen. IMO forcing users through a registration process before they can give you money is bad for business.

There is no nice standard for international addressing, and Drupal suffers from this. EC address management is not integrated with other address-orientated modules.

But...

It Drupal and EC are remarkably flexible. Anything can be a product. It's open source and you can add new stuff: I've built a number of modules including a specialist shipping module for Royal Mail shipping. I haven't found it to be a problem.

Someone complained about the lack of an API. In fact Drupal has a well-developed well-structured API. It's one of the reasons that it has coped well with growth. Try http://api.drupal.org/ [drupal.org] . The api is largely stable despite the established Drupal policy that backward compatibility is a nice-to-have rather than a given: I've used modules built for later versions which transferred to earlier versions without problems. Your mileage may vary, and of course things change as the system grows. But the changes between versions are well documented. I do think that the established callback injection points could be better documented. But I'd say the complaint about API was uninformed.

Re:Don't buld your own e-commerce site. Just don't (1)

Falc0n (618777) | more than 6 years ago | (#24280847)

It gets very elaborate, very fast. And there are TONS of security issues, and you will miss most of them. Not to mention that usability is a major concern, and will take a lot of time to get right.

This is why you use drupal. No one should be building websites, ecommerce or not, from scratch anymore. SQL injection, XSS, etc are reason enough. Thats why Sony BMG, AOL, MTV, etc are starting to roll out web platforms based on drupal. Using the Ecommerce package in drupal will insure security, and for the most part, usability.

Bite-the-bullet and pay one of the companies that specializes in e-commerce to do this for you. They have already worked out all kinds of issues that you don't even know exist. You and your customers will be MUCH happier.

Naw, you don't need to do this. Many people use oScommerce or Magento or many other F/OSS packages to do Ecommerce. The big problem with them is that they lack the CMS and customization that drupal allows. In fact the big problem with 'buying' some package is that many times your site and your 'store' will look like totally different websites, and you loose control over managing your data with other tools. While e-commerce can be inherently complex, it doesn't have to. Drupal E-commerce v4 is working to separate products, payments, shipping, etc so they don't have to rely on each other. Ubercart and ECv3 are very large projects because the assume that most people are buying many products, want multiple ways to pay for them, and need them shipped.

Re:Don't buld your own e-commerce site. Just don't (2, Interesting)

telbij (465356) | more than 6 years ago | (#24283631)

Drupal is my favorite open source CMS. Despite legitimate critiques it is an amazingly engineered piece of software; the customizability is unparalleled for a such a capable out-of-the-box package. Drupal makes many projects possible which would otherwise not be possible at all. Unfortunately Drupal is no panacea because all of this costs in terms of complexity.

This is why you use drupal. No one should be building websites, ecommerce or not, from scratch anymore.

No, this is why you use a framework. A good framework enables best practices with minimal overhead. Even a framework may be overkill because there are tons of websites that are extremely simple in nature, and maybe only need a dab of PHP here or there to add the necessary dynamic elements.

You use Drupal when you need a ton of boiler-plate functionality, and no budget to build from scratch using a framework. If you do have a reasonable budget you better think hard for several reasons:

  • Drupal starts you off with huge overhead. You will be running tons of code you aren't using from the get-go. You're basically starting off with quite a low ceiling.
  • You will be sacrificing design for ease of development. As customizable as Drupal is, there are still very simple user interface concepts that just don't mesh well with the huge engine powering everything. In these cases you are faced with the uncomfortable position of knowingly creating an inferior UI not because of some inherit complexity in the problem, but because Drupal has painted you into a corner.
  • Drupal makes it hard to optimize your database usage. Sure there are work-arounds, but consider the fact that many developers these days are trying to ditch relational databases in general because there are fundamentally hard to scale. It's still a common opinion despite the fact that the relational model is about as perfect a mix of flexibility and performance as you can get, backed by a theoretical basis that applies to all data in all domains. People are willing to throw out a huge amount of flexibility in terms of ad-hoc querying and data integrity because for many applications managing the data via hastily written application code is much easier than scaling an RDBMS. Drupal itself imposes many constraints that makes the relational model even harder to scale, and fundamentally ties your site to those assumptions so you'd better hope caching will give you the performance you need.
  • Drupal requires an expert to really make it sing. Without being intimately familiar with it, many things that Drupal was designed to do easily will be time consuming, even for a skilled PHP developer. With web frameworks, the issues you have to deal with are basically well known even across languages and platforms. The solutions may be different, but they are easy to learn if you understand the web because they all solve the same fundamental problems. Drupal on the other hand introduces a ton of concepts to allow for rapid and flexible development, but are not intuitive in and of themselves for a web programmer.

SQL injection, XSS, etc are reason enough. Thats why Sony BMG, AOL, MTV, etc are starting to roll out web platforms based on drupal. Using the Ecommerce package in drupal will insure security, and for the most part, usability.

First of all SQL injection is trivial to prevent. XSS is a little trickier, but is pretty manageable without a lot of mental overhead for the sufficiently paranoid developer. Of course things get trickier with XSRF and such. But look at the reality, if a security vulnerability is discovered in Drupal, pretty soon the bots are going to be out in force, and you'll be forced to upgrade. But what if your modules aren't compatible or you have other difficult to migrate upgrades? With a local XSS exploit at least someone has to write a custom script to attack you. Bottom line is you choose your poison.

Since 2005 I have been working almost exclusively with Drupal (starting with 4.5 I think) and Rails. Over time, Rails, even with it's rapidly changing API has resulted in much more maintainable sites. These days I'm very reluctant to take on any more Drupal sites because I am a design perfectionist. I have found preparing Rails estimates for clients to be much more reliable, and found the workflow with clients easier as there is a greater correspondence between what the client thinks will be an easy change to what actually is easy.

Re:Don't buld your own e-commerce site. Just don't (1)

Falc0n (618777) | more than 6 years ago | (#24284485)

No, this is why you use a framework. A good framework enables best practices with minimal overhead. Even a framework may be overkill because there are tons of websites that are extremely simple in nature, and maybe only need a dab of PHP here or there to add the necessary dynamic elements.

Drupal is (now) just as much a framework as it is a CMS.

# Drupal starts you off with huge overhead. You will be running tons of code you aren't using from the get-go. You're basically starting off with quite a low ceiling.

Not quite. the core modules are getting more and more efficient, cutting out everything that isn't basic content and framework code. It isn't CakePHP or Rails yet, but its still quite small.

You will be sacrificing design for ease of development.

False. With zen theme and drupal documentation, you have FULL CONTROL over every aspect of your website. With drupal 6, it gets even easier with Theme developer. My friend just started using drupal a month ago, with limited PHP and Zero drupal experience. He just finished up his gf's page: http://thelovebugdj.com/ [thelovebugdj.com]

Drupal makes it hard to optimize your database usage.

True, that is a tradeoff with -ANY- framework by default. However if you have the need for further database optimization, there are many documented ways to make drupal perform well. Instead of spending the budget on building a site from scratch, instead you can dedicate a portion of it in optimizing it. Remember, Popsci.com, MTV.uk, SonyBMG all run drupal.

Drupal requires an expert to really make it sing.

Depends on the size of the site. A small one as shown above doesn't require an expert, just some nights looking at documentation; which by the way, thanks to Lullabot, pingvision, Acquia, and others, drupal has some of the best documentation around. However, for bigger sites, you're already going to need experts to get it to do what you want. In the context of E-commerce, I'm CERTAIN you will have a more complete system, built in less time, if you go with drupal rather than building an ecommerce system in Rails. Sure, there will be features that a client will need, and will need to be added to the quote, but you'll be leaps and bounds further from the get-go than if you use a basic framework or build from scratch.

SQL injection, user login, search functionality, XSS, XSRF, user input verification, all are things that are annoying and need to be taken care of. I'd rather have a tested system with a workable upgrade path and spend my time working on the content I need to build the app.

Drupal used to be hard to upgrade, but these issues have largely been resolved in 5 and 6. If you haven't seriously worked with drupal since 5 came out, take a second look at drupal, its community, and evolving modules. Its quite impressive.

Re:Don't buld your own e-commerce site. Just don't (1)

telbij (465356) | more than 6 years ago | (#24289653)

False. With zen theme and drupal documentation, you have FULL CONTROL over every aspect of your website

Saying something like that demonstrates weak knowledge of fundamental software engineering principles. Every line of code and feature has a conceptual overhead to it. "Full Control" is just a marketing term. In reality you can always do anything you want, the underlying system merely encourages or discourages certain constructions.

Drupal chooses a content model, theming system, form system, and hook-based request processing that make a great deal of things extremely easy. But you don't get that for free. In order to generalize code to meet a wider variety of needs, the code itself must become more complex than any specific implementation of the functionality it is attempting to support in general. That's great if it does what you need, or if the customization you want fits easily into the existing model. However if it doesn't you have to deal with the complexity of an architecture that is not optimized towards your particular need at all.

but you'll be leaps and bounds further from the get-go than if you use a basic framework or build from scratch.

While that's true, additional development will be slower. Why? Because you can write very concrete code that does exactly what you need. For instance, I designed and developed a custom e-commerce store in about 30 hours in Rails. It imports 20,000 products from their inventory system database. Allows for wholesale sales to approved customers from a different database. Entire site is under 10 database tables. There is not one unnecessary feature in either the public or the admin interface. Further customizations would be quite easy as well as I have complete unit test coverage. If I want to completely change the order of the checkout process that would be the matter of a couple hours work.

I've had that exact requirement come up in a Drupal project and it was a nightmare. The e-commerce module is far too complex to go in and change any fundamental workflow. Sure, it was possible to set up a workflow that got the data into the database, but the user experience was horrible.

To be fair, frameworks also make choices that box you in... that is true of all code. However the philosophical difference is that pure frameworks in general tend towards solutions to more universal problems of web development, and those solutions tend to be smaller and scope and more independent of application code itself.

A review of the review (4, Insightful)

Red Flayer (890720) | more than 6 years ago | (#24278505)

The quality of the book's writing is noticeably weak, with countless awkward phrases and run-on sentences. Some are downright puzzling, e.g., "Thanks for your custom!" (page 125); did the author mean "order?" Throughout the book, one finds a remarkable underuse of commas, frequent mixing up of "that" and "which," misplacement of commas and parentheses, misuse of commas in place of semicolons and even periods (e.g., page 124), semicolons in place of colons, and missing hyphens from adjective phrases. Most noticeable -- and at times laughable -- is the excessive use of exclamation marks, reflecting a common misconception that they jazz up otherwise dull material. For example, page 49 contains three completely unnecessary exclamation marks, not counting the two contained within a customer testimonial. In addition, the book contains several errata, such as: "loose" (should read "lose"; pages 8 and 195), "leads customers" (should read "leads to customers"; page 57), "products" (should read "product's"; page 62), "customers' role" (should read "customers' roles"; page 88), "to mentioned" (should read "to mention"; page 131), "its does" (page 159), "If a more" (should read "If more"; page 202), "businesses" (should read "business's"; page 221), and many more.

The review seems pre-occupied with errors that were missed by the editors that do not reflect the quality (or lack thereof) of the writing itself. While the reviewer does touch on some serious issues (awkward phrases, run-on sentences), using over 10% of a review to harp on editorial gaffes is a waste of space. This is especially true considering that some of the "mistakes" are not mistakes at all, but instead, use of British English instead of American English. "Thanks for your custom!" is perfectly acceptable in England, it is equivalent to saying "Thanks for your business!" in the US.

In short, grammar Nazism doesn't belong in a book review, other than perhaps making a slight mention of it. I'm also very curious as to whether the review read a review copy, or a retail copy. Review copies are frequently filled with errors that will be caught later during final copy editing.

Re:A review of the review (0)

Anonymous Coward | more than 6 years ago | (#24279081)

bullshit. The care put into the editing and proofreading is very much a public example of the care put into the complete product including the writing - and the quality of and skill of the writer is made or broken by the grammar, spelling, English syntax found in his product.

Re:A review of the review (0)

Anonymous Coward | more than 6 years ago | (#24279393)

Not true. Complaining is perfectly appropriate. The care put into the editing and proofreading is very much a public example of the care put into the complete product including the writing - and the quality of and skill of the writer is made or broken by the grammar, spelling, English syntax found in his product.

And I prefer WordPress and the wp-e-commerce plugin in any case.

Re:A review of the review (0)

Anonymous Coward | more than 6 years ago | (#24279977)

You are 100% wrong about that. Having been involved with both sides of the publishing business for 20 years, I can say with complete confidence: You are wrong! The lack of editorial quality is a reflection of the technical quality. If the publisher did not want to be bothered to correct very basic grammar, they tend not to be as careful with the technical issues. Publishers often want to get the book out the door as quickly as possible and quality be damned.

Since they is no space limitations here as opposed to a magazine, I think it is worthwhile to have examples of why the reviewer thinks the editorial quality sucks. Coming from Packt, I appreciate it even more as I have personally seen a downward spiral in their quality, both editorial and technical. It's nice to have confirmation of my perception from somewhere else.

As for the "Thanks for your custom!" Americans tend to think that US English is correct as opposed to England English. Ludicrous, I know, but it's the truth. I'm an American, but I actually did know the phrase. I learned it from "The Prisoner".

Re:A review of the review (1)

gobbo (567674) | more than 6 years ago | (#24285817)

As for the "Thanks for your custom!" Americans tend to think that US English is correct as opposed to England English. Ludicrous, I know, but it's the truth. I'm an American, but I actually did know the phrase. I learned it from "The Prisoner".

That's saddening, because it means you didn't learn it from the vast body of texts known as "literature," though you appear to be literate.

Re:A review of the review (0)

Anonymous Coward | more than 6 years ago | (#24286863)

I was about 12 at the time and am almost 50 now. All modesty aside, I think it is pretty impressive for a 12-year-old to recognize the such subtle differences in the language and recognize that when the shop keeper said "I look forward to the pleasure of your custom", the world "custom" in that sentence and "customer", "customary", etc all have the same roots. So, in regards to your comment "That's saddening," you have my complete and full permission to blow it out your bloody arse.

Re:A review of the review (1)

kingduct (144865) | more than 6 years ago | (#24280513)

Whether or not the author(s) or the editor(s) are to blame, unclear language makes ideas harder to understand. The review was of the book and the ideas and information it conveys, and if those errors made the book harder to understand, then the complaints in the review are legitimate.

Re:A review of the review (1)

Red Flayer (890720) | more than 6 years ago | (#24280649)

You're right in some ways, but I'd still like to see the info on what copy he reviewed. Either the publisher is terrible (in which case, reviewer may be correct), or he got hold of a review copy... in which case the reviewer comes off as amateur at best.

However, given his complaint about "Custom", I'm taking every error the reviewer found with a grain of salt. I am not confident of his capacity to identify errors, even grammatical ones -- particularly since no context was given for them.

Fag0rz (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#24278541)

ShareG. *BSD is

Is "usable" good enough for e-commerce? (1)

VoyagerRadio (669156) | more than 6 years ago | (#24278841)

I'm having trouble (I wonder if IE7 isn't compatible with Slashdot's new format) posting this as a reply to the subject "Ubercart", but I'm hoping the poster of that comment will notice (and respond to) this. All else are welcome to response, of course: How do you mean "usable"? Is "usable" truly good enough in a site in which security and usability is of utmost importance? I'd just like for you to (please) explain your perspective of this term. I want to know if I can really expect to use an open source CMS like this to run a potentially excellent e-commerce site.

Re:Is "usable" good enough for e-commerce? (2, Informative)

criznach (583777) | more than 6 years ago | (#24281017)

I've rolled out sites using Xcart, Squirrelcart, Drupal Ecommerce, Drupal + Ubercart, and even Miva Merchant. Many of these packages work great "out of the box" for simple stores. Customizing and theming is where things go to hell. The commercial packages always seem to want to sell you the customizations and make it hard (or miserable) to do it yourself. The theming experience ranges from clunky custom template syntax (miva merchant) to logic embedded in the templates (squirrelcart). I set my projects apart from the competition by not using other people's themes. Every site is custom, which drives this point home... The Drupal approach to customization and theming is the best I've seen. Within the Drupal space, I found the Drupal Ecommerce module package covered in this book to be cobbled together and evolving too loosely. Drupal + Ubercart on the other hand is well supported and seems to have a plan moving forward.

Joomla! and VirtueMart (0)

Anonymous Coward | more than 6 years ago | (#24278853)

I've been playing with content management and e-commerce systems for years and my preference is Joomla! and VirtueMart. Joomla! is far more powerful and has a wider array of components, modules, mambots, and free themes.

Re:Joomla! and VirtueMart (0)

Anonymous Coward | more than 6 years ago | (#24279557)

Joomla ? powerful ? compared to drupal ?

Nice troll.

Re:Joomla! and VirtueMart (0)

Anonymous Coward | more than 6 years ago | (#24280185)

Joomla! is far more powerful and has a wider array of components, modules, mambots, and free themes

No ... full stop

Drupal.. (1)

AngryLlama (611814) | more than 6 years ago | (#24280105)

Ugh, it is alright. We adopted a project that ran on Drupal, but the old developers just didn't do it right. One problem about Drupal is it's performance - at least, for any project where you want very dynamic content (up to the minute). It really slows down then, especially if you have lot's of modules.

The module idea is OK, but it turns drupal into a single-paradigm framework.

Magento FTW (0)

Anonymous Coward | more than 6 years ago | (#24281309)

When 1.1 rolls out life will become much easier. I am sort of working backwards regarding the /. post but.... Magento has some CMS features for folks to edit content etc. I have found its never a good idea to mix and match scripts to add say a forum to something, especially when e-commerce is involved.

How's that for a run on sentence :)
N.

Another alternative in django - Satchmo (3, Informative)

crypie (111943) | more than 6 years ago | (#24283167)

Finding a good ecommerce package that's not written in PHP is a big pain. If you'd prefer to use Python and want to combine your store with CMS type functions you can use the Django framework along with Satchmo - http://www.satchmoproject.com

To be fair, I'm one of the developers but I figured I'd chime in with some alternatives if you don't like the current PHP-based offerings.

It would be nice... (1)

HardFocus (87842) | more than 6 years ago | (#24283289)

In light of the current Drupal release being 6.3, I hope this review will prompt the developers to shift priorities to getting a v6 compatible module [drupal.org] out for testing.

In the mean time, you might want to take a look at Ubercart [drupal.org] , another Drupal module.

KenticoCMS (1)

jrbirdman (1281118) | more than 6 years ago | (#24294049)

"most if not all content management systems (CMSs) lack native e-commerce capabilities."

Wrong.

We just started a large development project using KenticoCMS and, while we don't need it, it comes with e-commerce built-in.

If support for e-com is anything like the rest of the framework, I'd say it's outstanding. We've been beating up on Kentico for almost two months and haven't run into any bear traps yet.

.Net 3.5 compatible, full API, web and VS development environments, and good support.

It's not open source but still reasonably priced (~$5K US).

Very impressive.

And...no...I don't work for them. :)

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?