Feat: Restructuring Products into the Concern Catalog, for future Collection services
This commit is contained in:
+2
-2
@@ -1206,6 +1206,6 @@ Real bugs/traps hit while building against Lunar in this package — not obvious
|
||||
- **`ProductOption.handle` must be unique and non-null if a product has more than one option.** Lunar's Filament variant-switcher widget does `SelectFilter::make($option->handle)` per option — two options with a `null`/matching handle throws "Filter must have a unique name" as a 500 when opening that product's variant pricing page. Always derive a slug and check uniqueness.
|
||||
- **`Attribute.position` is per-group, and the panel sorts by it.** Hardcoding `position => 1` for multiple new attributes in the same group makes their order undefined/collide with existing attributes at position 1. Compute `max('position') + 1` per group instead.
|
||||
- **Currency `decimal_places` isn't always 2.** A seeded/demo currency can have the wrong value (seen: EUR seeded with `decimal_places = 1`), which silently corrupts every price display (`€16.50` renders as `165`). If prices look wrong by a factor of 10, check the currency row before assuming the price-writing code is broken.
|
||||
- **`Builder::paginateRaw()`'s `items()` is not a hit list on the Meilisearch driver.** It contains the *entire* raw response (`hits`, `query`, `processingTimeMs`, `hitsPerPage`, `page`, `totalPages`, `totalHits`) as one associative array. Treating `$paginator->items()` as a plain list (e.g. `collect($paginator->items())->values()`) silently produces 7 elements — the real hits array happens to land first, the rest are stray scalars from the other response keys — no error, just corrupted data. Pull `$paginator->items()['hits']` explicitly. `total()`/`perPage()`/`currentPage()`/`lastPage()` on the paginator are unaffected. See `Modules\Core\Product\Services\ProductService` / `docs/product-listing.md`.
|
||||
- **`ProductOption`/`ProductOptionValue::$name` is not `attribute_data` — `translateAttribute('name')` silently returns null for them.** Unlike `Product`/`Collection`/`Brand`, their translated `name` is a plain locale-keyed array cast (`AsArrayObject`) directly on the column, not stored in `attribute_data`. `HasTranslations::translateAttribute()` only reads `attribute_data`, so calling it on these two models compiles fine and returns `null` with no error — read the array directly instead (`$value->name[$locale] ?? ...`). See `Modules\Core\Product\Services\ProductIndexer::translatedName()`.
|
||||
- **`Builder::paginateRaw()`'s `items()` is not a hit list on the Meilisearch driver.** It contains the *entire* raw response (`hits`, `query`, `processingTimeMs`, `hitsPerPage`, `page`, `totalPages`, `totalHits`) as one associative array. Treating `$paginator->items()` as a plain list (e.g. `collect($paginator->items())->values()`) silently produces 7 elements — the real hits array happens to land first, the rest are stray scalars from the other response keys — no error, just corrupted data. Pull `$paginator->items()['hits']` explicitly. `total()`/`perPage()`/`currentPage()`/`lastPage()` on the paginator are unaffected. See `Modules\Core\Catalog\Services\ProductService` / `docs/product-listing.md`.
|
||||
- **`ProductOption`/`ProductOptionValue::$name` is not `attribute_data` — `translateAttribute('name')` silently returns null for them.** Unlike `Product`/`Collection`/`Brand`, their translated `name` is a plain locale-keyed array cast (`AsArrayObject`) directly on the column, not stored in `attribute_data`. `HasTranslations::translateAttribute()` only reads `attribute_data`, so calling it on these two models compiles fine and returns `null` with no error — read the array directly instead (`$value->name[$locale] ?? ...`). See `Modules\Core\Catalog\Services\ProductIndexer::translatedName()`.
|
||||
- **A running `queue:work` process does not pick up an edited/newly-added Scout indexer class.** It loads PHP classes once at boot and keeps them for the process's lifetime. Symptoms: reindexing commands succeed with no errors, calling `toSearchableArray()` directly (e.g. via `artisan tinker`, which always boots fresh) returns the new fields correctly, but documents written via `$model->searchable()` through the live queue are still missing them. Restart the queue worker after deploying an indexer change — no code fix needed.
|
||||
|
||||
+11
-11
@@ -1,10 +1,10 @@
|
||||
# Product Listing
|
||||
|
||||
`Modules\Core\Product\Services\ProductService` provides catalog browsing/filtering AND single-product
|
||||
`Modules\Core\Catalog\Services\ProductService` provides catalog browsing/filtering AND single-product
|
||||
lookup for a storefront — `list()`, `getById()`, `getBySlug()` — all reading directly from the
|
||||
Meilisearch index rather than the database. One data source for everything this service does.
|
||||
|
||||
This is separate from `Modules\Core\Product\Services\ProductSearchService` (see `product-search.md`), which
|
||||
This is separate from `Modules\Core\Catalog\Services\ProductSearchService` (see `product-search.md`), which
|
||||
handles free-text query search. `ProductService` is for browsing/lookup without a search term.
|
||||
|
||||
---
|
||||
@@ -14,7 +14,7 @@ handles free-text query search. `ProductService` is for browsing/lookup without
|
||||
Every method here reads Meilisearch documents directly and returns plain arrays — never Scout's
|
||||
`->get()`, which would re-hydrate Eloquent models from the database. This means the index has to
|
||||
carry everything a detail page needs (variants, prices, options, media, reviews — see below), not
|
||||
just the trimmed fields a listing page needs. `Modules\Core\Product\Services\ProductIndexer` is built to
|
||||
just the trimmed fields a listing page needs. `Modules\Core\Catalog\Services\ProductIndexer` is built to
|
||||
carry that full shape.
|
||||
|
||||
---
|
||||
@@ -22,9 +22,9 @@ carry that full shape.
|
||||
## Usage
|
||||
|
||||
```php
|
||||
use Modules\Core\Product\DTOs\ProductFilters;
|
||||
use Modules\Core\Product\Services\ProductService;
|
||||
use Modules\Core\Product\Enums\ProductSort;
|
||||
use Modules\Core\Catalog\DTOs\ProductFilters;
|
||||
use Modules\Core\Catalog\Services\ProductService;
|
||||
use Modules\Core\Catalog\Enums\ProductSort;
|
||||
|
||||
$service = app(ProductService::class);
|
||||
|
||||
@@ -62,11 +62,11 @@ All `ProductFilters` fields are optional; only the ones set are added to the Mei
|
||||
|
||||
---
|
||||
|
||||
## Fields this depends on: `Modules\Core\Product\Services\ProductIndexer`
|
||||
## Fields this depends on: `Modules\Core\Catalog\Services\ProductIndexer`
|
||||
|
||||
Lunar's own `Lunar\Search\ProductIndexer` only carries listing-grade fields (name, description,
|
||||
status, brand, a single thumbnail, skus) and marks just `__soft_deleted`, `skus`, `status` as
|
||||
filterable. `Modules\Core\Product\Services\ProductIndexer` extends it to add everything `ProductService`
|
||||
filterable. `Modules\Core\Catalog\Services\ProductIndexer` extends it to add everything `ProductService`
|
||||
needs, listing and detail alike:
|
||||
|
||||
| Field | Source | Notes |
|
||||
@@ -149,9 +149,9 @@ variants don't.
|
||||
|
||||
## Sorting
|
||||
|
||||
`ProductSort` (`Modules\Core\Product\Enums\ProductSort`) is a fixed enum of supported sort orders —
|
||||
`ProductSort` (`Modules\Core\Catalog\Enums\ProductSort`) is a fixed enum of supported sort orders —
|
||||
`PriceAsc`, `PriceDesc`, `Newest` — each mapping to a Meilisearch `sort` clause against a field
|
||||
`Modules\Core\Product\Services\ProductIndexer::getSortableFields()` marks sortable (`price`, plus
|
||||
`Modules\Core\Catalog\Services\ProductIndexer::getSortableFields()` marks sortable (`price`, plus
|
||||
`created_at`/`updated_at`/`skus`/`status` inherited from Lunar's base indexer). Adding a new
|
||||
`ProductSort` case requires adding the matching field to `getSortableFields()` and re-syncing (see
|
||||
below) — sortable attributes are index settings, not computed per-query, same as filterable ones.
|
||||
@@ -168,7 +168,7 @@ Not automatic — an app opts in via its own `config/lunar/search.php`:
|
||||
|
||||
```php
|
||||
'indexers' => [
|
||||
Lunar\Models\Product::class => Modules\Core\Product\Services\ProductIndexer::class,
|
||||
Lunar\Models\Product::class => Modules\Core\Catalog\Services\ProductIndexer::class,
|
||||
// ...other model indexers unchanged
|
||||
],
|
||||
```
|
||||
|
||||
@@ -6,7 +6,7 @@ Each `ProductOptionValue` carries a free-form `meta` jsonb column, but nothing i
|
||||
Lunar's own admin UI exposes it — there's no way for an admin to, say, attach a hex
|
||||
code to a "Red" value without editing the database directly.
|
||||
|
||||
`Modules\Core\Product\Contracts\ProductOptionTypeInterface` describes how a category
|
||||
`Modules\Core\Catalog\Contracts\ProductOptionTypeInterface` describes how a category
|
||||
of option behaves — what structured data its values carry in `meta`, and how an
|
||||
admin edits that data — without introducing a new model. `ProductOption`/
|
||||
`ProductOptionValue` stay exactly as Lunar defines them.
|
||||
@@ -19,7 +19,7 @@ A shop registers a type class from its own service provider's `boot()`, the same
|
||||
shape as `Modules\Core\Notification\NotificationRegistry`:
|
||||
|
||||
```php
|
||||
use Modules\Core\Product\Services\ProductOptionTypeManager;
|
||||
use Modules\Core\Catalog\Services\ProductOptionTypeManager;
|
||||
|
||||
ProductOptionTypeManager::get()->register([
|
||||
\App\ProductOptions\ColorOptionType::class,
|
||||
@@ -44,7 +44,7 @@ name/position, no extra meta form.
|
||||
namespace App\ProductOptions;
|
||||
|
||||
use Filament\Forms\Components\ColorPicker;
|
||||
use Modules\Core\Product\Contracts\ProductOptionTypeInterface;
|
||||
use Modules\Core\Catalog\Contracts\ProductOptionTypeInterface;
|
||||
|
||||
class ColorOptionType implements ProductOptionTypeInterface
|
||||
{
|
||||
@@ -70,8 +70,8 @@ plain jsonb column). `getKey()` is the identifier used in the admin's "Option Ty
|
||||
dropdown and in `ProductOption::meta['option_type']` — it has no relationship to the
|
||||
`ProductOption::handle`.
|
||||
|
||||
A reference implementation ships at `Modules\Core\Product\OptionTypes\ColorOptionType`,
|
||||
registered automatically by `Modules\Core\Providers\ProductServiceProvider` — no shop
|
||||
A reference implementation ships at `Modules\Core\Catalog\OptionTypes\ColorOptionType`,
|
||||
registered automatically by `Modules\Core\Providers\CatalogServiceProvider` — no shop
|
||||
setup needed for it to appear in the "Option Type" dropdown, though an admin still
|
||||
has to pick it per-`ProductOption` for it to take effect.
|
||||
|
||||
@@ -79,7 +79,7 @@ has to pick it per-`ProductOption` for it to take effect.
|
||||
|
||||
## How it's wired into the admin UI
|
||||
|
||||
`Modules\Core\Product\Services\ProductOptionTypeManager` is a singleton registry:
|
||||
`Modules\Core\Catalog\Services\ProductOptionTypeManager` is a singleton registry:
|
||||
- `get(): static` — the shared instance.
|
||||
- `register(array $types): void` — registers one or more type classes, keyed
|
||||
internally by `getKey()`.
|
||||
@@ -93,11 +93,11 @@ Two extensions hook into Lunar's admin via its extension system
|
||||
(`LunarPanel::extensions([...])`, registered in `CorePlugin`) — no forking of Lunar's
|
||||
classes needed:
|
||||
|
||||
- `Modules\Core\Product\Filament\Extensions\ProductOptionResourceExtension` extends
|
||||
- `Modules\Core\Catalog\Filament\Extensions\ProductOptionResourceExtension` extends
|
||||
`Lunar\Admin\Filament\Resources\ProductOptionResource`'s own form with a `Select`
|
||||
(`meta.option_type`) listing every enabled type's key. Shown only when at least one
|
||||
type is enabled.
|
||||
- `Modules\Core\Product\Filament\Extensions\ValuesRelationManagerExtension` extends
|
||||
- `Modules\Core\Catalog\Filament\Extensions\ValuesRelationManagerExtension` extends
|
||||
the "Values" tab's form. Its `extendForm()` reads
|
||||
`$option->meta['option_type']` off the owning `ProductOption`, resolves it via
|
||||
`ProductOptionTypeManager`, and appends `getMetaForm()`'s fields to the stock name
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Product Search
|
||||
|
||||
`Modules\Core\Product\Services\ProductSearchService` provides locale-aware full-text product search on
|
||||
`Modules\Core\Catalog\Services\ProductSearchService` provides locale-aware full-text product search on
|
||||
top of Laravel Scout + Meilisearch.
|
||||
|
||||
---
|
||||
@@ -24,7 +24,7 @@ merges `$builder->options` directly into the search request).
|
||||
## Usage
|
||||
|
||||
```php
|
||||
use Modules\Core\Product\Services\ProductSearchService;
|
||||
use Modules\Core\Catalog\Services\ProductSearchService;
|
||||
|
||||
$results = app(ProductSearchService::class)->search('running shoes');
|
||||
// or an explicit locale, bypassing App::getLocale():
|
||||
|
||||
Reference in New Issue
Block a user