Products & Product Displays (Drupal Commerce 1.x)

Uit De Vliegende Brigade
Ga naar: navigatie, zoeken

In Drupal Commerce zijn producten en hun representaties ontkoppelt:

  • Product: Producten bevatten de stamgegevens
  • Display: Een product komt pas tot leven als node als er een display mee correspondeert. Dat is een weergave van een specifieke hoeveelheid velden + presentatielaag.

In de praktijk probeer ik me zoveel mogelijk te beperken tot het gebruik van products. Standaard defineer ik bv. alle velden in een producttype. Echter, sommige zaken kunnen alleen op display-nivea geregeld worden: Voor sommige zaken heb je nu eenmaal een node nodig. Ik geloof dat clean url's daar een voorbeeld van is.

The game of the name

Ding op de achtergrond Ding op de voorgrond Opmerkingen
p1 p2 De namen zijn niet-intuïtief. Gebruik van cijfers wel
pt pd Flinke verbetering tov. omschrijvingen, ook al is pt (product type) achteraf een discutabele afkorting
Gebruikt voor tabelnamen → Gebruik cijfers
Product
Product instance
Commerce product (Feeds Importer)
Display
Product display
Product node
Product reference node[2]
Instanties van de betreffende objecten
Dikgedrukt: Aanbevolen namen
Product definition
Product type
Product variation
Display definition
Content type
Product node definition
Definities van de betreffende objecten. Zoiets als klasse-definities
Naamgeving is niet consistent (ihb. product type) - Geef het op

Inleiding

In Drupal Commerce zijn producten en de weergave van die producten gescheiden van elkaar:bron:

One of the most complicated things you will encounter when building a new Drupal Commerce site 
is product display configuration. Products are entities with intrinsic product ID, SKU, and 
title properties, as well as default price fields. They can be further customized using any 
number of product types and fields.

You can easily create products with the administrative interface, but your products will not be
automatically visible to users on the front end. Drupal Commerce separates the definition of a 
product from its display, allowing you to build custom displays using the tools the project 
provides such as the product reference field.

Net iets anders geformuleerd:

On a clean install of Drupal Commerce, simply adding products to the backend is not enough to 
display them for sale with an Add to Cart form. Drupal Commerce separates the definition (on 
the back end) from the display (on the front end) of a product.

Waarom?

Nou:

This separation lets you display the same product in any number of places without worrying about
data synchronization between the displays, a common problem for multilingual sites and multi-domain 
stores. It also lets you easily build displays referencing multiple products. Even so, you can 
still directly display product data through other means such as Views and Panels.

of:

This allows the same product definition to be used in any number of displays on the same site, 
across multiple domains, or through additional marketing channels while maintaining a single place 
where the core aspects of the product are administered (namely its SKU, price, and availability).

Ik denk dat ik ik er zelf ook wel raad mee weet:

  • Meertalige sites: De product-entiteiten bevatten de taalonafhankelijke zaken, zoals SKU, prijs en afbeelding. Met behulp van displays wordt bv. het body-veld in verschillende talen verzorgd
  • Amazon & verschillende sjablonen: Voor alle productgroepen heeft Amazon aparte sjablonen. Die kun je onderbrengen in aparte entiteiten, en in Displays laten samenkomen, afhankelijk van de productgroep
  • Google Shopping & subproducten: Ik heb een probleem met de matching binnen Google Shopping: Die matching vindt hoofdzakelijk plaats op grond van de titel ven een product. Maar vaak zoeken klanten niet op de titel, maar op een toepassing van een product. En sommige webwinkels (met name http://koolborstels-online.nl) hebben heel veel toepassingen per product. Ik wil die producten dus uitsplitsen in 'subproducten' per toepassing. Ik heb goede hoop dat dat kan dankzij Displays. Dus dat elke combinatie van een SKU en een toepassing een eigen landing page enzo wordt
  • Google Shopping & geaggregeerde producten: Dit is het tegengestelde van het voorbeeld hiervoor: Als iemand een generieke zoekterm invoert, zijn er meerdere passende producten. Het zou zo leuk zijn, als ik daar met Displays op kan inspelen, al lijkt het me onwaarschijnlijk
  • Union queries: Displays bieden de mogelijkheid om heterogene data samen te brengen, zoals in een union query. Dit is de sleutel om online marktplaatsen aan te bieden: Je hebt bv. 20 verschillende categorieën van producten, met allemaal hun stamgegevens, maar ook allemaal hun categorie-specifieke gegevens. Door deze scheiding tussen data en presentatie, kun je daarvan abstraheren waar dat relevant is. Je kunt namelijk data uit verschillende bronnen laten samenkomen in een display.

Nog een paar voorbeelden van Ryan:

  • Line items: Een line item is gewoon een andere display
  • Product variations: Een witte of een zwarte mok? Twee producten die een display delen, waarin je je kleur kiest ([3],18:38)

Technische achtergrond

Producten zijn geïmporteerd mbv. de Drupal Commerce Migrate-module. Die 3.216 producten zitten allemaal in de tabel commerce_product. Die dingen heten nodes, maar waarschijnlijk is Entities een betere benaming ([1],12:44). Een product-entity bestaat uit minimaal een SKU, Product-ID en Price. Dit kun je uitbreiden, maar je kunt ook alternatieve product-entities defineren
Vanaf het moment dat Drupal Commerce is geïnstalleerd, bestaan er Product-entities, maar pas als er een Display is gedefineerd, verschijnt dat in dit menu én producten moeten gekoppeld worden aan display-instanties middels een reference field

Product node definitie beschikbaar

  • Vanaf het begin is er een product node gedefineerd: Store » Products
  • Die product node definitie kun je uitbreiden qua velden.

Product Display aanmaken → Content-type aanmaken

Je kunt producten zichtbaar maken via Views of Panels, maar de standaard-manier is door een maatwerk content type aan te maken en daarin een referentie op te nemen naar het betreffende product.

Ik noem dit contenttype naar het soort van producten dat ermee worden opgeslagen. Als dat heel breed is, maak ik er desgewenst 'product' van. Ik gebruik meestal Nederlandse namen: Dan zie ik snel wat van mij is, en wat van het systeem is. En net als bij ER-diagrammen voor databases: Standaard gebruik ik enkelvoud. Tenzij de producten altijd per meerdere stuks verkocht worden.

Nodes & display linken

Het veld Product variations op de tweede regel, bevat de referentie naar de achterliggende product-entiteit
En hier zie je hoe alle velden in één keer worden weergegeven. Je hoeft dus geen data dubbel in te voeren. Dit verklaart wellicht ook de term product variation die aan het referentieveld was gegeven. Verder bevat deze Display meer referenties, en ook die zie je terug in dit totaalscherm.

P1 vs P2 - Welke velden waar?

Meestal is het onderscheid tussen P1 en P2 voor mij irrelevant, omdat ik bv. maar in één taal werk. Toch kan ik dit onderwerp niet compleet negeren (zie hieronder). Wat zijn de handigste instellingen?

Helaas: je hebt beide nodig

Zolang ik geen onderscheid hoef te maken tussen P1 en P2, ligt het voor de hand om P2 helemaal te negeren. Als ik bv. veel met views werk, heb ik P2 niet eens nodig. Helaas: Sommige funcitionaliteiten van Drupal werken alleen op P2-niveau (zie verderop). Je hebt dus beiden nodig.

Standaard alles in P1

Jeroen: Doe jezelf een lol, en probeer alles in P1 onder te brengen. Moeilijk doen met opsplitsen kan later.

Dingen die per se in P2 moeten

  • De core-module Path werkt op node-niveau en dus niet op product-niveau → Heb ik als gebruiker verder weinig van doen
  • Faceted Search?
  • Taxonomie?)

Voorbeeld dec. 2016

P1: Alles, inclusief body & productimage
P2: Nix. Dwz.: Referentieveld naar P1 + verplichte titelscherm

Zie ook

Bronnen

Achtergrond-info

Producten toevoegen