×

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!

Book Review: Getting Started With Drupal Commerce

samzenpus posted about 6 months ago | from the read-all-about-it dept.

Books 37

Michael Ross writes "An online store is one of the most common use cases for a website nowadays. For those web developers and business owners who choose the current version of Drupal as a basis for such an e-commerce project, the canonical solution is Drupal Commerce. There are numerous online resources for learning Commerce, and yet for the longest time no printed book. Now we have Getting Started with Drupal Commerce, written by Richard Jones." Read below for the rest of Michael's review.This title was released by Packt Publishing on 24 September 2013, under the ISBN 978-1783280230. (This review is based upon a copy of the book kindly provided by the publisher.) On the book's website, visitors can read information about the book, including its table of contents, errata (none listed, as of this writing), and a sample chapter (the third one, on "Planning Your Store").

At first glance, 152 pages may seem wholly inadequate for explaining how to build an online store using Drupal Commerce. However, the table of contents suggests that, within the book's 10 chapters, the author addresses most of the critical topics: installation of the Commerce project, product catalog and classification, product data, shopping cart functionality, the checkout process, shipping services, taxes, order management, discounts, and coupons. A bonus chapter, "Extending Commerce," is not included in the book itself, but is available as a free download. (Readers should note that the URL provided in the book is incorrect, as it is missing the last underscore.)

Prospective readers do not need to know how to program in PHP or Drupal; however, a working knowledge of Drupal site building through the user interface, would be helpful. Anyone who wishes to follow the steps performed in the book for creating the example Commerce site, must have access to a Drupal 7 installation, with sufficient privileges to install and configure modules and set permissions, as needed.

The first chapter, "Introducing Key Concepts," as the title suggests, introduces the reader to the Drupal Commerce package, its overall capabilities, its submodules, and its dependencies. The module list (on page 6) is missing nine entries. Other than that, the material provides a good sense of what is to come. The first chapter, like all the others in the book, concludes with a brief and utterly useless summary. In this case, it states that the readers now "understand the motivation of the developers," even though that was not discussed in the chapter.

Installing Drupal Commerce is the subject of the next chapter. MySQL is listed as a requisite download, but actually MariaDB, PostgreSQL, and SQLite are equally usable. The author mentions Mac OS X and Windows as possible environments, but neglects Linux. Most of the chapter assumes that the reader has elected to use the Acquia Dev Desktop, and it consequently may prove frustrating to anyone who uses a different distribution to get started, or who installs the needed components individually.

As an e-commerce website is developed and (usually) later modified, the participants discover the value in all of the time and effort invested upfront in planning the information needed to track products, customers, payments, and other facets of the operation. Thus the third chapter is arguably one of the most valuable in the book, and should prompt site designers and developers to ask plenty of questions of their clients.

With Chapter 4, "Products," the author begins describing and illustrating the creation of the example website — in this case, a wholesale coffee and tea store based in the UK. At a critical juncture (page 35), the reader is instructed to enable "Commerce Backoffice (Commerce package)" and "Commerce Backoffice (Product package)," which is odd, since all four Commerce Backoffice submodules are in the "Commerce (contrib)" package, and none have those two exact names. Readers may presume that Commerce Backoffice and Commerce Backoffice Product were intended. It later turns out that "Commerce Backoffice content" was also needed. It is possible that the author was using an earlier version of Commerce that had different names, but that's difficult to ascertain because he apparently does not mention which version of Commerce is used in the book.

Chapters 5 and 6 demonstrate how to set up a shopping cart and configure the checkout process. The material should be comprehensible to the typical reader, and possibly a pleasant relief if his head is still spinning from the terminology soup encountered in the fourth chapter. The author explains how to use PayPal for accepting customer payments, and what permissions to set so that visitors to one's store can check out. Strangely enough, there is no discussion as to what permissions, if any, visitors will need for viewing products and adding them to the shopping cart. This might seem obvious to those experienced with Drupal Commerce, but likely will not be to neophytes.

The next two chapters show how to set up flat rate shipping as an option for one's customers, and how to apply a value added tax to each order, including the use of the Rules module for handling special cases flexibly, such as offering free or discounted shipping when the checkout balance exceeds a certain amount on any order not being shipped internationally. Lastly, readers learn how to set up order tracking.

The last three chapters demonstrate how to apply various tax rates to customer orders, how to manage orders on the back-end (such as setting status codes and viewing payment transactions), and how to define discounts and coupons that can be offered to prospective customers. The 11th chapter, on extending Drupal Commerce, should have been included in the published volume itself, as it certainly would not have pushed the page count beyond a reasonable level.

Throughout the book, almost all of the explanations are clear and straightforward, with the only exceptions being the puzzling reference to a "uid property" (page 10), which is not explained, and the use of several different phrases to describe product display nodes (in the fourth chapter). Unfortunately, all of the material apparently assumes that the reader will encounter no problems in trying to perform the same steps, because no troubleshooting resources are mentioned.

Aside from the aforementioned faulty URL on page 2, this book contains too many errata relative to its size: "out of the box" (page 5; missing three hyphens), "Apache based" (page 13; same problem), a space in the URL (page 15), "than [a] necessity" (16), "to [the] recently" (17), "Specifying [the] language" (25), "to [the] public" (27), "other than helper modules" (35), "Images/" (39; should be lowercase), "fairtrade" and "fair trade" (46 etc.; should read "fair-trade"), "doesn't" (47; should read "isn't"), "top-" (64), "blocks" (67; should read "block"), "rules" (73; should read "rule"), "as [a] page" (76), "as screen" (93), "field_tax_code" (106-107; should read "field_vat_code"), and "cine" (108; movies and Jamaican coffee have the same pricing?).

Like so many other books in the computer field, this one contains other flaws in the writing, such as semicolons used where commas are called for (e.g., page 5), and the mixing of singular and plural terms (e.g., page 28). However, its quality of writing is better than that of the majority of Packt Publishing's offerings.

Most of this book's screenshots are quite helpful, although a few might cause some confusion, mostly in that they do not reflect what the reader will see in her own installation. Consider only a handful of examples: An image field "Progress indicator" is mentioned (page 39), but not evident in any screenshot nor on the "Product image" edit page in my own installation. The screenshot on page 45 does not include the "Description" field that the reader is instructed to create, two pages earlier. A "Product: Tax code" field is shown (page 57), prior to any tax functionality being implemented in the narrative. The checkout web page is missing a field for an e-mail address (page 80). Alert readers will immediately wonder where in Drupal Commerce they would go to modify the billing fields, but that doesn't seem to be covered (but I could be mistaken).

One may level the charge that this book provides only the information needed to create a fairly simple e-commerce website. But that would be missing the point, because this book is not intended as an exhaustive exposition of the subject. Getting Started with Drupal Commerce is a valuable starting point for anyone interested in learning how to build online stores using Drupal 7.

Michael Ross is a freelance web developer and writer.

You can purchase Getting Started with Drupal Commerce from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

37 comments

Waiting (1)

Anonymous Coward | about 6 months ago | (#45123851)

I'm waiting for Bennett Haselton's review.

making money review (1)

Moblaster (521614) | about 6 months ago | (#45128813)

Here's my review... after using Drupal extensively on several projects, I can tell you the best way to make money with Drupal is not to use it in the first place. It's absolutely amazing how quickly trying to do anything even remotely interesting in Drupal turns your codebase into a nightmarish, unmanageable mess. Well, at the least first six time you build a Drupal website. After that you'll have learned enough to realize the investment will never quite pay off. You might as well code up a site from scratch in PHP, Javascript, jQuery and HTML/CSS. You'll have the same problems putting it together, but at least you'll be able to find developers who can maintain it without a four month straight vertical learning curve to the land of 35%-of-normal productivity. Ok, rant over. Drupal lovers can mod me down now. But from my perspective, the only people who should be loving Drupal are consultants getting paid by the hour. Because it's one heck of a top-dollar billable-hour generator.

Re:making money review (1)

hazah (807503) | about 6 months ago | (#45134203)

There's one of you retards in every thread... If you cannot put a Drupal website together, you should find a more suitable profession. If you think you can do that type of user registration, permission and access management, theming, content and extension management from scratch, you're deluded. I'll take Drupal over your barely tested shitpile any day. Kthanxbye.

I don't approve. (-1)

Anonymous Coward | about 6 months ago | (#45123985)

I don't approve of trying to monetize the internet. Technology should be appreciated in it raw, purest form. Copper and silicon, baby.

Re:I don't approve. (2)

Steve_Ussler (2941703) | about 6 months ago | (#45124659)

is that Richard Stallman posting as an AC? :)

Re:I don't approve. (0)

CRCulver (715279) | about 6 months ago | (#45124777)

Richard Stallman has absolutely no problem with people making money with software, provided their business model doesn't involve keeping the source to themselves. You'd think that Slashdot posters would have a better understanding of the man than this ignorant caricature.

Re:I don't approve. (1, Troll)

Steve_Ussler (2941703) | about 6 months ago | (#45124881)

:::Richard Stallman has absolutely no problem with people making money with software, provided their business model doesn't involve keeping the source to themselves. That is his view. Why is he more correct than those who have a 180 degree opposing view? :::You'd think that Slashdot posters would have a better understanding of the man than this ignorant caricature. Part of the problem is that Stalman is to a degree, has a very alienating personality that has not endeared him to many people. Right or wrong, that is the reality.

Re:I don't approve. (0)

CRCulver (715279) | about 6 months ago | (#45125035)

Why is he more correct than those who have a 180 degree opposing view?

Who said he was right? But before deciding whether he is right or wrong, one ought to understand what he is arguing for.

Part of the problem is that Stalman [sic] is to a degree, has a very alienating personality that has not endeared him to many people.

Regardless of how odious Stallman's personality is to many, you'd think that on a news for nerds site that historically attracts people clued up about the Free Software debate, people wouldn't post the misunderstanding that Stallman is anti-money-making.

What it doesnt cover is speed. (3)

Lumpy (12016) | about 6 months ago | (#45124087)

Last time I tried it, Drupal was a major processor hog. you were doomed if you had shared hosting instead of a dedicated box in the rack. Has this changed? has drupal fixed all the code so it's a lean and mean speedy system now?

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45124099)

The fuck? Were you trying to run it on a VIC 20?

Re:What it doesnt cover is speed. (0, Interesting)

Anonymous Coward | about 6 months ago | (#45124131)

Once again a fucking moron that has ZERO clue chimes in. come on back kiddie when you have actually ran a website for money. Your paper route on your home pee cee does not count.

For lumpy, Dont bother, Drupal is still a major hog that requires a dedicated box in the rack. Mostly because hosting companies try to jam 5000 sites on each box.

Re:What it doesnt cover is speed. (-1)

Anonymous Coward | about 6 months ago | (#45124249)

FTW go back to watching Big Bang Theory reruns, feeb.

Re:What it doesnt cover is speed. (-1)

Anonymous Coward | about 6 months ago | (#45124907)

Drupal is still a major hog that requires a dedicated box in the rack

Complete nonsense. You can happily run Drupal on a run of the mill virtual server on shared hardware.

You just need to do the same thing you'd have to do with more fully dedicated hardware than god:

CACHE. EVERYTHING.

Everything.

Fuck, cache yo wife, cache yo ssh logins, cache yo vim sessions.

Re:What it doesnt cover is speed. (1)

pspahn (1175617) | about 6 months ago | (#45125981)

What I am curious about is why someone is trying to run an e-commerce site on shared hosting.

If you build a brick and mortar store, do you also go cut-rate and have the walls built by some highschooler with a hammer and a saw?

If you intend to make money selling things online, do yourself and your customers a favor and fork out the necessary $50-100/mo (and up, depending on traffic) for proper hosting. I have been a customer of Nexcess [nexcess.net] for a handful of years, and not only are their servers highly tuned for the Magento platform, their support is fantastic, so I'm giving them a free plug. Not only will you have proper iron, you also have access to their support teams, which can be worth the hosting cost alone in many cases.

I don't have any experience with Drupal specifically, my main platform is Magento which is also known to be a big resource hog. This is not an unsolvable problem, though. There are plenty of caching libraries out there that resolve the issue of performance, some of them are built into the platform, some are server side, and some are third-party additions.

TL;DR invest in your business and stop trying to do things cut-rate.

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45131175)

What I am curious about is why someone is trying to run an e-commerce site on shared hosting.

So many people who want a website built especially on the low end simply don't ever recover even the money spent on the website, and that isn't counting hosting. I'd call these sites "It would be neat!" sites. They are not a real business plan, just some half realized dream that won't ever amount to anything. When you have a site like this, $5 per user for google apps or $50 a month for hosting is pretty expensive.

They shouldn't even have a website, and thats the problem. It isn't a business plan its virtual masturbation.

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45128107)

Not so. I have a few Drupal sites with 1,000+ unique visitors a month that perform better than most any site on the internet. I have one e-commerce site (with ubercart instead of commerce though... bad choice) that sometimes gets 1,000+ a day, and it's just a blip of a spike in CPU usage. That is on shared hosting with no memcached or varnish at all. It's been load tested to ~4,500 concurrent users, which is leaps and bounds more users than the client ever suspects to visit at once. If I were to implement memcached and varnish, it could handle loads more users.

Caching mitigates a LOT. Drupal runs a lot of queries on a page request; roughly 1/4 of them (on an ecommerce site at least) require any modification on a per user basis, so cache the shit out of them. The rest can be cached on a user basis.

Re:What it doesnt cover is speed. (4, Interesting)

Jakeula (1427201) | about 6 months ago | (#45124153)

I maintain my companies site on Drupal 7 and it is in fact a resource hog. We have had to add more RAM to our servers twice because when our users go to checkout, our server times out and our users get a 502 error page. To be fair our Drupal site was poorly developed and only halfway done before I got my hands on it so I guess its possible building a site properly and completely would change this.

Re:What it doesnt cover is speed. (1)

Gr8Apes (679165) | about 6 months ago | (#45125233)

I maintain my companies site on Drupal 7 and it is in fact a resource hog. We have had to add more RAM to our servers twice because when our users go to checkout, our server times out and our users get a 502 error page. To be fair our Drupal site was poorly developed and only halfway done before I got my hands on it so I guess its possible building a site properly and completely would change this.

No, no it's not. Drupal is a terrible system and anyone with any virtual load and reasonable complexity will soon be looking for something to migrate to. I have migrated several sites off of Drupal, as they grew beyond it capacity to support a user for a reasonable cost. There are other issues with Drupal, but we don't need to go down that road.

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45128147)

Hah, and I make a living migrating other CMS's to Drupal. 100% customer satisfaction as well! I've ported from WP, Joomla, Django (my personal favorite), Rails, you name it. Every single client has loved it. Then again, I've already built a custom backend that eases the administration for a content editor, and 90% of the work I do is theming stuff I've already built and importing data (which, for the most part, I've already done as well).

Your argument could be applied to any CMS that you don't know how to use. Literally any of them.

abstraction layer module unity types (1)

globaljustin (574257) | about 6 months ago | (#45125963)

Drupal is a beast. IMHO, To make Drupal function at the state-of-the-art requires solid internet programming skills. The kind of skills you can't make an "API" for...

Drupal's speed issues are, IMHO, a symptom of too many abstraction layers in the 'development stack' (i hate that term)...

see, you have a 'frame' and in that frame you can put any number of 'units'...each 'unit' has community-contriubted 'modules' that allow you to integrate functions like a web-sign up form or picture slideshow...to download a module, use the 'Doober-flop Jetpack' plug-in...to install the plug-in, pick from one of these common Module API's contributed by users: X, Y, Z...but you can only use Y on Drupal 7...plug-ins can also be their own 'module', depending on they type of 'unit' you use in the 'frame'...except on future versions 'plug-in/modules' will get their own 'unit' type.

That's my experience installing a site from scratch from Drupal. I used to think that the level of knowledge required to make a full 'ecommerce' site from scratch from Drupal was equal to the skills needed to code it from scratch by hand in a text editor (people really hardly ever do this)...but I'm learning...still I don't see Drupal catching on as fast as it should.

It's a great concept...drupal as the developer's FOSS version of Wordpress (plus alot more)...

Re:abstraction layer module unity types (0)

Anonymous Coward | about 6 months ago | (#45128265)

see, you have a 'frame' and in that frame you can put any number of 'units'...each 'unit' has community-contriubted 'modules' that allow you to integrate functions like a web-sign up form or picture slideshow...to download a module, use the 'Doober-flop Jetpack' plug-in...to install the plug-in, pick from one of these common Module API's contributed by users: X, Y, Z...but you can only use Y on Drupal 7...plug-ins can also be their own 'module', depending on they type of 'unit' you use in the 'frame'...except on future versions 'plug-in/modules' will get their own 'unit' type.

Please stay away from Drupal. And sharp objects. And complicated sentences. And food that you have to chew.

Re:What it doesnt cover is speed. (1)

amoeba47 (882560) | about 6 months ago | (#45127017)

You will find significant performance improvements when using Varnish, memcache, APC, authcache and entitycache with Drupal.

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45127829)

And correspondingly slower dev time due to the increased complexity of this mess, trying to make up for Drupal being slow to start with.

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45136861)

And correspondingly slower dev time due to the increased complexity of this mess, trying to make up for Drupal being slow to start with.

Dude, you can pretty much just turn on APC and you increase your performance a hundred fold. It's just a few linux commands and shouldn't take you more than 5-10 minutes. eg: http://www.howtoforge.com/apc-php5-apache2-debian-etch

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45137013)

Here's the deal with Drupal... do any amount of performance debugging and you will see that the reason it is slow out of the box is because it calls hundreds and sometimes thousands of PHP functions for every page load. But if you install/turn on a PHP cache like APC http://php.net/manual/en/book.apc.php almost all of the performance problems instantly go away. It's like night and day. Actually it's more like night and being in the middle of the sun. You don't really even need to install the Drupal counterpart modules that also use the server cache for page caching... that's a very minor improvement, often not even noticeable, you can add at the end of development if you are anal about it or trying to eek every last bit of performance out of your site. The real improvement comes from the PHP function caching and that just happens automatically if you turn it on.

The people who run Drupal could clear up a lot of misconceptions about the performance of their product if they would just put a big bold red warning during the installation process that says "don't even try to run this without a server PHP cache turned on or you are just going to end up hating it and spreading misconceptions about Drupal performance on various internet forums"

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45124305)

He was trying. Should have tried a C64. Everything is better on a C64.

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45125569)

You're being too kind here.

Just by checking the out-of the box Apache configuration you can tell that this thing will suck big time in performance.
Who in his right mind insists putting a .htaccess file on the top web directory? This is something that the Apache folks specifically argue agains. And it goes on version, after version.
To add insult to injury, the way that "static" files are served is mind-numbing. The .htaccess forces Apache to check if the requested web path corresponds to a file on the disk so that it is served statically. Like it is too much trouble to have a dir dedicated to static files dir (like every semi-serious framework/cms has) that involves 0 additional processing.

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45127857)

And don't mention the default and INSANE use of the DATABASE as if it is a cache.

Re:What it doesnt cover is speed. (0)

Anonymous Coward | about 6 months ago | (#45129655)

No, it never will be. The only people that like Drupal, have either never used a good PHP framework or just make drupal themes then dump the client.

Re:What it doesnt cover is speed. (1)

hazah (807503) | about 6 months ago | (#45134279)

Or people that may, perhaps want to avoid reinventing the wheel for every damn site.

Drupal Commerce++ (2)

amoeba47 (882560) | about 6 months ago | (#45125971)

Drupal Commerce is a well designed and crafted module suite. It fixes all the failings of the predecessor Ubercart as a complete rewrite and transforms it into a new and powerful ecommerce system. Drupal Commerce allows for the development of a flexible and secure ecommerce solutions. We've been using it for a while now on several projects and are very happy with it as a robust, reliable ecommerce system. Great stuff.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...