While many Drupal developers have at least some eCommerce experience, the number of people in our community who make it their primary focus is rather small. This isn't surprising, given Drupal is most often used as a CMS, not an eCommerce platform. However, it does mean that when you encounter an eCommerce opportunity, you may not be making the most effective pitch you can to win the merchant's business.

One way to improve your pitch is to make sure you're using the same vocabulary to describe eCommerce features and concepts as the rest of the eCommerce industry. It's all too easy for us as Drupal developers to rely on our internal vocabulary, but merchants comparing your proposals, case studies, or Drupal Commerce articles won't have the slightest clue what Taxonomy Terms, Views, or Search API indexes are.

Learning and using industry standard terms will help you build clarity and confidence with your eCommerce prospects and customers, reducing the amount of work they have to do to understand your proposals and compare them against other solutions to see exactly where Drupal Commerce comes out on top.

Product Display Pages (PDPs)

A product display page is exactly what it sounds like: a page on the website that displays a product for sale. In Drupal 7 and earlier we recommended using custom node types to build product display pages, but as of Drupal 8 / Commerce 2.x, we've created a specific Product entity type for these.

PDPs typically feature the product title, image(s), description, pricing and availability, and custom fields that render structured details or specifications depending on the type of product being sold. When reviewing wireframes or sample pages with the merchant, you'll want to be mapping the various page components to known field types and consider how they might render in the full PDP vs. a teaser vs. the shopping cart. You'll likely need to plan custom Views or Layout Builder components to support your merchants' preferred cross-selling method (e.g. by category, purchase history, or manual curation), which may also require custom product taxonomies or other fields to implement.

Last but not least, these pages typically include an Add to Cart form. This is where the data model gets slightly more complex, as most eCommerce platforms distinguish between products and product variations (sometimes referred to as product variants). Products have one or more variations comprised of a title, SKU, price, and any custom fields that differ per variation. The job of the Add to Cart form is to let customers select which of the variations they want to purchase, usually by selecting an attribute value that corresponds to a particular variation (e.g. a size option).

Drupal Commerce does two things for you when the customer changes the selected variation. First, it updates the portions of the PDP that are rendered from the variation. This means you'll need to determine during your architecture phase if fields should go on the product or the product variation. Ideally fields go on the product to avoid unnecessary data duplication across multiple variations, but you have the option to support scenarios like updating the image to match a selected color variation. Second, the URL will be updated to include the variation ID so you and your customers can link directly to a specific variation on the PDP.

There are numerous popular modules you can use to further enrich and optimize your PDPs. We recommend the recently published book Digital Marketing with Drupal by long-time Drupal contributor José Fernandes of Bloomidea to learn more about how to improve the marketing capabilities of a Drupal Commerce store.

Product Listing Pages (PLPs)

A product listing page is also exactly what it sounds like: a list of products displayed for sale on a website. The list may be manually curated (i.e. all of the products in a specific category), user selected and sorted as through a faceted search interface, or otherwise queried from the database through some other means.

In Drupal, a PLP is most often built through the Views module, but you should refrain from using the word Views with a merchant. They're more used to talking about catalog navigation, keyword search, and faceted search interfaces. If I know the team I'm pitching has a technical member, I may introduce the concept of Views by saying, "Drupal has a built in database querying tool that we use to generate lists of all kinds of data objects, including products."

One of the great things about Drupal is its integration with Apache Solr through the Search API and Facet API modules. These modules let you build feature rich PLPs with no code, but you generally shouldn't be diving into the technical details too deeply in client conversations. What merchants really want to know is whether or not your PLPs can scale for any sized product database (hint: yes, up to 15M SKUs and counting) and if they support both keyword and facet based search (again, yes, our demo store configures this out of the box).

When you're discussing PLPs with customers, the important questions to ask are how they expect customers to navigate these pages, what information they want to see for each product on the page, and what kind of sorting (e.g. recently added) or filtering (e.g. price ranges) functionality they expect.

Some of the more complex things you'll have to manage are product listing pages with manually sorted products or product images and links that reflect a specific variation based on a facet or filter (e.g. a thumbnail and link reflecting a previous color facet selection). Drupal Commerce accommodates even these advanced scenarios, but you definitely have to plan site building and / or theming time to make them work. We've also recently begun using Elasticsearch for some of these cases ourselves, as it offers significantly advanced functionality with a merchant friendly user interface out of the box.

What next?

We want Drupal Commerce to win. Leveling up our development community to see more opportunities won and projects succeed is a big part of that.

There are limitless topics to explore to ensure we're speaking the same language as your eCommerce prospects. I'll be presenting this particular topic in a lightning talk at DrupalCon Portland 2022. I'd love to hear from folks there or in the comments here what other topics we should add to the schedule.