Crear una tienda Drupal Commerce desde cero: instalación y configuración inicial

Después de estudiar la arquitectura conceptual de Drupal Commerce vamos a comenzar una nueva fase: construir una tienda desde cero.

Hasta ahora hemos analizado:

Discovery
   ↓
Product Modeling
   ↓
Pricing
   ↓
Orders
   ↓
Checkout
   ↓
Payments
   ↓
Shipping
   ↓
Fulfillment

Ahora utilizaremos esos conceptos para tomar decisiones reales dentro de una instalación Drupal.

Para hacerlo utilizaremos un negocio de ejemplo suficientemente pequeño para comprenderlo con claridad, pero suficientemente variado para explorar diferentes capacidades de Commerce.

1. Nuestro negocio de ejemplo

Imaginemos una familia que comienza a vender productos desde casa mediante Internet.

Inicialmente quiere vender tres grandes tipos de cosas:

Artículos usados

Objetos que la familia ya posee y desea vender.

Por ejemplo:

Used Products

├── Laptop usado
├── Cámara fotográfica
├── Mesa
├── Bicicleta
└── Libros

Normalmente cada artículo:

• Es único
• Tiene una sola unidad disponible
• Tiene un precio específico
• Tiene fotografías propias
• Tiene una condición particular

Productos importados

La familia también compra algunos productos en el exterior para revenderlos localmente.

Por ejemplo:

Imported Products

├── Accesorios electrónicos
├── Cables
├── Gadgets
├── Artículos para el hogar
└── Pequeños dispositivos

Estos productos pueden tener:

• Varias unidades en stock
• Reposición de inventario
• Costos de importación
• Precio de venta
• Diferentes variantes

Pasteles

También existe un pequeño negocio familiar de pastelería.

Por ejemplo:

Cake

Chocolate Cake

que puede ofrecerse en diferentes tamaños:

Small

Medium

Large

y quizás diferentes sabores o coberturas:

Chocolate

Vanilla

Strawberry

Esto nos permitirá trabajar con Product Attributes y Product Variations.

Servicios en el futuro

Más adelante la familia podría ofrecer servicios.

Por ejemplo:

Computer setup

Basic technical support

Cake decoration service

Home delivery service

Personalized event service

No implementaremos todavía estos servicios, pero tendremos en cuenta que el modelo pueda extenderse sin reconstruir toda la tienda.

2. Por qué este ejemplo es interesante

Nuestro pequeño negocio contiene varios problemas diferentes de Commerce.

Used Products
        ↓
Unique items


Imported Products
        ↓
Inventory / repeatable products


Cakes
        ↓
Product Variations


Future Services
        ↓
Non-physical commerce

Esto nos permitirá aprender progresivamente diferentes patrones de modelado.

Además nos obliga a evitar una mala práctica común:

Crear una única estructura genérica para cualquier cosa que podamos vender.

Queremos compartir estructuras cuando tenga sentido, pero separarlas cuando existan diferencias reales de negocio.

3. Alcance de nuestra primera versión

No vamos a implementar toda la tienda desde el primer artículo.

Nuestra primera versión tendrá un alcance deliberadamente pequeño.

Construiremos:

Drupal
   ↓
Commerce
   ↓
Store
   ↓
Basic Product Architecture
   ↓
First Product

En artículos posteriores añadiremos:

Attributes

Variations

Inventory

Checkout

Payments

Shipping

Promotions

Taxes

Services

Trabajaremos de forma incremental.

4. Arquitectura inicial del negocio

Antes de instalar Commerce podemos hacer un primer diseño conceptual.

HOME SHOP
   │
   ├── Used Products
   │
   ├── Imported Products
   │
   ├── Cakes
   │
   └── Services
       └── Future

La primera pregunta es:

¿Necesitamos cuatro Product Types?

No necesariamente.

Debemos analizar las diferencias estructurales.

5. Analizando los artículos usados

Un producto usado podría tener:

Title

Description

Category

Condition

Images

Price

Availability

Por ejemplo:

MacBook Air M1 usado

Condition:
Good

Price:
450 USD

Quantity:
1

Normalmente tendrá una única Product Variation.

Product
MacBook Air M1 usado

        ↓

Variation

SKU:
USED-0001

Price:
450 USD

No necesitamos Attributes porque el usuario no selecciona entre múltiples versiones.

6. Analizando los productos importados

Algunos productos importados podrían tener exactamente la misma estructura.

Por ejemplo:

USB-C Hub

Description

Brand

Category

Images

Price

y:

Variation

SKU:
IMP-USBHUB-001

Price:
35 USD

En ese caso la diferencia entre:

Used Product

Imported Product

podría ser simplemente una clasificación.

Podríamos utilizar:

Product Type:
Physical Product


Taxonomy:
Product Origin

├── Used
├── Imported
└── Local

Esto sería más sencillo que crear Product Types diferentes sin necesidad.

7. Pero existen diferencias reales

Sin embargo, quizá queramos registrar información específica para los productos usados.

Por ejemplo:

Condition

Purchase year

Visible defects

Mientras los productos importados podrían necesitar:

Brand

Supplier

Country of origin

Aquí tenemos una decisión real de arquitectura.

Podemos:

Option A

One Product Type
+
optional fields

o:

Option B

Used Product

Imported Product

Para nuestro ejercicio elegiremos inicialmente mantenerlos separados.

Esto hará más visibles las diferencias entre Product Types y nos permitirá practicar su configuración.

8. Arquitectura inicial de Product Types

Comenzaremos con:

Product Types

├── Used Product
├── Imported Product
└── Cake

Dejaremos:

Service

para una etapa posterior.

9. Variation Types

También debemos pensar en las unidades comprables.

Used Product

Product

Used Laptop

        ↓

1 Variation

SKU:
USED-0001

Imported Product

Inicialmente:

Product

USB-C Hub

        ↓

1 Variation

SKU:
IMP-0001

Pero posteriormente un producto importado puede tener:

Color

Size

Capacity

y múltiples Variations.

Cake

Product

Chocolate Cake

        ↓

Variations

├── Small
├── Medium
└── Large

Por tanto el pastel será nuestro primer ejemplo real de múltiples Variations.

10. Nuestra arquitectura inicial

Podemos representar el diseño así:

STORE
Home Shop

   │
   ├── Product Type
   │   Used Product
   │       ↓
   │   Used Variation
   │
   ├── Product Type
   │   Imported Product
   │       ↓
   │   Imported Variation
   │
   └── Product Type
       Cake
           ↓
       Cake Variation

Más adelante podremos evaluar si realmente necesitamos mantener separados algunos de estos tipos.

Parte del aprendizaje consiste precisamente en revisar nuestras decisiones cuando conocemos mejor el dominio.

11. Stack de nuestra tienda

Partiremos de un proyecto Drupal moderno administrado mediante Composer.

Nuestra arquitectura será:

Drupal 11
   ↓
Drupal Commerce 3.x
   ↓
Custom configuration
   ↓
Custom theme / frontend later

Durante esta primera fase nos concentraremos en administración y arquitectura.

La apariencia visual puede esperar.

12. Crear un nuevo proyecto Drupal

Si comenzamos completamente desde cero podemos utilizar el proyecto recomendado de Drupal.

composer create-project drupal/recommended-project home-shop

cd home-shop

Después podemos preparar nuestro entorno local utilizando la herramienta que prefiramos.

Por ejemplo:

DDEV

En nuestra serie asumiremos que Drupal ya está correctamente instalado y funcionando antes de añadir Commerce.

13. Instalar Drupal Commerce

Commerce debe instalarse mediante Composer.

Para Commerce 3.x:

composer require 'drupal/commerce:^3.3'

Composer instalará Commerce y sus dependencias PHP.

Después podemos comprobar los módulos disponibles:

drush pm:list --filter=commerce

Commerce se distribuye como un conjunto de módulos relacionados.

14. Commerce no es un único módulo funcional

Drupal Commerce está dividido en diferentes componentes.

Encontraremos módulos relacionados con conceptos como:

Commerce

Store

Product

Order

Cart

Checkout

Payment

Price

Promotion

Tax

Log

Esta división refleja la arquitectura que hemos estudiado durante toda la serie.

No se trata de un monolito.

15. Habilitar Commerce

Podemos habilitar el conjunto principal mediante Drush.

Por ejemplo:

drush en commerce -y

Dependiendo de nuestro proyecto también podemos habilitar explícitamente componentes concretos posteriormente.

Después:

drush cr

Una vez habilitado Commerce aparecerán nuevas secciones administrativas relacionadas con la tienda.

16. No instalaremos todavía Shipping

Nuestros primeros productos serán físicos.

Podríamos pensar que deberíamos instalar inmediatamente Commerce Shipping.

Pero no lo haremos todavía.

Primero queremos dominar:

Store

Products

Variations

Attributes

Orders

Después añadiremos Shipping conscientemente.

Esto nos permite comprender qué funcionalidad pertenece a Commerce Core y cuál procede de módulos adicionales.

17. Tampoco instalaremos un Payment Gateway todavía

No comenzaremos instalando Stripe o PayPal.

Primero construiremos correctamente nuestra tienda.

Más adelante podremos instalar un Gateway de prueba.

Durante desarrollo también podemos trabajar con opciones de pago manual para comprender el flujo sin depender inicialmente de servicios externos.

18. Primera decisión: moneda

Nuestra tienda familiar necesita una moneda base.

Supongamos que opera inicialmente en Ecuador.

Utilizaremos:

USD

Ecuador utiliza el dólar estadounidense, por lo que para nuestro ejemplo no necesitamos conversión de moneda.

Esto simplifica mucho nuestra primera implementación.

19. Crear nuestra primera Store

Una instalación Commerce necesita al menos una Store para vender productos.

Conceptualmente crearemos:

Store Type

Online Store

y:

Store

Home Shop

Por ahora tendremos:

1 Store

No necesitamos una Store para cada familia de productos.

20. Datos iniciales de la Store

Nuestra Store podría configurarse conceptualmente con:

Name:
Home Shop


Default Currency:
USD


Email:
store@example.com


Country:
Ecuador

La dirección exacta dependerá del negocio real.

En un proyecto de producción también debemos configurar correctamente la información comercial y fiscal correspondiente.

21. ¿Necesitamos varias Stores?

No.

No necesitamos:

Used Store

Imported Store

Cake Store

porque estas categorías pertenecen al mismo negocio.

Tenemos:

Home Shop
   │
   ├── Used Products
   ├── Imported Products
   └── Cakes

Una única Store es suficiente.

22. Crear categorías

Antes de crear productos podemos preparar una Taxonomy.

Por ejemplo:

Vocabulary:

Product Category

Con términos:

Electronics

Home

Furniture

Photography

Books

Food

Cakes

Más adelante podremos construir una jerarquía más completa.

23. Crear una clasificación de origen

También puede ser útil registrar cómo obtenemos cada producto.

Podríamos crear:

Vocabulary:

Product Origin

Con términos:

Used

Imported

Local Production

Esto nos permitirá posteriormente revisar si todavía tiene sentido mantener separados:

Used Product

Imported Product

o si podemos consolidarlos.

24. Crear una clasificación de condición

Los productos usados necesitan indicar su estado.

Podríamos utilizar una Taxonomy:

Product Condition

├── Like New
├── Very Good
├── Good
├── Fair
└── For Parts

O un field con opciones predefinidas.

Para este ejercicio utilizaremos Taxonomy porque queremos permitir:

• Filtros
• Páginas por condición
• Administración centralizada de términos

25. Diseñar Used Product

Nuestro primer Product Type será:

Used Product

Podría tener:

Title

Description

Category

Condition

Images

Visible Defects

Original Purchase Year

Mientras la Variation contendrá:

SKU

Price

Más adelante añadiremos inventario.

26. Diseñar Imported Product

Nuestro segundo Product Type:

Imported Product

Podría contener:

Title

Description

Brand

Category

Images

Country of Origin

La Variation:

SKU

Price

Más adelante puede incorporar Attributes y stock.

27. Diseñar Cake

Nuestro tercer Product Type será:

Cake

El Product podría contener:

Title

Description

Images

Ingredients

Allergen Information

Category

Las Variations representarán las opciones que realmente vendemos.

Small

Medium

Large

Cada una puede tener:

SKU

Price

Size

28. Size será nuestro primer Product Attribute

Crearemos conceptualmente:

Product Attribute

Cake Size

Con valores:

Small

Medium

Large

Entonces:

Product

Chocolate Cake

        ↓

Variations

├── Small
├── Medium
└── Large

Esto nos permitirá practicar la relación entre:

Product

Variation Type

Attribute

Variation

29. ¿Y el sabor?

Aquí debemos detenernos antes de crear otro Attribute.

Supongamos que tenemos:

Chocolate Cake

Vanilla Cake

Carrot Cake

Debemos preguntar:

¿Son sabores seleccionables del mismo producto o son productos diferentes?

Podríamos diseñar:

Product:
Birthday Cake

Attributes:

Flavor
├── Chocolate
├── Vanilla
└── Carrot

Size
├── Small
├── Medium
└── Large

Esto produciría hasta:

3 flavors
×
3 sizes
=
9 variations

Pero quizás para el negocio tenga más sentido:

Product:
Chocolate Cake

Variations:
Small
Medium
Large


Product:
Vanilla Cake

Variations:
Small
Medium
Large

Para nuestro ejercicio utilizaremos este segundo modelo.

El sabor definirá el Product y el tamaño definirá la Variation.

30. Por qué elegimos este modelo

Porque queremos que cada tipo de pastel tenga:

• Fotografías propias
• Descripción propia
• Ingredientes propios
• Información de alérgenos propia

Mientras el tamaño modifica principalmente:

• Precio
• SKU
• Cantidad aproximada de porciones

Por tanto:

Flavor / recipe
        ↓
Product


Size
        ↓
Variation

Esta es precisamente la clase de razonamiento que debemos aprender a realizar.

31. Nuestra arquitectura inicial completa

STORE
Home Shop

│
├── USED PRODUCT
│      │
│      └── Used Variation
│
├── IMPORTED PRODUCT
│      │
│      └── Imported Variation
│
└── CAKE
       │
       └── Cake Variation
              │
              └── Attribute
                  Size

Clasificaciones compartidas:

Taxonomies

Product Category

Product Origin

Product Condition

32. Nuestro primer producto real

Para comprobar la instalación comenzaremos con un artículo usado.

Por ejemplo:

Product

Used Canon Camera

Datos:

Title:
Canon EOS Camera usada


Category:
Photography


Condition:
Good


Description:
Cámara usada en buen estado.


Visible defects:
Small scratches on body.

Variation:

SKU:
USED-CAMERA-001


Price:
250 USD

Tendremos:

Product
Canon EOS Camera usada

        ↓

Variation
USED-CAMERA-001

        ↓

250 USD

33. Por qué incluso el producto usado necesita Variation

Este ejemplo refuerza uno de los conceptos fundamentales de Commerce.

Tenemos solamente una cámara.

No existen:

Colors

Sizes

Capacities

Pero seguimos necesitando:

Product
        ↓
Product Variation

porque la Variation es la entidad comprable.

La cámara puede tener una única Variation.

34. Nuestro segundo producto será importado

Posteriormente añadiremos:

Product

USB-C Multiport Hub

con:

SKU:
IMP-HUB-001


Price:
35 USD

Esto nos permitirá comparar los dos Product Types.

Quizás descubramos que su estructura es suficientemente similar como para consolidarlos.

Esa revisión forma parte del proceso de arquitectura.

35. Nuestro tercer producto será un pastel

Finalmente añadiremos:

Product

Chocolate Cake

con:

Variation #1

Size:
Small

SKU:
CAKE-CHO-S

Price:
15 USD


Variation #2

Size:
Medium

SKU:
CAKE-CHO-M

Price:
25 USD


Variation #3

Size:
Large

SKU:
CAKE-CHO-L

Price:
40 USD

Este será nuestro primer producto con Attributes y múltiples Variations.

36. ¿Dónde colocaremos las fotografías?

En nuestros primeros ejemplos utilizaremos imágenes a nivel de Product.

Por ejemplo:

Used Camera

Images
├── front.jpg
├── back.jpg
└── scratch-detail.jpg

y:

Chocolate Cake

Images
├── cake-main.jpg
└── cake-detail.jpg

Si posteriormente diferentes Variations tienen imágenes diferentes, podremos mover o añadir imágenes a nivel de Variation.

37. ¿Dónde colocaremos el stock?

Todavía no.

Es importante no confundir:

Published
        ↓
Product visibility

con:

Stock
        ↓
Inventory availability

Más adelante estudiaremos explícitamente cómo manejar inventario.

Para un artículo usado queremos eventualmente:

Initial Stock
1

y después de comprarlo:

Stock
0

Pero no intentaremos implementar esto mediante un simple campo improvisado.

38. Tampoco modelaremos todavía el costo de importación como Price

Supongamos:

USB Hub

Purchase price:
15 USD

Import cost:
5 USD

Final internal cost:
20 USD

Sale price:
35 USD

Commerce Price representa el precio comercial de venta.

Los costos internos pertenecen a otro problema.

Más adelante podemos decidir si necesitamos almacenar:

Purchase Cost

Import Cost

Margin

para reporting interno.

No debemos mezclar automáticamente:

Cost
        ≠
Selling Price

39. Prepararnos para servicios sin implementarlos

Nuestro diseño también debe permitir una futura incorporación de servicios.

Por ejemplo:

Product Type

Service

Podría tener:

Title

Description

Duration

Requirements

Y una Variation:

SKU

Price

Un servicio puede ser perfectamente una entidad comprable sin necesitar Shipping.

Esto confirma por qué no queremos acoplar toda nuestra arquitectura a productos físicos.

40. Configuración frente a contenido

Durante esta implementación debemos distinguir cuidadosamente dos tipos de información.

Configuration

Product Types

Variation Types

Fields

Taxonomies definitions

Attributes

Order Types

Checkout Flows

Esta configuración normalmente forma parte de nuestro sistema de configuración Drupal.

Content

Canon Camera

USB Hub

Chocolate Cake

Small Variation

Medium Variation

Estos son datos comerciales.

La separación es importante para nuestro proceso de desarrollo y deployment.

41. Exportaremos la configuración

Una vez creada la arquitectura podremos exportarla utilizando:

drush cex -y

Después podremos revisar los cambios en:

config/sync

o en el directorio de configuración utilizado por nuestro proyecto.

Deberíamos poder identificar archivos relacionados con:

commerce_product_type

commerce_product_variation_type

commerce_product_attribute

field.storage

field.field

taxonomy.vocabulary

Esto será especialmente útil para aprender cómo Commerce representa su configuración internamente.

42. No exportamos el catálogo como configuración

Cuando ejecutamos:

drush cex

no esperamos encontrar:

Canon Camera

USB Hub

Chocolate Cake

porque estos productos son entidades de contenido.

Lo que exportamos es la arquitectura que permite crearlos.

Configuration
        ↓
¿Qué tipos de cosas podemos vender?


Content
        ↓
¿Qué cosas estamos vendiendo?

43. Secuencia práctica de nuestra tienda

Nuestra implementación seguirá aproximadamente este orden:

1. Drupal

2. Commerce

3. Store

4. Taxonomies

5. Product Types

6. Variation Types

7. Product Attributes

8. Fields

9. Used Product

10. Imported Product

11. Cake

12. Cart

13. Checkout

14. Payment

15. Inventory

16. Shipping

17. Promotions

18. Taxes

19. Services

No todos los proyectos reales deben seguir exactamente este orden.

Pero para aprendizaje nos permitirá introducir los conceptos progresivamente.

44. Nuestra primera milestone

Al terminar esta primera fase deberíamos ser capaces de navegar administrativamente por una arquitectura similar a:

Commerce

├── Store
│   └── Home Shop
│
├── Products
│   ├── Used Product
│   ├── Imported Product
│   └── Cake
│
├── Product Variations
│   ├── Used Variation
│   ├── Imported Variation
│   └── Cake Variation
│
└── Product Attributes
    └── Cake Size

Y deberíamos poder crear:

Canon Camera usada
        ↓
250 USD


USB-C Hub
        ↓
35 USD


Chocolate Cake
        ↓
Small  15 USD
Medium 25 USD
Large  40 USD

45. Qué no vamos a hacer todavía

Para mantener clara esta fase, todavía no configuraremos:

Real Payment Gateway

Shipping

Inventory

Taxes

Promotions

Coupons

ERP integrations

Invoices

Services

Todos estos componentes tendrán su propio momento.

Primero queremos tener un catálogo correctamente modelado.

46. Nuestro principio de trabajo

A lo largo de la implementación utilizaremos la misma regla aplicada durante toda la serie:

Primero entendemos qué necesita el negocio. Después decidimos cómo representarlo en Drupal Commerce. Finalmente configuramos Drupal.

No utilizaremos la interfaz para descubrir nuestro modelo.

Utilizaremos la interfaz para implementar un modelo que podamos explicar.

47. Checklist de esta primera etapa

Antes de continuar deberíamos tener claro:

Store

• Una única Store
• Moneda USD
• Negocio inicialmente local

Product Types

• Used Product
• Imported Product
• Cake

Variation Types

• Used Variation
• Imported Variation
• Cake Variation

Attributes

• Cake Size

Taxonomies

• Product Category
• Product Origin
• Product Condition

Future

• Inventory
• Shipping
• Payment Gateway
• Services

48. Modelo mental inicial

Nuestra primera implementación puede resumirse así:

HOME SHOP
   │
   ▼
STORE
   │
   ├───────────────────────┐
   │                       │
   ▼                       ▼
USED PRODUCTS        IMPORTED PRODUCTS
   │                       │
   ▼                       ▼
VARIATION               VARIATION
   │                       │
   ▼                       ▼
PRICE                   PRICE


              CAKES
                │
                ▼
             PRODUCT
                │
                ▼
          CAKE VARIATIONS
                │
          ┌─────┼─────┐
          ▼     ▼     ▼
        Small Medium Large
          │     │     │
          ▼     ▼     ▼
        Price Price Price

Posteriormente:

Products
   ↓
Cart
   ↓
Checkout
   ↓
Payment
   ↓
Shipping
   ↓
Order Completion

Conclusión

Con este artículo comenzamos la transición desde arquitectura conceptual hacia implementación real.

Nuestro negocio de ejemplo nos permitirá trabajar con varios patrones importantes:

Used Product
= producto normalmente único


Imported Product
= producto repetible
  con posible inventario


Cake
= producto con Variations


Service
= futura entidad comprable
  sin Shipping

La primera lección práctica sigue siendo arquitectónica.

No debemos instalar módulos ni crear campos simplemente porque pueden parecernos útiles.

Primero definimos qué queremos representar.

Nuestra arquitectura inicial será:

1 Store

3 Product Types

3 Variation Types

1 Product Attribute

3 Taxonomies

y evolucionará solamente cuando aparezca una necesidad real.

En el siguiente artículo comenzaremos directamente dentro de Drupal: crearemos la Store, los Product Types y los Product Variation Types.

Además examinaremos las opciones que aparecen en cada formulario administrativo y explicaremos qué significa cada una, en lugar de limitarnos a indicar qué botones debemos pulsar.