diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 94a8a47f..e8cedc9f 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -6,7 +6,7 @@ }, "metadata": { "description": "Claude skills for Dynamicweb 10 — organized by task domain, bundled by role.", - "version": "5.8.3" + "version": "5.8.4" }, "plugins": [ { diff --git a/CHANGELOG.md b/CHANGELOG.md index 465217f1..9e56dc43 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,6 +3,13 @@ All notable changes to the Dynamicweb Skills plugin are recorded here. The `version` field in `.claude-plugin/marketplace.json` tracks these entries. +## [5.8.4] + +- **`dw-demo-pim` `canonical-setup-order.md` step 8:** the catalog-rebuild traps (relations that + re-attach to a group recreated with an earlier id, `delete_groups` deleting the group's products) + now link to `dw-pim-modelling` `structural-model.md` §2.2, where the group types and their + relation tables are described. + ## [5.8.3] Fold of the presales build-journal learnings (DW 10.28.11, Swift 2.4.0, MCP add-in 0.6.0-beta): diff --git a/manifest.json b/manifest.json index 02574b3b..ea16332d 100644 --- a/manifest.json +++ b/manifest.json @@ -1,6 +1,6 @@ { "version": 2, - "generatedAt": "2026-09-29T10:38:38.989Z", + "generatedAt": "2026-09-29T10:42:24.932Z", "worksOn": { "dw": { "ring": "R1", diff --git a/skills/dw-demo-pim/references/canonical-setup-order.md b/skills/dw-demo-pim/references/canonical-setup-order.md index c6612394..676f4b96 100644 --- a/skills/dw-demo-pim/references/canonical-setup-order.md +++ b/skills/dw-demo-pim/references/canonical-setup-order.md @@ -95,9 +95,9 @@ No `ShopType=1` shop. Products live on `EcomGroupProductRelation` rows under `SH 7. **Data Models** via `create_data_model_structure` OR piecewise: create `EcomProductCategory` + translation → fields (in BOTH `reference_category` AND the concrete category, both with translations) → `EcomGroups` row with `GroupType=2` and `ProductCategoryId` set → `EcomShopGroupRelation` linking to SHOP-DATA. See `structural-model.md` §2.8 for the field-plumbing internals. 8. **Catalog groups** (GroupType=0) under SHOP1 — `save_groups` with shopId=SHOP1. **Pass `shopId` on SUBGROUPS too, in the same call as `parentGroupId`.** `save_groups {name, parentGroupId}` alone writes the `EcomGroupRelations` parent row and no `EcomShopGroupRelation` row, and DW resolves a group to its shop through that table without walking the parent chain: the branch renders in navigation and its PLP returns 200, while `ProductsByGroupId` returns 0 for products whose relation rows exist. Assert one `EcomShopGroupRelation` row per group before moving on (see [`structural-model.md`](../../dw-pim-modelling/references/structural-model.md) §2.2). - **Rebuilding on a host that already carried a catalog: products and group relations are not area-scoped.** Deleting an area (or rebuilding the storefront in a new one) leaves every product and every product-to-group relation behind, and a group recreated with an **earlier id** silently picks up the old relations: a rebuild that created 10 products found 20 in the index, the original 10 re-attached through `GROUP6`-`GROUP9` recreated with their old ids [dw 10.28.11 · mcp 0.6.0]. Before recreating groups, list what the host still holds (`get_groups`, and `get_products_by_group_id` per group id you are about to reuse), then either delete the orphaned products or give the new groups ids never used on this host. The hosted-publish variant of the same trap is in [`publish-to-hosted.md`](../../dw-demo-hosted/references/publish-to-hosted.md) ("Relation rows re-attach the stock catalog"). + **Rebuilding on a host that already carried a catalog: products and group relations are not area-scoped.** Deleting an area (or rebuilding the storefront in a new one) leaves every product and every product-to-group relation (`EcomGroupProductRelation`, keyed on the group id; the group and relation tables are in [`structural-model.md`](../../dw-pim-modelling/references/structural-model.md) §2.2) behind, and a group recreated with an **earlier id** silently picks up the old relations: a rebuild that created 10 products found 20 in the index, the original 10 re-attached through `GROUP6`-`GROUP9` recreated with their old ids [dw 10.28.11 · mcp 0.6.0]. Before recreating groups, list what the host still holds (`get_groups`, and `get_products_by_group_id` per group id you are about to reuse), then either delete the orphaned products or give the new groups ids never used on this host. The hosted-publish variant of the same trap is in [`publish-to-hosted.md`](../../dw-demo-hosted/references/publish-to-hosted.md) ("Relation rows re-attach the stock catalog"). - **`delete_groups` deletes the products in the group**, not only the group (its own tool description says it deletes all subgroups and products in each group); what it does to a product that is also related to another group is not measured. So never delete a stale group tree with products still in it: `remove_products_from_group` first, confirm `get_products_by_group_id` returns 0 for every group in the tree, then `delete_groups`. A stale top-level group tree is worth removing: the Swift navigation enumerates every top-level group of the shop, so a leftover data-model folder shows up as a nav entry. + **`delete_groups` deletes the products in the group**, not only the group (its own tool description says it deletes all subgroups and products in each group); what it does to a product that is also related to another group is not measured. So never delete a stale group tree with products still in it: `remove_products_from_group` first, confirm `get_products_by_group_id` returns 0 for every group in the tree, then `delete_groups`. How a data-model folder and its groups relate to products is in [`structural-model.md`](../../dw-pim-modelling/references/structural-model.md) §2.2. A stale top-level group tree is worth removing: the Swift navigation enumerates every top-level group of the shop, so a leftover data-model folder shows up as a nav entry. 9. **Variant Groups + Options** — `save_variant_groups`, `save_variant_options`. 10. **Products** — `create_products`. **Pass `neverOutOfStock: true` (or a real stock value) on every create.** `create_products` writes the product as a stock-tracked type with stock 0, so a create that omits both reads back `stockStatus: OutOfStock` and add-to-cart is disabled on the storefront; a batch of 30 landed that way [dw 10.28.11 · mcp 0.6.0]. Read `stockStatus` back with `get_products_by_ids` after each batch, and repair an already-created batch with `patch_products_safe`. Set `ProductType=2` on bundles afterward. **`create_products` ignores `languageId`** — products land on the default (master) language; on a non-default-language storefront translate/repoint them or the PLP renders empty (see [`localization.md`](localization.md) "create_products ignores languageId"). 11. **Relate products to data model groups** — `assign_data_model_to_products` (creates `EcomGroupProductRelation` to the DataModel group; that's how fields flow to the product). See `structural-model.md` §2.8 for the four-row reference_category mechanic this depends on.