Skip to content

Product

First-Pass Node Dossier

This page is an evidence-backed node dossier generated from the domain hierarchy and node questionnaire.

What It Is

Product is the primary sellable catalog record in Pyle. It holds the core catalog identity for an item, links that item to its main taxonomy records, and acts as the parent record for pricing, inventory, media, related-product, and storefront product-page behavior.

Parent hierarchy:

  • Catalog & Merchandising
  • Product Core
  • Product

Primary implementation paths:

  • packages/framework/src/Models/Product.php
  • packages/framework/src/Actions/Product
  • packages/framework/src/Http/Controllers/Api/Admin/ProductsController.php
  • packages/admin/src/Livewire/Admin/Products
  • packages/admin/src/Livewire/Admin/Product

What Users Can Do With It

Direct capabilities

Admin users can:

  • create a product from the products list
  • edit the core product record on the product page
  • change brand, type, and primary category
  • manage stock-related, shipping-related, and quantity-related fields on the product page
  • manage product-owned media and related records from product sub-sections
  • create, update, and delete products through the admin API
  • import and export products and product-owned relations through Excel

Indirect capabilities

Other workflows use Product as the parent record without making the main product page the only management channel:

  • ERP hooks can update products
  • category relationships can be synchronized through category-specific flows
  • collection behavior can be driven by bulk import or collection-generation logic
  • product-group behavior is resolved from collection, type, and attribute data

Where It Is Managed

ChannelRoleNotes
Admin products listDirectCreate, list, search, and open product records
Admin product pageDirectMain packaged edit surface for core product fields
Admin APIDirectCRUD plus related flows such as category sync, policies, and shipping classes
Excel import/exportDirectBulk products plus product-owned relation sheets
ERP bridgeDirectProduct is ERP-syncable
StorefrontIndirectProduct is the main shopper-facing item, but storefront does not author it

Sources:

  • packages/admin/routes/web.php
  • packages/admin/src/Livewire/Admin/Products/CreateProductDialog.php
  • packages/admin/src/Livewire/Admin/Product/Page.php
  • packages/framework/src/Http/Controllers/Api/Admin/ProductsController.php
  • packages/admin/src/Livewire/Admin/Tools/Excel/ExportDialog/ProductExport.php
  • packages/admin/src/Livewire/Admin/Tools/Excel/ImportDialog/ProductImport.php
  • packages/framework/src/Services/ErpBridge/Product/ProductErpSyncService.php

Channel-Level Field Coverage

Admin create dialog

The packaged create flow exposes:

  • active
  • sku
  • barcode
  • name
  • product_manufacturer_id
  • product_type_id
  • product_category_id

Creation nuance:

  • the create dialog sends the product name as the initial description

Sources:

  • packages/admin/src/Livewire/Admin/Products/CreateProductDialog.php
  • packages/framework/src/Actions/Product/CreateProduct.php

Admin product page

The inspected product page exposes:

  • sku
  • barcode
  • name
  • description
  • active
  • discontinued
  • featured
  • product_manufacturer_id
  • product_type_id
  • product_category_id
  • shipping_weight_kg
  • shipping_width_in
  • shipping_length_in
  • shipping_height_in
  • quantity_per_skid
  • stock_tracking
  • stock_purchasable
  • taxable
  • quantity_min
  • quantity_max
  • msrp_price
  • stock_status

Sources:

  • packages/admin/src/Livewire/Admin/Product/Page.php

Admin API

The admin API allows CRUD and exposes list shaping for fields such as:

  • sku
  • barcode
  • name
  • description
  • slug
  • meta_title
  • meta_description
  • product_manufacturer_id
  • product_type_id
  • shipping and pricing measurement fields
  • stock fields
  • discontinued state

The admin show endpoint also includes product terms, product categories, and comments when requested.

Sources:

  • packages/framework/src/Http/Controllers/Api/Admin/ProductsController.php
  • packages/framework/src/Http/Resources/Admin/ProductResource.php

Model fields that exist but are not clearly exposed in the inspected packaged product page

Examples include:

  • external_id
  • product_collection_id
  • meta_title
  • meta_description
  • meta_keywords
  • tags
  • reviews_allowed
  • review_rating
  • stock_level
  • pricing_measure
  • pricing_base_measure
  • pricing_measure_unit
  • ordered_count
  • product_sample_id
  • data_last_updated_at

Some of these are available through API, import/export, or upstream sync paths instead of the inspected main admin product page.

Source:

  • packages/framework/src/Models/Product.php

Storefront field filtering

The storefront resource deliberately removes internal inventory and shipping detail fields such as:

  • stock_tracking
  • stock_level
  • shipment_dimensions
  • shipping dimensions and weight
  • ordered_count

It then nests user-facing related data such as:

  • brand
  • primary category
  • product type
  • product offers
  • additional categories
  • terms
  • policies
  • images
  • videos

Source:

  • packages/framework/src/Http/Resources/Storefront/ProductResource.php

Configuration And Data Model

Key model characteristics:

  • translatable
  • soft-deletable
  • searchable
  • ERP-syncable
  • activity-log aware
  • emits product lifecycle events when important fields change

Important field groups:

Field GroupPurpose
identitysku, barcode, translated name, translated slug
taxonomyproduct_type_id, product_category_id, product_collection_id, product_manufacturer_id
operational stateactive, featured, discontinued, taxable
shipping and quantityweight, dimensions, quantity_min, quantity_max, quantity_per_skid
stockstock_tracking, stock_purchasable, stock_status, stock_level
merchandising and SEOdescriptions, meta fields, tags

Creation and update rules:

  • brand, category, type, SKU, name, and description are required
  • translated slugs are generated on create
  • pricing measure fields are validated together when used

Sources:

  • packages/framework/src/Models/Product.php
  • packages/framework/src/Actions/Product/CreateProduct.php
  • packages/framework/src/Actions/Product/UpdateProduct.php

Relationships

Product directly relates to:

  • productManufacturer
  • productType
  • productCategory
  • productCategories
  • productCollection
  • productOffers
  • featuredOffers
  • productTerms
  • productAttributes
  • productSample
  • productCrossSells
  • productUpSells
  • images
  • videos
  • productDocuments
  • productPolicies
  • shipping classes
  • vendor mappings and vendor items

Practical dependencies:

  • pricing and promotion systems depend on the product record
  • inventory systems update sellable stock state on the product
  • storefront product pages use the product as the central payload
  • product groups depend on a product’s collection, type, and term values

Source:

  • packages/framework/src/Models/Product.php

Rules And Downstream Effects

Important behavior:

  • deleting a product deletes its product terms
  • restoring a product restores product terms through RestoreProductTerms
  • changing brand, collection, type, or active state dispatches dedicated product events
  • changing the product manufacturer after a previous manufacturer existed clears product_collection_id
  • storefront product-group payloads are only added when the request asks for with_product_groups

Practical downstream effects:

  • classification changes can alter browse behavior and grouped-selection behavior
  • changing brand can indirectly remove the product from collection-driven grouped-product behavior until the collection workflow re-aligns it
  • active state affects storefront visibility and many downstream flows
  • the product page is only one part of product ownership; images, videos, documents, cross-sells, and policies are managed in product-owned subflows

Sources:

  • packages/framework/src/Models/Product.php
  • packages/framework/src/Listeners/Product/RemoveProductCollection.php
  • packages/framework/src/Http/Resources/Storefront/ProductResource.php
  • packages/framework/src/Http/Controllers/Api/Admin/ProductsController.php

Integrations And Automation

Excel

The packaged product export supports a large catalog template with sheets such as:

  • products
  • product_categories
  • product_manufacturers
  • product_collections
  • product_types
  • product_attributes
  • product_images
  • product_documents
  • product_videos
  • product_terms
  • product_cross_sells
  • product_upsells

The packaged import flow uses the product import template to update products and several product-owned relation sheets.

Sources:

  • packages/admin/src/Livewire/Admin/Tools/Excel/ExportDialog/ProductExport.php
  • packages/framework/src/Actions/Exports/Product/ProductTemplatesExport.php
  • packages/admin/src/Livewire/Admin/Tools/Excel/ImportDialog/ProductImport.php
  • packages/framework/src/Actions/Import/Product/ProductImport.php

ERP bridge

Product is ERP-syncable, but the inspected ERP service supports hook-based and per-model sync rather than a simple collection-level sync action.

Source:

  • packages/framework/src/Services/ErpBridge/Product/ProductErpSyncService.php

Where It Appears To End Users

Product is first-class in the storefront.

The inspected storefront uses product data on:

  • product detail pages
  • product-group selection blocks
  • brand and category browse flows
  • collection-adjacent product suggestions

The storefront payload also exposes nested catalog context such as brand, category, type, terms, policies, and related options.

Sources:

  • packages/storefront/routes/web.php
  • packages/framework/src/Http/Resources/Storefront/ProductResource.php
  • packages/storefront/src/Livewire/Storefront/Product/ProductGroupBlock.php
  • packages/storefront/src/View/Components/Product/CollectionProducts.php

Current Documentation Takeaways

The three most important operator-level facts are:

  1. Product is the center of the catalog, but not every product-owned behavior is managed from one screen.
  2. The packaged create flow is intentionally smaller than the full product page and fills some fields by default.
  3. Collection and grouped-product behavior depend on fields that are not obviously visible in the main product page, so product ownership is broader than the primary edit form.

Open Questions

  • The inspected main product page does not clearly expose product_collection_id, even though collection membership is important to downstream grouping and storefront behavior.
  • Some SEO and pricing-measurement fields are present in the model and API but were not confirmed in the inspected packaged product page UI.