Many shops already hold passport data in their WooCommerce products, as attributes: a "Composition" attribute on each garment, a "Country of origin" on each item. DPTag reads those when it creates a passport, and treats them as the most reliable source there is, since they were written for that very product.
Which attributes are read
Four passport fields can be filled from attributes. An attribute is matched by its name, compared without regard to case or accents, in English or French:
| Passport field | Attribute names recognised |
|---|---|
| Materials (composition) | Composition, Material, Materials, Fabric, Matière, Matières, Tissu |
| Country of origin | Country of origin, Country, Origin, Made in, Pays d'origine, Pays, Origine |
| Care instructions | Care instructions, Care, Washing, Entretien, Lavage |
| Certifications | Certifications, Certification, Labels, Label |
Both kinds of WooCommerce attributes work: global attributes, the ones defined under Products, then Attributes, and shared across products, and custom attributes typed on a single product. For a global attribute, the names of the selected terms are used; for a custom one, its values. Several values are joined with commas.
The composition attribute goes through the same parser as the category composition: "95% organic cotton, 5% elastane" becomes two materials with their percentages, in either order and in either language. Details on the composition page.
Other passport fields, the warranty or the recycling instructions for instance, are not read from attributes. They come from the defaults, or from the form.
Attributes win
When a passport is created, a recognised attribute beats everything else for its field: the category composition, the store default, and the AI. The reasoning is that an attribute is a fact someone entered about this exact product, whereas a default is a rule that holds for most products and the AI is an inference from text. Known data beats inference.
That also means the AI never touches a field filled from an attribute, even when the option to double-check store defaults is on: that option only reaches store-wide defaults, never a category value and never an attribute.
Two ways to use this
If your attributes are already there, nothing to do: run the wizard or the bulk action and the passports pick them up. This is the best case, and the reason to keep composition and origin as attributes rather than as free text in a description, which the plugin cannot read without AI.
If they are not, there is no need to create them for the passport's sake. Categories and store defaults cover the same ground with far less typing, and the passport form holds whatever is specific to one product. Attributes are worth adding when they serve the shop itself, as filters or variations; the passport benefits from them as a side effect.
Timing
Like the defaults, attributes are read once, when the passport is created. Editing an attribute afterwards does not update an existing passport, which keeps its own values; edit the passport, or recreate it if it is still a draft. A product whose attributes are filled after its passport was created gets nothing from them until then.