Sweet Tees is a local T-shirt store that sells wildly popular, custom-printed T-shirts. It has a physical storefront, and the owners enjoy running a small store and love their current location. However, they get frequent mail-order requests for their shirts and stickers, and would like to grow that end of the business. Taking orders on the phone and tracking sales has proven to be inefficient and time-consuming for both them and their customers.

In order to increase sales, we will equip the Sweet Tees website with an online store that has integrated shopping cart functionality, where visitors to the site can add items to their cart without the hassle of having to create an account first. A shopping cart should be visible on all pages with a link to “check out” at any time. The store needs to flow seamlessly with the existing website so that customers have a consistent experience. Sweet Tees would like to make the checkout process as simple as possible, so we will also need to make sure we provide them with a single-page checkout, without requiring customers to create a user account. Finally, they wish to accept credit cards on their orders, so we will need to set up a payment gateway for this purpose.

Drupal Commerce is a complete package for running an online store. As such, it actually contains numerous submodules that each implement features of an online store, and can be turned on or off depending on the precise functionality required. In this section, we’ll look at each module in turn, and outline its purpose and where it fits.

Commerce and Commerce UI

Commerce is a required module that provides the underlying APIs and functionality for the Drupal Commerce suite as a whole, and doesn’t provide much in the way of configurability. The Commerce UI module provides the main Store (admin/commerce) configuration panel, pictured in Figure 9-2.

Note

Nearly all modules in the Drupal Commerce package are split into both a “functional” module and a “UI” module. This is to allow other contributed or custom modules to potentially replace the default user interface with one more streamlined to a particular use case.

Figure 9-2. Commerce UI provides the default Store management screens

Cart

Cart handles the shopping cart, pictured in Figure 9-3, and provides features such as a handy sidebar block showing cart contents on all pages, and the ability for customers to add or remove cart contents. Both the block and checkout page are views, so you can customize the precise fields and order they’re displayed in, just like any other listing built in the Views module.

The Cart module also exposes a number of events and actions that can trigger system behavior through the Rules module. For example, for a site selling multiple subscription levels, it might make sense to remove the old subscription level from the cart when adding a different subscription.

Figure 9-3. The shopping cart page and sidebar block provided by the Cart module

Customer and Customer UI

The Customer module exposes an entity type called Customer Profile, which can be used to store information a customer must fill out during the checkout process. By default, Drupal Commerce ships with a profile type called “Billing information,” pictured in Figure 9-4. However, other modules—such as Commerce Shipping, which exposes a profile type called “Shipping information”—may offer additional types as well. Because customer profiles are entities, they may have other fields added to them, such as phone number or Tax ID.

Figure 9-4. Checkout panes are provided by the Checkout module

Figure 9-5. The page elements (“checkout panes”) to show during the checkout process, as well as their order, are configurable in the Checkout module settings

Order, Order UI, Line Item, and Line Item UI

The Order and Line Item modules are responsible for recording, tracking, and managing individual orders to the store. Figures 9-6 and 9-7 show the default user interface for managing orders, provided by the Order UI and Line Item UI modules. You can view orders that are completed as well as those still in the shopping cart phase, and you can also create and edit orders manually—for example, to accept orders over the phone.

Figure 9-6. Orders overview listing page

Figure 9-7. A sample order

Product and Product UI

Something that’s pretty essential to any store is cataloguing all of the products it sells. In Drupal Commerce, this capability is provided by the Product module.

Products in Drupal Commerce are entities, which means you can create different product types (e.g., Book, Music, Event Registration), and add more fields to those product types. All products in Drupal Commerce have a set of basic, required fields: Product SKU, Title, Price, and Status. Figure 9-8 shows an example of a product type with an image field added to it.

Figure 9-8. A sample product form including both the standard, required fields as well as an extra image field

Like elsewhere in Drupal Commerce, the default product view exposed by the optional Product UI module, pictured in Figure 9-9, can be customized with the Views module. This allows you to add extra fields, expose filters for product type or keyword search, or whatever else you can envision doing with Views.

Figure 9-9. The default view from the Product UI module

Before we get to the first step in creating our store—adding products—it’s worth taking some time to discuss and understand how Drupal Commerce treats products within the system. While product management may appear unintuitive at first, the product management features in Drupal Commerce are designed to allow for maximum flexibility.

The first step in setting up our online T-shirt store is to turn on a formidable array of modules to enable the Drupal Commerce module, and then set up product types for the merchandise that Sweet Tees sells: T-shirts and stickers.

Configuring Product Types

1. Go to Store→Products (admin/commerce/products), the main product admin panel, and click the Product Types tab. By default, you’ll see a single product type listed there called Product. That’s a bit too generic for our tastes, so click the Delete link to remove it.

2. Click “Add product type” and give it a Name of “T-shirt” and Description of “Our award-winning T-shirts.” Then click “Save and add fields.” At the Managed Fields screen for T-shirt (admin/commerce/products/types/t-shirt/fields), pictured in Figure 9-10, you’ll see we already have a few fields predefined: Product SKU, Title, Price, and Status.

   

   Figure 9-10. Default fields available to product types

3. Add two new fields—Size and Color—to the T-shirt product type, using the values in Tables 9-1 and 9-2, respectively.

   Table 9-1. Settings for the T-shirt product type’s Size field

   Field	Value
   Label	Size
   Machine name	size
   Field type	List (text)
   Widget	Select list
   Allowed values list	S M L XL
   Required field	Checked

   Table 9-2. Settings for the T-shirt product type’s Color field

   Field	Value
   Label	Color
   Machine name	color
   Field type	List (text)
   Widget	Select list
   Allowed values list	White Black
   Required field	Checked

4. We also want to add an image field, but thanks to the default Article content type, we already have one we can use. Under “Add existing field,” choose “Image: field_image (Image)” as the field to share, then provide a Label of “Image” and click Save. Leave the default settings.

5. Finally, reorder the fields as indicated in Figure 9-11 (Product SKU, Title, Price, Image, Size, Color, and Status), and click Save.

   

   Figure 9-11. The completed T-shirt product type with reordered fields

6. Return to the main Product Types screen and create a second product type at “Add product type” (admin/commerce/products/types/add) for Sticker. Give it a Name of “Sticker” and Description of “A sticker with a witty phrase.” We can just keep the default fields here, so simply click “Save product type.”

7. As you did with T-shirt, add the existing image field to Sticker, leave the default settings, and drag it just above Status in the list of fields.

8. When finished, your product types screen (admin/commerce/products/types) should look as pictured in Figure 9-12.

Figure 9-12. Product types for the Sweet Tees store

Creating Sample Products

Now that we have our product templates created, let’s work on populating some store content!

1. Go to Store→Products (admin/commerce/products) and click the “Add a product” link (admin/commerce/products/add) to see a menu of available product types.

   Note

   Since you’ll return to this screen fairly often over the course of managing your online store, you might want to hover over the plus sign (+) next to “Add a product” and click “Add to Default shortcuts” so the link is easily accessible from all pages in Drupal’s Shortcut bar at the top of the screen.

2. Let’s start with a sticker, since that’s nice and easy. Click Create Sticker (admin/commerce/products/add/sticker). Give it the values in Table 9-3 and click “Save product.”

   Table 9-3. Values for a sample Sticker product

   Field	Value
   Product SKU	STICKER-001
   Title	Druplicon sticker
   Price	10.00
   Image	(Upload the drupal-sticker.png file from the assets/ch09-store folder.)
   Status	Active (default)

   Note

   In almost all cases, you’ll leave the Status field as Active. The Disabled status is useful in the case of items that are discontinued. You wouldn’t want to delete the product, as that could destroy customer order data. Setting the product as Disabled will ensure it can’t be added to anyone’s shopping cart and will hide it from view.

3. Now let’s add a T-shirt by clicking “Add a product” and then Create T-shirt (admin/commerce/products/add/t-shirt). Give it the values in Table 9-4 and click “Save product.”

   Table 9-4. Values for a sample T-shirt product

   Field	Value
   Product SKU	TSHIRT-001-M-WH
   Title	Druplicon T-Shirt - Medium White
   Price	1.99 (Note: this is a deliberate typo that we will fix in the next section!)
   Image	(Upload the druplicon-tshirt-white.png file from the assets/ch09-store folder.)
   Size	M
   Color	White
   Status	Active (default)

   Note

   As mentioned in Spotlight: Drupal Commerce, Drupal Commerce needs one product with a unique SKU per product configuration. Our T-shirt store sells both multiple sizes (S, M, L, XL) and multiple colors (White, Black) of each of the three T-shirt designs. As a result, if we keep going along with this example, we would have to enter in a whopping 24 products by hand. Yowza! Let’s hope Sweet Tees doesn’t think about adding any new T-shirt designs or, heaven forbid, decide to offer women’s and children’s styles of each design as well!

   Luckily, there’s a way to bulk-import lots of products at once, which will be the focus of the next section of this chapter.

4. Now that we’ve entered a couple of products, our product administration screen at Store→Products (admin/commerce/products) should look as pictured in Figure 9-13.

Figure 9-13. Sample products for the Sweet Tees store

Note

Remember: nearly all listing pages in Drupal Commerce are Views, including the product overview page. You can easily customize this page to add extra columns for the Image, Size, and Color fields; add an exposed filter or two to restrict the list by certain product types or provide a keyword search; or anything else you do with Views module. Be creative!

Of course, a company like Sweet Tees has many more products than just a single sticker and T-shirt they’d like to sell. However, entering their entire inventory by hand will quickly become tedious and carpal tunnel–inducing. Luckily, using standard Drupal data import tools, we have a solution to this problem.

The Feeds module provides the capability to ingest data from any number of different sources and transform it into native Drupal constructs. It’s a versatile tool that can be used for things such as large-scale data migration, automatically populating a block of recent content from external sites, or synchronizing content posted among multiple sites.

Among its features are the ability to scan incoming data for already existing content and decide whether to ignore it or merge in the defaults. Content ingestion can be scheduled and queued, even for large jobs.

The Feeds module works by creating one or more “importers” to do the data ingestion. Importers have three basic components: the Fetcher, the Parser, and the Processor.

Figure 9-14 shows the default feed importer settings. This configuration creates an importer that fetches an RSS or Atom feed from a URL every 30 minutes, then imports the contents into Drupal as nodes. The fetcher, parser, and processor settings can then be customized to allow for other behaviors.

Figure 9-14. A feed importer showing default options

There are also several contributed modules that can extend the Feeds module’s capabilities. For example, the “Feeds YouTube parser” module (http://drupal.org/project/feeds_youtubehttp://drupal.org/project/feeds_comment_processor) provides the capability to read feeds of videos from YouTube; the “Feeds Comment Processor” module (http://drupal.org/project/feeds_comment_processor) allows importing feed content as comments; and the “Feeds Directory Fetcher” module (http://drupal.org/project/feeds_fetcher_directory) can monitor a directory for new files and turn them into a feed for parsing.

Now that we’re familiar with the Feeds module’s data import tools, let’s turn our attention to importing T-shirt products for Sweet Tees.

Sweet Tees has kindly furnished us with a comma-separated values (CSV) file containing all of their T-shirt product data for this purpose. CSV is a common data export format from databases and spreadsheet programs. A CSV file is a simple text file that encodes a data set with each record on its own line, and a separator (such as a comma or tab) between the data values. We’ll examine the contents of this file more closely in Mapping CSV Data to Drupal Commerce Products.

We’ll use the Commerce Feeds module for this purpose, which provides two new Feeds processors: Commerce Customer Profile processor and Commerce Product processor.

Creating a Feed Importer for CSV Files

1. Go to the Modules page and enable the following modules:

   • Commerce (contrib) package

     • Commerce Feeds

   • Feeds package

     • Feeds

     • Feeds Admin UI

   • Other package

     • Job Scheduler

2. Go to Structure→Feeds Importers (admin/structure/feeds) and click the “New importer” tab (admin/structure/feeds/create).

3. Fill out the form with the values in Table 9-5 and click the Create button.

   Table 9-5. Settings for the Product importer

   Field	Value
   Name	T-shirt importer
   Description	Import the Sweet Tees T-shirt catalog from CSV file.

4. At the next screen, there is a table with many settings, most of which can be ignored. “Basic settings” allows you to configure things like how often to import from a feed and whether the process should happen in the background or immediately upon form submission. Then the Fetcher, Processor, and Parser sections affect the settings for each of those components.

5. Under Fetcher, click Change, choose “File upload” instead of “HTTP fetcher,” and click Save. While the “HTTP fetcher” option would be useful for reading in feed data from a remote URL, the Sweet Tees product list is in a CSV file sitting on your computer’s hard drive, so it makes sense to show a file upload field instead of a URL field. If you wish, you can click Settings for the file upload fetcher to configure additional settings such as what file extensions are allowed, but that’s unnecessary for this example.

6. Under Parser, click Change, choose “CSV parser,” and click Save. Once again, you can click Settings for the CSV parser to change options such as what delimiter is used in the file, but we don’t need to do that here.

7. Under Processor, click Change, choose “Commerce Product Parser,” and click Save. The CSV items will now be imported as Drupal Commerce products, not nodes.

8. Click the Settings link next to “Commerce Product processor,” enter the values found in Table 9-6, and click Save.

   Table 9-6. Settings for the Commerce Product processor

   Field	Value
   Update existing commerce products	Update existing products
   Text format	Plain text (default)
   Product type	T-shirt
   Author	admin

   Note

   The one value worth mentioning here is “Update existing commerce products.” This value means that if incoming product data from the feed matches existing data within Drupal, the values coming in from the feed will “win” and override the site’s data. In this case, we want that, since it’s an initial import of the CSV data. In future imports, however, we’d probably want to leave that at “Do not update existing products” so only new products are added.

9. When completed, the settings along the left side should look as shown in Figure 9-15.

Figure 9-15. Settings for the product feed importer

Mapping CSV Data to Drupal Commerce Products

Now for the fun part: telling the Feeds module how to take incoming CSV data and turn it into Drupal products!

1. Click the Mapping link next to the Commerce Product processor on the T-shirt importer edit page to view the “Mapping for Commerce Product processor” page (admin/structure/feeds/edit/t_shirt_importer/mapping).

2. Take a peek inside the using_drupal_tshirts.csv file and examine its contents. Of particular note is the first row of the file, which lists the columns of the incoming data: SKU, Title, Price, Size, Color, and Image. These are the “source fields” we need to map. Here is an excerpt:

   SKU,Title,Price,Size,Color,Image
   TSHIRT-001-S-WH,Druplicon T-Shirt - Small White,1699,S,White,
       http://usingdrupal.com/sites/default/files/v7/ch09-store/druplicon-tshirt...
   TSHIRT-001-M-WH,Druplicon T-Shirt - Medium White,1499,M,White,
       http://usingdrupal.com/sites/default/files/v7/ch09-store/druplicon-tshirt...
   TSHIRT-001-L-WH,Druplicon T-Shirt - Large White,1499,L,White,
       http://usingdrupal.com/sites/default/files/v7/ch09-store/druplicon-tshirt...

   Note that the data intentionally charges more for Small shirts—both to show that it can be done, and also because skinny people have it way too easy in life.

   Note

   The first question you might reasonably ask is, “What’s up with those weird prices?” Because Drupal Commerce supports multiple currencies, and different currencies have different rules on how they’re formatted, the developers made the decision to store all pricing data in the “minor unit” of the amount (so the price in cents, in the case of US or Canadian Dollars). If your incoming data stores price information in the more predictable “16.99”-style format, try the Feeds Tamper module for manipulating the source data before it hits the Feed parser.

3. Back in Drupal, examine the values under the “Select a target” drop-down: Product SKU, Product Title, and so on. These are the “target fields” in products, to which the source data will be mapped.

   Note

   If you find yourself puzzled by some of the options here, such as GUID, there’s a handy Legend fieldset down below that contains descriptions of each target.

4. One after another, add the source-to-target mappings indicated in Table 9-7 by typing the name of the Source field from the CSV file, selecting the name of the Target field from the drop-down box, and clicking the Add button. If you make a mistake, check Remove next to the field and click the Save button at the bottom of the form.

   Table 9-7. Source-to-target mappings for product import

   Source	Target
   SKU	Product SKU
   Title	Product title
   Price	Price: Amount
   Size	Size
   Color	Color
   Image	Image

5. Check the Unique Target checkbox next to the SKU field and click Save, to indicate that this value uniquely identifies each record.

6. When your mapping configuration is finished, your screen should look as pictured in Figure 9-16.

Figure 9-16. Mapping for the T-shirt feed importer

Importing CSV Product Data

And now, the moment we’ve all been waiting for.

1. Close out of the Feeds administration screen and go to Import (import) in the Navigation block, then click on “T-shirt importer” (import/t_shirt_importer).

2. Click “Choose file” on the File field and point it to the using_drupal_tshirts.csv file, then click Import.

3. A progress bar should appear for a few seconds, and then you should see a notification that Drupal created 23 commerce products, and updated 1 commerce product. Score! Let’s check it out.

   Note

   If anything goes awry here, the Delete Items tab will present an option to remove all imported values and try again.

4. To confirm, head to Store→Products (admin/commerce/products), which should appear similar to Figure 9-17. You should see a heck of a lot more products there than before, and our previously mistyped $1.99 T-shirt from earlier should now be the correct $14.99 price. Yippee!

Figure 9-17. Mapping for the product feed importer

Now that all of this groovy product data is showing up fine in the administrative interface, there’s just one problem: how do we expose these products on our public website to our customers? And further, how do we avoid displaying a product catalog with 25 entries in it, when from a customer’s point of view we only sell four products (three T-shirts and a sticker)?

Drupal Commerce’s “Products” concept essentially acts as your “warehouse” or “product catalog”: any and all items your store sells or has sold in the past should be represented in Drupal as products. However, that only gets you part of the way there: while your products will show up great in the administrative listings, they’re not visible on the site and your users can’t actually purchase them yet. Additionally, in our movie store example, paging through 27,000 products with titles like “Airplane! Blu-Ray Spanish Version” and “Airplane! DVD English Version” won’t make much sense to our customers. They’ll simply want to search for individual movie titles, and then choose the format and language they want as they’re adding the movie to their shopping cart.

The way Drupal Commerce facilitates both of these needs is through the use of one or more content types with a Product Reference field attached. The Product Reference field can group together one or more products into a single product display node, and mark the required fields in those products as attributes (for example, the Size field on a T-shirt) and expose them as attribute selection fields on the “Add to Cart” form. Updating these fields will also switch product-specific properties, such as the image attached to a product, or its price.

Figure 9-18 illustrates the concept of products and product displays.

Figure 9-18. Product displays collect one or more products and expose their required fields as attributes for customers to select from

Now it’s time to create the storefront our users will view, from which they can add products to their shopping cart.

Let’s try putting what we just learned into action by creating a content type for product displays, and a few sample products to get the hang of how things work.

Figure 9-19. A Drupal Commerce product display node

Next, let’s create a nice interface for browsing products. We can categorize product displays using the Taxonomy system, and use the Views module for providing the browsing page:

Figure 9-26. Final views configuration for the product catalog

Figure 9-27. Final product catalog

It’s easy to imagine that different kinds of stores might have certain things they want to have happen when various events take place throughout the purchasing process. For example, if someone adds more than 10 of an item to his cart, a store might want to provide a 10% discount. Or if someone was anonymous and then registers or logs in, a store might want to assign his old shopping cart to his newly found account.

Traditionally, this kind of custom logic would have to be done in code by a programmer. However, the Rules module exposes a user interface for clicking together custom logic in a web-based interface. This increases accessibility to nonprogrammers, and also allows for bits of business logic to be shared among multiple sites with the Rules module’s import and export capabilities.

Because of the flexibility it provides, Drupal Commerce’s payment system relies on the Rules module, so it’s worth a quick diversion here before proceeding to setting up payments.

Figure 9-28. Rules module overview page

The following are the architectural blocks of Rules:

Figure 9-29. The user interface for choosing Rules data selectors

Figure 9-30 shows a diagram of how the parts of the system work together. Not only does the Rules module expose events, conditions, and actions to play with, but Drupal Commerce and many other modules do as well. Two examples covered elsewhere in the book are the Flag module and the Workbench module.

Figure 9-30. The logic for processing rules

Let’s try a practical example of some Rules module concepts for the Sweet Tees store. Drupal Commerce’s Tax module stores its tax charging in Rules.

Before we can open up our store to the public, we need to ensure that all applicable sales taxes are being applied to our items. Because Sweet Tees is based in California, we will need to charge 7.25% sales tax on all products sold if the customer lives in the state of California.

Figure 9-31. Configured Rules component for CA sales tax

Of course, it’s one thing to have a bunch of products ready for purchase. But what Sweet Tees really cares about is raking in the dough. They want to be able to accept credit card transactions on their newfangled online store.

An online retailer must have a merchant account: a type of bank account provided by a financial institution that allows organizations to accept credit payments. A merchant account can be provided by a merchant bank or by a third party such as PayPal or Authorize.net that authorizes payments on behalf of banks. Fees vary between services, and should be evaluated based on anticipated transaction volume and average sale price.

While customers’ credit card details are entered into forms on the Drupal side, no sensitive information is ever stored by Drupal Commerce. Instead, it is passed on to the payment gateway for storage on their side.

Figure 9-32 outlines the process of Drupal handing off the request to the payment processor.

Figure 9-32. Drupal Commerce payment flow diagram

The spot where the customer’s credit card details are captured depends on the payment processor, and may require additional setup on your Drupal site. For example, PayPal offers a starter, no-setup fee tier of service, called Website Payments Standard, that will redirect the customer to PayPal.com upon checkout to enter her credit card details, then return her back to your site when the transaction is verified. In this case, no additional configuration is required.

However, many shop owners would rather have a fully integrated shopping experience, and want to gather the credit card details on their own site. PayPal’s Website Payments Pro offers this capability, but using it requires secure socket layer (SSL) encryption between your site and PayPal. Luckily, the Secure Pages module (http://drupal.org/project/securepages) provides this capability.

PayPal is a popular payment processor, especially for new site owners. It allows credit card transactions as well as payments from within PayPal itself, which is common particularly within the eBay ecosystem. There are predominantly two “flavors” of PayPal’s payment processing tools:

For our purposes, we’ll be using Website Payments Standard, since there are no setup fees, no extra security setup required, and we can get started right away. Note that the setup steps for other payment processors vary depending on the provider; PayPal WPS is used in this chapter for illustrative purposes.

Figure 9-35. Dashboard for PayPal test account

Now that we have the PayPal side of payments set up, it’s time to set up the Drupal side of things. We’ll do this with the Commerce PayPal module from http://drupal.org/project/commerce_paypal, and Drupal Commerce’s Order and Payment (UI) modules. Just as we saw with Taxes, Ubercart payment methods are Rules-enabled for maximum flexibility.

Figure 9-36. Configuring PayPal WPS payment settings

The remaining element of our site is actually implementing the ecommerce portions: an online shopping cart and the ability to process orders, as well as reporting tools to tell us how our store is doing. We will now complete our store configuration.

To complete this section, we must first enable one final set of modules. Go to Modules (admin/modules) and enable the remaining UI modules in the Commerce package:

Shopping Cart

Thanks to the Cart module that we enabled earlier, everything we need for a shopping cart is pretty much done. Let’s make some final tweaks:

1. Drupal Commerce ships with an optional block that can display a visitor’s shopping cart on all pages. Go to Structure→Blocks (admin/structure/block), drag the Shopping Cart block to the top of the “Sidebar first” region, and click “Save blocks.”

2. Test it out by navigating to a product page and clicking the “Add to cart” button. You should see the product and total show up instantly in the left sidebar.

3. Click the “View cart” button to see the full shopping cart. It’s looking a little bland. Luckily, the shopping cart (as well as the shopping cart block) is a view, which means we can make tweaks to it.

4. Let’s add a product thumbnail image field as well. Hover over the larger shopping cart view, click the gear icon, and click “Edit view.”

5. The view is currently showing order information. To add product information, we need to add a relationship to it. In the Relationships section, click “add,” and select “Commerce Line item: Referenced product.” Accept the default settings.

6. Click the “add” button in the Fields section and check “Field: Image.” Uncheck “Create a label” and choose an image style of “thumbnail.” Click Apply to save changes.

7. Finally, reorder the image field so it comes first in the list. In the Fields section, click the drop-down next to “add” and choose “rearrange.” Use the drag-and-drop handles to move “(Product) Field: Image” to the top of the list, then click Apply.

When finished, save and close the view and return to the shopping cart page, which should now be visible in all its glory, as pictured in Figure 9-37.

Figure 9-37. Drupal Commerce shopping cart, along with a sidebar block

We now have our shopping cart ready to go. That was easy! Next, we’ll talk about what happens when someone clicks the Checkout button.

Checkout Process

Drupal Commerce provides the ability to fully customize the checkout workflow to your store’s specific needs. By default, the checkout process contains four distinct steps: “Checkout,” “Review order,” “Payment,” and “Checkout complete.” A variety of page elements called panes are provided and can be placed in any step in any order, and you can control certain cosmetic aspects of panes such as whether they appear in a fieldset.

1. Go to Store→Configuration→“Checkout settings” (admin/commerce/config/checkout) to view the current checkout configuration settings.

2. Because PayPal WPS forces a redirect to a third-party website when gathering payment details, it behooves us to make the checkout process as simple as possible. We can omit the “Review order” step of the process altogether by removing all of the panes within it. Drag the Payment pane to the bottom of the Checkout section, and the Review pane to the Disabled section.

3. When you’re finished, your checkout settings should be as pictured in Figure 9-38. We’ll see this change in action in the next section.

Figure 9-38. The newly customized checkout workflow

Placing a Test Order

We are now ready to make our first test order! Here’s how:

1. Click Checkout from either the left sidebar block or the shopping cart page.

2. We are now on the checkout screen, pictured in Figure 9-39. By default, this page displays the contents of our shopping cart for confirmation, followed by account information, and fields to enter a billing address. Because we customized it to do this, it also contains the payment selector. Complete the billing information section with your information. Click “Continue to next step” when finished.

   

   Figure 9-39. The order summary and delivery details of the checkout screen

   Note

   If you wish to whittle down the exhaustive default country list to something more appropriate for your customer base, you can do so from Store→“Customer profiles”→“Profile types” (admin/commerce/customer-profiles/types). Click “manage fields,” then edit the Address field and change the “Available countries” selection.

3. The next screen will inform you that you are being redirected to PayPal’s site. Wait for a few seconds, and you should see a screen similar to Figure 9-40. To test credit card transactions, choose the “Don’t have a PayPal account?” option. You’ll be prompted to enter your billing information and credit card details.

   

   Figure 9-40. PayPal’s billing information screen

4. Before proceeding, return to your browser tab with the PayPal developer sandbox we set up earlier (or log in again). Under “Test accounts,” click “View details” on the Personal account. Copy and paste the credit card number and expiration date there into the payment form. For CSC, fill in any 3-digit number.

5. Complete the rest of the form and then submit it. Because you’re using a credit card number that PayPal knows about, you will be prompted to log in with your PayPal account. Choose the option to “Continue to pay as a guest and do not use my PayPal account.”

6. If all goes well, you should see a PayPal confirmation page for your order. Click Pay Now. You’ll be taken to a final screen showing a confirmation message, as pictured in Figure 9-41. Click “Return to Sweet Tees’s Test Store” to go back to your Drupal site.

   

   Figure 9-41. PayPal’s order confirmation screen

7. Back on the Sweet Tees website, you’ll be presented with a short thank-you page, with a link to view the current order status from the Orders section of your user profile, shown in Figure 9-42. Click the “view your order” link, and you should see a screen similar to Figure 9-43.

   Note

   You can customize the text on this page in the checkout configuration at Store→Configuration→“Checkout settings” (admin/commerce/config/checkout). Click the “configure” link next to “Completion message,” and check the “Override the default checkout completion message” checkbox.

Figure 9-42. The final checkout confirmation form

Figure 9-43. The completed order, as seen by the customer

In this chapter, we have covered the basics of setting up an online storefront and shopping cart using the Drupal Commerce package for Drupal. However, there are several additional modules that you will likely want to consider before taking your online store live:

In this chapter, we were able to set up a complete online store for our customer, Sweet Tees, using Drupal Commerce, a powerful, flexible ecommerce framework built on Drupal. We set up a payment system through PayPal’s Website Payments Standard. We also delved into the topic of data imports with the Feeds module, and covered tweaking Drupal’s functionality at various system points with the Rules module.

Here are the modules we referenced in this chapter:

Here are the additional resources that we referenced in this chapter: