core/CHANGELOG.md

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog.

[0.15.0] - 2026-09-07

Changed

• Breaking: Modules\Core\Payment\Models\PaymentMethod is now the full DB-instance layer for Payment, same three-layer split (registry / DB instance / cross-cutting config) Shipping already has via ShippingMethod — see docs/payments.md. Every value that used to live in config('lunar.payments.types.{type}.*') (payment_driver, capture_mode, captured_status) moves onto the PaymentMethod row itself as real columns: driver (the new PaymentDriverRegistry key — NOT the same as type; two rows can share one driver), name (admin-facing label, nothing played this role before), capture_mode, captured_status, authorized_status, position (admin-controlled ordering, new — reorderable in the Filament table), driver_missing_at. config('lunar.payments.types') is gone entirely; config/ payment.php now holds only cart_pipeline (genuinely cross-cutting — every store gets the same pipeline wiring regardless of how many payment methods it configures).
• Breaking: Modules\Core\Payment\Services\PaymentDriverResolver is deleted, replaced by Modules\Core\Payment\Services\PaymentDriverRegistry — register(string $key, string $driverClass)/resolve(string $key): ?object/all(): array<string, string>. Deliberately knows nothing about PaymentMethod or the database (mirrors Lunar\Shipping\Managers\ ShippingManager's built-in-methods + Manager::extend() split, purpose-built rather than extending Illuminate\Support\Manager — Payment's drivers implement several independent capability interfaces at once, not one uniform contract). Built-ins (OfflinePaymentDriver as 'offline', StripePaymentDriver as 'stripe') registered in PaymentServiceProvider::boot(), exactly how Shipping::extend('acs', ...) already works.
• Breaking: Modules\Core\Checkout\Services\CheckoutService::getPaymentMethods() now returns Illuminate\Support\Collection<int, PaymentMethod> (ordered by position), not array<string>. A method is offered only once three independent checks all pass — enabled (admin turned it on), driver_missing_at is null (the driver class still exists), and the resolved driver's own Configurable::isConfigured() (its runtime requirements are met) — each failure meaning something different to an admin diagnosing why a method isn't showing up. initiatePayment() resolves the driver via the selected row's own driver column, not type.
• Modules\Core\Payment\Filament\Resources\PaymentMethodResource — canCreate()/canDelete() now both true (previously hardcoded false, since a row could only ever be a config-defined type before this release). New create/edit form (name, type, driver — a Select populated live from PaymentDriverRegistry::all(), capture_mode, captured_status, authorized_status); reorderable table (->reorderable('position')); a distinct "Driver status" icon column (separate from the enabled toggle) showing whether driver_missing_at is set.
• Modules\Core\Order\Listeners\ApplyResolvedPaymentStatus reads captured_status/ authorized_status off the PaymentMethod row (where('type', $event->type)) instead of config(...).
• Modules\Core\Command\InstallLunarCommand::seedPaymentMethods() no longer iterates config('lunar.payments.types') — it seeds exactly one opinionated cash-on-delivery starter row, every value a plain literal in the command itself (not sourced from config or the registry — a driver has no business carrying opinions about what its captured order status should be called; that's a merchant decision). Skip-if-exists, same as before.

Added

• php artisan boboko:payment:sync-drivers — reconciles every PaymentMethod row's driver against PaymentDriverRegistry, setting driver_missing_at when a driver no longer resolves (a package removed, a custom register() call deleted) and clearing it automatically if that driver is registered again in a later deploy. Deliberately its own standalone command, meant to run unconditionally on every container start/deploy (Dockerfile entrypoint, alongside migrate) — "did the set of registered drivers change" is a deploy-time event, cheap enough to check every time regardless of whether anything actually changed. Verified live: flags a row whose driver was manually corrupted, and auto-clears the flag once the driver resolves again.

• docs/payments.md — new "Registry, DB instance, and cross-cutting config" section: the three-layer split researched against Shipping's own already-existing pattern and three real e-commerce platforms (Shopify, WooCommerce, Medusa.js), the "would a store ever plausibly want two different answers to this" test for deciding config vs. DB-column placement, and the three-check availability chain.

• Modules\Core\Payment\Services\PaymentMethodCache (Cache::rememberForever, same pattern as Localization\Services\LanguageCache) + Modules\Core\Payment\Services\PaymentMethodService (create/update/delete/list) — the single read/write gateway for PaymentMethod now used by every Filament resource action (create, edit, edit-fee, delete, the inline enabled toggle) instead of the Eloquent model directly, so the cache is invalidated and PaymentMethodCreated/PaymentMethodUpdated/PaymentMethodDeleted/PaymentMethodsReordered dispatch on every write, with no exceptions other than Filament's own drag-to-reorder (which does a raw bulk SQL UPDATE on the position column directly via CanReorderRecords/reorderTable(), before afterReordering() fires — a confirmed, unavoidable Filament limitation; the reorder hook only clears the cache and dispatches PaymentMethodsReordered afterward). CheckoutService::getPaymentMethods() and ApplyResolvedPaymentStatus both now read through the cache instead of querying PaymentMethod directly.

• Modules\Core\Payment\Models\CoreTransaction (a Lunar\Models\Transaction subclass) + Modules\Core\Payment\Support\TransactionDriverAdapter, registered via Lunar\Facades\ModelManifest::replace(Lunar\Models\Contracts\Transaction::class, CoreTransaction::class) — the same contract-swap mechanism already used elsewhere for Customer/Staff. Fixes a real crash (InvalidArgumentException: Driver [cash-on-delivery] not supported) the first time anything called $transaction->refund()/->capture(): Lunar\Models\Transaction::driver() calls Lunar's own, entirely separate Lunar\Facades\Payments::driver() manager, which had never heard of any of this codebase's driver keys. CoreTransaction::driver() returns TransactionDriverAdapter instead, which resolves the transaction's real PaymentMethod/PaymentDriverRegistry driver and calls it — Lunar's own admin panel "Refund"/"Capture" buttons now transparently reach the real payment system underneath, including correctly reporting failure (not a silently-faked success) when the resolved driver doesn't implement SupportsRefunds/SupportsCaptures.

• TransactionDriverAdapter::refundVia(Transaction $transaction, ?string $driverKey, int $amount, ?string $notes = null) — refund through an explicitly chosen driver, independent of the one the original payment went through (e.g. a cash-on-delivery order refunded via Bank Transfer, which has no notion of the original offline payment at all). The order page's refund action gained a "Refund via" Select (every PaymentDriverRegistry driver implementing SupportsRefunds, defaulting to the transaction's own driver) that routes through this method instead of Lunar\Models\Transaction::refund(), whose fixed signature has no room for a driver override.

• Modules\Core\Payment\Drivers\BankTransferPaymentDriver (registered as 'bank-transfer') — manual/attested, same trust model as OfflinePaymentDriver: no gateway call, pay()/refund() decide success immediately on a staff member's say-so. Implements both SupportsPay and SupportsRefunds; exists specifically so a payment taken through a different method can still be refunded via bank transfer. The admin UI for receiving a payment this way (bank reference, notes, proof-of-transfer upload) is a follow-up — the driver itself is complete and usable via the registry today.

• Modules\Core\Order\Filament\Infolists\TransactionEntry (swapped in for Lunar's own Lunar\Admin\Support\Infolists\Components\Transaction via a new OrderTransactionsExtension::extendTransactionsRepeatableEntry() hook) — the order page's transaction cards now also show a note recorded in Transaction.meta['notes'] when the notes column itself is empty. Order\Services\TransactionRecorder only ever wrote notes from PaymentResult::$failureReason, which is never set on a successful result — a manual driver's staff-entered note (e.g. BankTransferPaymentDriver's) was being recorded but had nowhere to render.

• Modules\Core\Payment\Listeners\LogPaymentMethodActivity — PaymentMethod now has an admin activity trail, unlike Order/Transaction/Staff it previously had none. Routes PaymentMethodCreated/Updated/Deleted through the existing Logging\ActivityLogService (the same one Localization\Listeners\LogTranslationActivity already uses) rather than adding PaymentMethod to Lunar\Base\Traits\LogsActivity's generic model-observer logging — PaymentMethodUpdated::$old/PaymentMethodDeleted::$method's snapshot already carry more deliberate before/after context than Eloquent's own dirty-attribute diffing would reconstruct. PaymentMethodsReordered is deliberately NOT logged — a multi-row position change doesn't fit ActivityLogService's one-Model-subject shape, and isn't worth a new method for a low-stakes, purely-cosmetic setting.

• New payment_methods.refunded_status column + form field (same Select pattern as captured_status/authorized_status) — ApplyResolvedPaymentStatus now also reacts to PaymentRefunded, so Order.status actually changes on a refund; before this, only the derived Order::paymentStatus() reflected a refund (reading transactions live), while the stored status column — what admin filtering, customer emails, etc. actually key off — never moved. Resolves the ORIGINAL payment method for this lookup, not the refund event's own $type: a refund routed through a different driver via refundVia() (e.g. cash-on-delivery refunded through Bank Transfer) carries the REFUND driver's registry key as $event->type, which usually isn't even a real PaymentMethod.type — the listener now finds the order's earliest successful capture/intent transaction instead and reads refunded_status off that transaction's own PaymentMethod row, since that's the payment the refund is actually reversing. Deliberately no void_status yet — a void never moved money, so it doesn't carry the same "the customer needs to see this changed" weight a refund does.

Fixed

• Existing PaymentMethod rows seeded before this release (cash-on-delivery, cash-in-hand) had driver/capture_mode/captured_status all NULL after the migration ran — a data backfill was required (not automated by the migration itself) to restore them to a resolvable state; flagged here since a consuming app upgrading past this release needs the same backfill for its own pre-existing rows before getPaymentMethods() will offer them again.
• Lunar\Admin\Filament\Resources\OrderResource\Pages\ManageOrder::getRefundAction()/ getCaptureAction() and OrderItemsTable::getBulkRefundAction() report a failed refund/capture by calling $action->failureNotification(...), $action->failure(), then $action->halt() — but Filament\Actions\Concerns\InteractsWithActions::callMountedAction() only ever sends that notification from a code path that runs after the action's closure returns normally; halt() throws Filament\Support\Exceptions\Halt, caught by an earlier catch block that rolls back and returns, so the notification was built but never sent — clicking "Refund" on a payment method that genuinely can't be refunded looked like nothing happened at all, no error, no toast. Real, pre-existing Filament/Lunar bug, invisible until this release's TransactionDriverAdapter made an honest failure (rather than a hard crash or a silently-faked success) actually reachable. Fixed via new Modules\Core\Order\Filament\Extensions\OrderRefundActionsExtension/ OrderItemsTableExtension, which wrap the affected actions' closures to send the queued failure notification themselves before re-throwing Halt.
• TransactionDriverAdapter::refund()/capture() never included order_id in the $context passed to the driver, so Order\Listeners\RecordPaymentTransaction/ApplyResolvedPaymentStatus (both requiring $context['order_id']) silently no-op'd for every admin-initiated refund/capture through any driver — no audit Transaction row was ever created, regardless of whether the refund/capture itself succeeded. Fixed by passing $transaction->order_id through.

[0.14.0] - 2026-09-03

Changed

• Breaking: Modules\Core\Catalog\Services\ProductSearchService::search() now returns Modules\Core\Catalog\DTOs\ProductListingResult — the exact same shape ProductService::list() already returns — instead of a bare Illuminate\Database\Eloquent\Collection<Product> of hydrated models with no pagination at all. New signature: search(string $query, ?ProductFilters $filters = null, ?ProductSort $sort = null, int $perPage = 24, int $page = 1): ProductListingResult. ->products is a real LengthAwarePaginator of plain, localized indexed-document arrays (not Eloquent models, not Scout's raw response) — a search results page and a category listing page are now interchangeable from a controller's perspective: same DTO, same ProductCard::fromIndexed() mapping, same pagination/sort/tag/price-slider handling. ->priceBounds/->availableTags are scoped to the search query itself (delegated to ProductService::priceSliderBounds()/availableTags(), both of which already accepted a $query param for this).
• Modules\Core\Catalog\Services\ProductService::availableTags() is now public (was private) and takes an optional $query parameter, so ProductSearchService::search() can reuse it directly instead of reimplementing the same facet call.

Added

• Modules\Core\Catalog\Support\ProductDocumentLocalizer — the per-locale field resolution and raw-Meilisearch-response unwrapping (withLocalizedFields(), hitsFrom()) extracted out of ProductService into its own class, since ProductSearchService needed the exact same logic against the exact same kind of document. Both services now depend on this one class instead of ProductService owning logic a second service also needed.

[0.13.0] - 2026-09-03

Changed

• Breaking: Payment is now a genuinely standalone module — no direct calls into Checkout/Order, no reaching into their Eloquent models, communication only via events. The entire old confirm()-based flow is gone: Modules\Core\Payment\Contracts\PaymentDriver (and the already-stale Modules\Core\Checkout\Contracts\PaymentDriver duplicate), Checkout\Events\PaymentConfirmed, Payment\Contracts\InitiatesPayment, Payment\DataTransferObjects\PaymentInitiation, Payment\Enums\PaymentInitiationMode, Payment\Events\PaymentSucceeded/PaymentFailed, Payment\Events\OrderPaymentStatusResolved, and Payment\Exceptions\PaymentNotConfirmedException are all deleted. This flow was non-functional on master before this release — CheckoutService::confirmPayment() dispatched an event nothing listened for, so no order was ever placed after payment.
• Breaking: Every payment operation is now its own explicit, opt-in contract, modeled on how real gateways (Stripe, Mastercard's own gateway, Nexi) actually split these operations — see docs/payments.md: Modules\Core\Payment\Contracts\SupportsPay (atomic authorize+capture), SupportsAuthorization (hold only), SupportsCaptures (settle a prior hold), SupportsVoids (release a prior hold without settling), SupportsRefunds (reverse settled funds), HandlesPaymentCallback (resolve an async pay()/authorize() later, from a webhook), and Configurable (isConfigured(), split out of the old single PaymentDriver interface). A driver implements only the operations its gateway actually supports.
• Breaking: Every amount flowing through these contracts is Lunar\DataTypes\Price (Lunar's own bundled minor-unit-value + Currency type) — never a bare int paired separately with a Currency. Each driver converts at its own boundary (e.g. StripeManager::toStripeAmount()/fromStripeAmount()); Payment itself only ever speaks Lunar's Price.
• Breaking: Modules\Core\Checkout\Services\CheckoutService::placeOrder() and confirmPayment() are both replaced by a single initiatePayment(string $fingerprint, array $data = []): Modules\Core\Payment\DTOs\PaymentResult. It creates the draft Order (Cart::createOrder(), idempotent against an existing draft) and hands off directly to the resolved driver's pay()/authorize(), per that type's new config('lunar.payments.types.{type}.capture_mode') key. Checkout\Events\OrderPlaced no longer dispatches from CheckoutService — it now fires from Modules\Core\Order\Listeners\ApplyResolvedPaymentStatus once a PaymentCaptured/PaymentAuthorized event actually transitions the order's placed_at, since a draft order can now exist well before payment resolves (an async gateway).
• Modules\Core\Payment\Services\PaymentDriverResolver::resolve() now returns ?object instead of the deleted PaymentDriver interface — a driver implements several independent capability interfaces at once, so a caller does its own instanceof SupportsPay/instanceof SupportsAuthorization check, the same pattern the capability interfaces themselves are designed around.
• config/payment.php's cash-on-delivery entry gains capture_mode ('pay', since OfflinePaymentDriver only implements SupportsPay) and captured_status ('payment-offline', replacing the previously dead 'authorized' => 'awaiting-payment' key, which nothing ever read).

Added

• Modules\Core\Payment\DTOs\PaymentResult — the one return shape every operation (pay, authorize, capture, void, refund, handleCallback) produces, regardless of gateway: status (Modules\Core\Payment\Enums\PaymentResultStatus: Succeeded/Failed/Pending), reference, amount (a Price), failureReason, retriable (real on Stripe/Mastercard's own soft-decline classification, always false on Nexi — it has no such signal), raw (the untouched gateway response, for audit), meta, and continuation (see below).
• Modules\Core\Payment\DTOs\PaymentContinuation / Modules\Core\Payment\Enums\PaymentContinuationType — what a caller does next with a Pending PaymentResult, gateway-agnostically (Redirect or ClientSecret), so a storefront controller never needs gateway-specific knowledge of e.g. Stripe's own PaymentIntent fields to drive a 3-D Secure/redirect continuation.
• Eight new events, one terminal pair per operation, replacing the old single PaymentSucceeded/PaymentFailed: PaymentAuthorized/PaymentAuthorizationFailed, PaymentCaptured/PaymentCaptureFailed, PaymentVoided/PaymentVoidFailed, PaymentRefunded/PaymentRefundFailed. PaymentCaptured is deliberately the same event whether money was taken via pay() (one gateway call) or authorize()→capture() (two calls) — "a payment has been captured" is the same business fact either way. Every event carries {type, result: PaymentResult, context} — context is an opaque bag the caller hands in and gets back untouched, so Payment never needs to know what a Cart or Order is.
• Modules\Core\Order\Listeners\ApplyResolvedPaymentStatus (rewired, not new — previously listened to the now-deleted OrderPaymentStatusResolved) is the only place an Order's status column is written in reaction to a payment outcome: it listens to PaymentCaptured/PaymentAuthorized directly, reads $event->context['order_id'], and resolves the new status from config('lunar.payments.types.{type}.captured_status')/authorized_status.
• Modules\Core\Payment\Drivers\StripePaymentDriver rewritten onto the new contracts — implements all six capability interfaces plus Configurable. Solves handleCallback()'s async-correlation problem (a webhook is a separate HTTP request from the pay()/authorize() call that started it) the same way lunarphp/stripe's own StripePaymentType/ProcessStripeWebhook do: real cart_id/order_id columns on Lunar\Stripe\Models\StripePaymentIntent, plus two new columns this driver needs (context, payment_type) added by a new migration — database/migrations/2026_09_03_000002_add_context_to_stripe_payment_intents.php.
• Modules\Core\Payment\Http\Controllers\StripeWebhookController + src/Payment/routes/webhooks.php (POST /payments/stripe/webhook, loaded by PaymentServiceProvider) — a boboko-owned webhook endpoint, deliberately not lunarphp/stripe's own route (which dispatches into Lunar's own Payments::driver('stripe') flow, the flow this driver replaces). Reuses Lunar\Stripe\Http\Middleware\StripeWebhookMiddleware and Stripe\Webhook::constructEvent() directly — both are genuine Stripe SDK signature verification, safe to reuse without touching the rest of that vendor package's flow. Requires config('services.stripe.webhooks.lunar') set in a consuming app; no stripe config type entry is added to config/payment.php in this release — enabling Stripe for real is a follow-up.
• docs/payments.md — full design notes: the operation/contract table cross-referenced against Mastercard/Stripe/Nexi's real APIs, why PaymentResult normalizes only what every gateway can always provide, the async-correlation pattern, and what's explicitly out of scope (a Transaction-writing listener, the stripe config entry, frontend Stripe Elements integration).

Fixed

• Modules\Core\Checkout\Services\CheckoutService::selectPaymentMethod() crashed (Call to a member function toArray() on null) the first time it ran against a cart whose meta column was still a genuine SQL NULL (any freshly-created cart) — Cart::$meta's AsArrayObject cast returns null, not an empty array-like object, for a null column. Fixed with a null-safe fallback.
• Modules\Core\Shipping\Carriers\Acs\AcsRateDriver/BoxNowRateDriver referenced Lunar\Shipping\DTOs\ShippingOptionRequest, a namespace that doesn't exist in the installed lunarphp/table-rate-shipping version (the real class is Lunar\Shipping\DataTransferObjects\ShippingOptionRequest) — crashed Illuminate\Support\Manager's interface-compatibility check the moment anything touched ShippingManager::getSupportedDrivers(), including simply adding a line to a cart (via Modules\Core\Shipping\Listeners\FlushLivePricingCache).

[0.13.1] - 2026-09-03

Added

• Modules\Core\Order\Listeners\RecordPaymentTransaction — writes the lunar_transactions row for a successful PaymentCaptured/PaymentAuthorized/PaymentVoided/PaymentRefunded event, via a new Modules\Core\Order\Services\TransactionRecorder (moved here from Payment\Services, and rewritten to take a PaymentResult directly instead of the deleted CaptureResult/RefundResult DTOs — Payment never writes to Order's models, Transaction.order_id being required is exactly why this lives in Order, same reasoning as ApplyResolvedPaymentStatus). Closes a real gap introduced in 0.13.0: Order::paymentStatus() (which derives its answer entirely from $order->transactions) always resolved to PaymentStatus::Offline — its "no transactions at all" fallback — regardless of what actually happened, since nothing had ever written a row. Verified live: a captured offline payment now produces a type: capture transaction and Order::paymentStatus() correctly resolves to captured.

[0.12.1] - 2026-09-03

Fixed

• Modules\Core\MigrateImport\Shopify\ShopifyExportImporter now attaches a variant's Variant Image CSV column to that ProductVariant's own images() media pivot (media_product_variant, primary/position). Previously the variant image was never read at all — every image from the CSV, including ones the export clearly scopes to one specific variant, went only into the product's own top-level gallery, so a variant swatch/option change had no way to show its own photo.
• Modules\Core\MigrateImport\Shopify\Resolvers\ProductOptionResolver::resolveOption() now sets label (same value as name) when creating a Lunar\Models\ProductOption, not just name. A ProductOption with a null label crashes Lunar's own ProductOptionIndexer::toSearchableArray() (foreach() on null) the moment that option gets reindexed — every option created by the importer before this fix has a null label and needs a wipe-and-reimport (see docs/shopify-reimport.md, new in this release) to pick up the fix, since firstOrCreate() never revisits an already-existing row.
• product_reviews.product_id's foreign key had no ON DELETE clause, so deleting a reviewed Product threw a constraint violation instead of the review going with it, unlike every other product-dependent table. New migration adds cascadeOnDelete().

Added

• Modules\Core\Catalog\Services\ProductIndexer::mapVariant() now embeds gtin, mpn, ean, backorder, unit_quantity, shippable, tax_ref, and dimensions (length/width/height/weight/volume, each with value+unit) on every indexed variant — previously only id/sku/stock/purchasable/options/prices/media were embedded, so a search result or filter needing any of these had no way to get at them without a separate Postgres query per variant.
• ProductIndexer::toSearchableArray() adds a top-level, filterable skus field (every variant's SKU, deduplicated) — filtering/matching by SKU no longer requires reaching into the nested variants array.
• docs/shopify-reimport.md — runbook for wiping every imported product (cascading through Lunar so Meilisearch documents go too) and re-running the importer from scratch, needed whenever a fix like the two above only takes effect on newly-created rows.

[0.12.0] - 2026-09-03

Changed

• Breaking: Modules\Core\Catalog\Services\ProductService::list() now returns Modules\Core\Catalog\DTOs\ProductListingResult (->products: the same Illuminate\Pagination\LengthAwarePaginator as before, ->priceBounds: a new Modules\Core\Catalog\DTOs\PriceSliderBounds) instead of returning the paginator directly. A caller doing $service->list(...)->items()/->through(...) must update to $service->list(...)->products->items()/->through(...). This collapses what used to be two separate calls a controller had to orchestrate itself (list() for products, priceRange() + manual floor/ceil/"is this actually filtered" math for the slider) into one.
• Breaking: Modules\Core\Catalog\Services\ProductSearchService::search()'s signature changed from search(string $query, ?string $locale = null) to search(string $query, ?ProductFilters $filters = null, ?ProductSort $sort = null) — the $locale parameter is gone (see "every configured language, always" below); $filters/$sort apply the same Modules\Core\Catalog\Support\ProductFilterBuilder/ProductSort::toMeilisearchSort() semantics ProductService::list() already used, so a text search can now be narrowed by price/brand/stock and sorted the same way a category listing can.
• ProductSearchService now targets every configured store language's fields on every search (Lunar\Models\Language::all()), not just the current request locale plus the store's default language. The old {current, default} pairing silently stopped catching anything outside those two locales whenever they were equal (a single-language store, or a shopper browsing in the default language) — always searching every configured language closes that gap in both directions. See docs/product-search.md.
• Extracted Modules\Core\Catalog\Services\ProductService's private buildFilter() into a new standalone Modules\Core\Catalog\Support\ProductFilterBuilder, so ProductSearchService can apply the exact same Meilisearch filter-clause semantics to a text query, instead of reimplementing filter-building a second time.

Added

• Modules\Core\Catalog\Services\ProductService::priceSliderBounds() — priceRange() rounded to whole currency units (floor/ceil) plus whether the given selected min/max actually narrows it, returned as a PriceSliderBounds DTO. Used internally by list() now; also callable directly for a caller (e.g. a text-search results page) that needs slider bounds without a full list() call.
• Modules\Core\Catalog\Services\ProductService::priceRange() gained an optional string $query = '' parameter, so a caller can scope the price range to a text search's own matches (pass the shopper's search text) instead of always spanning the whole catalog.
• Modules\Core\Catalog\Services\ProductService::random(int $limit) — random products still scoped to the Meilisearch index's own channel/status visibility, unlike a raw Product::inRandomOrder() (which has no notion of that filtering). Meilisearch has no ORDER BY RANDOM() equivalent, so this fetches every matching id only (attributesToRetrieve: ['id']), shuffles in PHP, then fetches the full localized documents for just the ids picked, restoring the shuffled order afterward (Meilisearch's id IN [...] filter doesn't preserve list order on its own).
• Modules\Core\Catalog\Services\ProductService::variantSummaries(array $product) — the id/price/image of every variant on a product document, for a variant picker/swatch list, without a caller reaching into $product['variants'][n]['prices'][0]/['media'][0] itself.
• Modules\Core\Catalog\Services\ProductSearchService::search() now also targets variants.options.value — a variant's own option value (e.g. "Κάπτεν Γαμέρικα" on a "Name" option) is matchable by search even when that text never appears in the product's own name or description.
• php artisan lunar:meilisearch:tune-product-search (Modules\Core\Command\TuneProductSearchCommand) — tightens minWordSizeForTypos (1 typo only at 8+ characters, 2 typos only at 12+) and disables Meilisearch's prefixSearch on the product index. Meilisearch's defaults for both were loose enough to produce bad matches on short Greek words (confirmed the specific case was prefixSearch's default indexingTime behavior on a shared word-start, not typo tolerance, via showMatchesPosition). Consuming apps should run this after lunar:meilisearch:setup whenever the product index needs (re)provisioning — requires Meilisearch v1.12+ (prefixSearch didn't exist as a configurable setting before then).

[0.11.1] - 2026-09-01

Fixed

• Modules\Core\Catalog\Services\RecommendationService::recommend() built its result with the base Illuminate\Support\Collection (collect()) instead of Illuminate\Database\Eloquent\Collection, even though every element is a Product model. ProductIndexer::toSearchableArray() calling ->load(['media', 'variants.prices']) on that result threw BadMethodCallException: Method Illuminate\Support\Collection::load does not exist — silently failing every MakeSearchable queue job for a saved product (visible only as FAIL in the queue log, with the real exception in storage/logs/laravel.log). Fixed by having RecommendationService accumulate into a real Eloquent\Collection from the start.

[0.11.0] - 2026-09-01

Added

• Modules\Core\Catalog\Services\RecommendationService — computes "related products" for a given product as a configurable, ordered chain of strategies (config('catalog.recommendation_rules')), not one hardcoded rule. Tops up from each successive rule until the limit (default 4) is reached or every rule is exhausted — e.g. 3 products from a same-category rule plus 1 from a random fallback — deduplicated across rules so the same product is never returned twice. Ships with Modules\Core\Catalog\Recommendations\SameCategoryRule (other products sharing the source product's first collection) and RandomRule (the universal fallback, placed last in the default chain). A new rule is just a class implementing Modules\Core\Catalog\Contracts\RecommendationRule. Documented in docs/product-recommendations.md.
• Modules\Core\Catalog\Services\ProductIndexer embeds the result directly into each product's own Meilisearch document as recommendations: [{id, name, price, image}, ...] (recommendations.id filterable) — a product detail page renders its "related products" section with zero extra queries, same reasoning as the existing collections field. Deliberately embeds an id for the view to build a locale-correct URL from, not a resolved href — product.show is locale-prefixed, so a URL baked in at index time would only be correct for whichever locale happened to be active during that index run.
• Modules\Core\Catalog\Events\ProductSaved/ProductDeleted, dispatched from Product::saved()/Product::deleted() in CatalogServiceProvider (the latter fires for both a soft delete and a force delete, matching Scout's own unsearchable() trigger point) — feed Modules\Core\Catalog\Listeners\ReindexProductsRecommendingProduct, which reverse-searches Meilisearch for every product currently recommending the changed/deleted one (recommendations.id = "..." — there's no Postgres relation for this, a recommendation only exists inside the index) and re-indexes them via Scout's own ->searchable(). Product creation is deliberately not hooked into this: a new product not yet appearing as a recommendation elsewhere is an accepted staleness window, the same tradeoff already documented for in_stock/price — see docs/product-recommendations.md.
• CatalogServiceProvider schedules lunar:search:index "Lunar\Models\Product" --refresh daily at 03:00 — a safety net on top of the event-driven reindexing above, covering a newly-created product not yet appearing as a recommendation and any other drift already accepted between reindexes. --refresh also re-syncs filterable/sortable index settings, not just documents.

[0.10.1] - 2026-09-01

Added

• Modules\Core\Localization\Services\StorefrontLabels::all() gains three keys found missing from 3dealer's actual storefront.* translation usage: shop.price_min, shop.price_max, shop.reset (the price-filter sidebar's min/max labels and its reset link). Picked up by InstallLunarCommand's existing per-key upsert — re-running lunar:install on an already-installed store adds only these three rows, leaving everything already seeded or admin-edited untouched.

[0.10.0] - 2026-08-31

Changed

• Breaking: Upgraded lunarphp/lunar, lunarphp/core, lunarphp/stripe, lunarphp/table-rate-shipping, and lunarphp/search to 1.5.0, and filament/filament to v4.12.6 — the first Filament v4 admin panel on this codebase. lunarphp/filament3-2fa and kalnoy/nestedset are gone, replaced by Filament v4's native two-factor auth and lunarphp/nestedset. Ran Filament's automated filament-v4 migration tool across src/, then hand-fixed three bugs it introduced or left behind: a stale $infolist variable reference in CartResource's ViewCart page (the parameter had been renamed to $schema but the body wasn't updated), ShippingMethodResourceExtension rewritten to call getDefaultChildComponents() (returns array|Schema) instead of the type-safe getChildComponents() (always array<Component>), and — unrelated to the tool, but surfaced by the same PHP version bump — InvalidCouponException's readonly $code property illegally shadowing the built-in Exception::$code, renamed to $couponCode. LunarStaff::addActivitylogExcept() updated for the renamed two_factor_secret/two_factor_recovery_codes staff columns (now app_authentication_secret/app_authentication_recovery_codes; two_factor_confirmed_at removed). Consuming apps must run composer update boboko/core --with-all-dependencies and php artisan migrate.

Added

• Modules\Core\Checkout\Contracts\PaymentDriver — the abstraction every payment provider implements: confirm(Cart $cart, string $type, string $fingerprint, array $data): Order and isConfigured(): bool. A driver only ever calls CheckoutService::placeOrder() once it has, by whatever mechanism is native to that gateway, independently confirmed payment — never Lunar's raw Cart::createOrder(). This is what lets the storefront checkout sequence stay uniform regardless of which provider is active: set addresses, select shipping, hand off to whichever driver is configured, and the driver decides when (or whether) the order gets created.
• Modules\Core\Payment\Drivers\OfflinePaymentDriver — shared by every payment type with no real gateway to confirm against (cash-in-hand, cash-on-delivery): places the order immediately via CheckoutService::placeOrder(), then sets the order status from config("lunar.payments.types.{$type}.authorized") using the type actually confirmed, not a hardcoded key, since one driver instance serves multiple types.
• Modules\Core\Payment\Drivers\StripePaymentDriver — a fork, not a decoration, of lunarphp/stripe's StripePaymentType::authorize(): that method is final and calls Cart::createOrder() directly with no seam to redirect into our fingerprint-checked placeOrder(), so this class reimplements its logic (intent retrieval, capture-on-policy, status mapping via UpdateOrderFromIntent) with that one substitution. Throws the new Modules\Core\Payment\Exceptions\PaymentNotConfirmedException on anything short of a genuinely confirmed payment intent — never falls through to placing an order on ambiguity.
• CheckoutService::getPaymentMethods(): array — every payment type currently offered to the storefront: every key in config('lunar.payments.types') that is both administratively enabled (Modules\Core\Payment\Models\PaymentMethod::enabled) and whose driver reports isConfigured() (e.g. Stripe with no API key set is never offered, regardless of the enabled toggle). selectPaymentMethod(string $type) and confirmPayment(string $type, array $data) both validate against this list, throwing the new UnknownPaymentTypeException for a type that isn't currently offered — re-checked in confirmPayment() too, since a type could be disabled between selection and confirmation.
• CheckoutService::selectPaymentMethod() snapshots Cart::fingerprint() into cart->meta['checkout_fingerprint'] after saving the chosen type and recalculating — the fingerprint has to reflect the final total including any payment-type-specific adjustment (e.g. a COD surcharge), which only exists once payment_method is set. confirmPayment() reads this stored fingerprint internally rather than taking one as a parameter: a storefront should never need to know Cart::fingerprint() exists or capture it at exactly the right moment itself.
• Modules\Core\Payment\Models\PaymentMethod — one DB row per payment type key (matching config('lunar.payments.types')), enabled boolean plus a data jsonb column (starting with fee, the flat cash-on-delivery surcharge) — mirrors Lunar's own Discount model (a single jsonb column of keyed settings, not a fixed column per setting or a separate conditions table). Seeded idempotently by InstallLunarCommand (skip-if-exists per type, safe to re-run after installing a new payment-provider package), always enabled: false — a newly-seeded type shouldn't go live for shoppers before staff have configured and reviewed it. Admin-editable via the new PaymentMethodResource (inline enabled toggle, modal fee editor) under Settings.
• ApplyCashOnDeliveryFee now reads its surcharge from PaymentMethod instead of static config, so it's admin-editable without a deploy.

Fixed

• CashOnDeliveryPaymentDriver renamed to OfflinePaymentDriver and generalized to work for any offline-style type — it previously hardcoded 'cash-on-delivery' when reading the post-placement order status from config, which would have silently read the wrong type's status the moment a second offline type (cash-in-hand) used it.

[0.9.0] - 2026-08-29

Added

• Modules\Core\Cart\Services\CartService — the boboko-owned API for all cart mutation, wrapping Lunar's CartSession/Cart primitives: addLine(), updateLine(), removeLine(), clear(), applyCoupon()/removeCoupon() (throws InvalidCouponException on an invalid code), and save-for-later (saveForLater()/moveToCart()/activeLines()/savedLines(), backed by a meta.saved_for_later flag and a new Modules\Core\Cart\Pipelines\ZeroSavedForLaterPrice cart-line pipeline step that zeroes a saved line's price so it's excluded from cart totals without being removed). Dispatches 8 real domain events (CartLineAdded/Updated/Removed/Saved/MovedToCart, CartCleared, CartCouponApplied/Removed) — none have a listener yet, built so a future concern (analytics, recovery) has something to attach to. Documented in docs/cart.md.
• Modules\Core\Checkout\Services\CheckoutService — the boboko-owned API for the checkout stage (address → shipping selection → order placement), sitting between CartService and Order: setShippingAddress()/setBillingAddress(), getShippingOptions()/selectShippingOption() (throws the new InvalidShippingOptionException on an identifier that doesn't resolve — previously a silent no-op), and placeOrder(string $fingerprint) (the fingerprint is mandatory, not optional — forces re-confirmation via Lunar's own FingerprintMismatchException if the cart changed since the shopper last saw its total). Dispatches ShippingAddressSet/BillingAddressSet/ShippingOptionSelected/OrderPlaced, each carrying richer, already-resolved payload (e.g. the resolved ShippingOption, not just its identifier) than CartService's events. No exception wrapping otherwise — Lunar's own CartException/FingerprintMismatchException are already the right shape for a storefront to render as form errors. Documented in docs/checkout.md.
• Modules\Core\Cart\Filament\Resources\CartResource's list view now classifies every cart into one of four states — Ongoing, Abandoned Cart, Abandoned Checkout, Completed — instead of the previous two-tab Abandoned/Completed split, distinguishing a cart that never reached checkout from one that has a started-but-unplaced order (mirrors the real distinction in Lunar's own Cart::scopeActive()). Abandonment threshold is a fixed, configurable cutoff (config('core.cart.abandoned_after'), default 1 hour). Added a customer hyperlink (list column + a "View Customer" header action on the view page, both pointing straight at customers/{id} via the plain customer_id column, no extra query via the customer relation).
• Modules\Core\Cart\Commands\DetectAbandonedCarts (boboko:cart:detect-abandoned, scheduled hourly) dispatches Modules\Core\Recovery\Events\CartAbandoned/CheckoutAbandoned for carts/checkouts past the abandonment cutoff — detection only, no persistence; a real tracking table is left for when Recovery is built as its own concern. Fixed a self-defeating bug from an earlier draft: marking a cart as notified by writing to it bumped updated_at, which immediately un-staled it for the next run's own cutoff check.
• Merged the Shipping-Carriers branch: live carrier rate quoting and fulfillment for ACS Courier and Box Now (Modules\Core\Shipping\Carriers\{Acs,BoxNow}) on top of lunarphp/table-rate-shipping — AcsRateDriver/BoxNowRateDriver (live + static price-break resolution), AcsFulfillmentService/BoxNowFulfillmentService (shipment creation, label printing, cancellation via the new Modules\Core\Shipping\Contracts\CarrierFulfillmentInterface, resolved per-carrier via contextual container binding), Modules\Core\Shipping\Models\Shipment/ShipmentInfo, PollShipmentTrackingJob (scheduled every 30 minutes), ManagePickupManifests (Filament page for carrier manifest batching), and an OrderViewExtension adding a "Create Shipment" header action to Lunar's order view. Carrier credentials are published config (config/shippingCarriers/{acs,boxnow}.php), never committed.
• Modules\Core\Shipping\Concerns\CachesLivePricing caches a live-priced carrier quote per (rate, cart) for 30 minutes — a real, billed API call that's otherwise re-run on every getShippingOptions()/selectShippingOption() call within the same checkout attempt. Modules\Core\Shipping\Listeners\FlushLivePricingCache invalidates it on the only two things that can change a quote: a cart line changing or the shipping address changing (deliberately not on order placement — the price the shopper was quoted must still be readable afterwards). Scoped generically to any SupportsLivePricing driver, not hardcoded to ACS.
• AcsRateDriver::resolveLivePrice() now falls back to the rate's own configured static price if the live ACS API call fails (previously: the shipping option silently disappeared from the list on any API error, including a brief outage). ManageShippingRates (our Filament subclass of the vendor rates page) now allows a static price to be configured and saved on a "live" rate specifically for this fallback — previously those fields were hidden and discarded on save for any live-priced rate.

Fixed

• Fixed a crash (Attempt to read property "price" on null) opening/editing a live-priced shipping rate with no fallback price configured yet — the vendor ManageShippingRates page's afterStateHydrated callback for the price field had no null-guard for a rate with zero basePrices, which is now the routine case for an unconfigured live rate.
• Fixed the Filament admin panel's home URL (/boboko/home) incorrectly resolving to the Shipping module's ManagePickupManifests page instead of the Dashboard — Filament falls back to the first item of the first registered navigation group when no explicit homeUrl() is set, and ManagePickupManifests had no navigationGroup/navigationSort of its own. Fixed via explicit navigationGroup = 'Sales' / navigationSort = 100, placing it after Sales in the nav instead of first overall.

[0.8.0] - 2026-08-27

Added

• Modules\Core\Cart\Filament\Resources\CartResource gives staff read-only visibility into carts in the Filament admin panel — Lunar ships no cart admin view at all. Scoped to carts with a known user_id/customer_id (an anonymous guest cart carries no identity staff could act on); list table shows customer/user, line/item counts (via Filament's built-in ->counts()/->sum(), no per-row queries), currency, and last activity. List page has only two tabs, Abandoned (default active) and Completed — no "All" tab, so the list never runs an unfiltered fetch over the whole table. They key off whether the cart has a placed order (orders.placed_at IS NOT NULL), not Cart::completed_at — that column is declared/cast on the model but never actually written anywhere in Lunar core, so it's not a real signal; "Abandoned" mirrors Lunar's own Cart::scopeActive(). getNavigationBadge() shows the abandoned-cart count in the sidebar via a single COUNT(*) query, no rows loaded. View page runs $cart->calculate() once so line/cart totals (plain public properties Lunar never persists) are populated, without paying that cost per row in the list. Documented in docs/cart.md.

[0.7.0] - 2026-08-27

Added

• Modules\Core\Catalog\Services\CollectionService provides category browsing/nav AND single-collection lookup from Meilisearch, mirroring ProductService exactly (list(), getById(), getBySlug(), same locale-resolution logic). Modules\Core\Catalog\Services\CollectionIndexer extends Lunar's own Lunar\Search\CollectionIndexer (which only carried id/name/created_at) to add parent_id, _lft/_rgt (nested-set tree position, filterable/sortable), collection_group_id, slugs, and thumbnail. Modules\Core\Catalog\DTOs\CollectionFilters supports parentId (children of a specific collection), groupId, and rootOnly (top-level collections, parent_id IS NULL — mutually exclusive with parentId). Modules\Core\Catalog\Enums\CollectionSort adds Position (_lft:asc, the recommended default for nav/tree UIs — matches admin arrangement order), Name, Newest. Must be registered in a consuming app's config/lunar/search.php (Lunar\Models\Collection::class => CollectionIndexer::class), same as ProductIndexer. Documented in docs/collections.md.
• Modules\Core\Localization\Services\StorefrontLabels::all() extracts the default storefront UI label list out of InstallLunarCommand into its own class, and adds every previously-missing key (nav.contact, product.description/no_image/read_more/reviews, customer_reviews, pagination.*, review.*, shop.*) that had already been seeded manually in some stores but was absent from the command's own list — bringing the code-side default back in sync with what a real store actually has. InstallLunarCommand::seedStorefrontLabels() now does a per-key upsert instead of an all-or-nothing "only seed if the group is empty" guard: a key already present in the database (including one an admin has since edited via the Filament Language Lines resource) is left untouched, and only missing keys are created via TranslationService::create(). This makes it safe to add new keys to StorefrontLabels::all() later and re-run lunar:install on an already-installed store without either silently skipping the new keys (the old guard's behavior) or reverting an admin's edits back to the hardcoded default. Documented in docs/localization.md ("Seeding").
• Modules\Core\Catalog\Services\CollectionIndexer adds ancestors — [{id, name}, ...] ordered root-first (via the newly eager-loaded ancestors relation) — so a breadcrumb can render directly from CollectionService::getById()/getBySlug() with zero extra queries, and product_count — how many products are in a collection or any of its descendants, queried from the product Meilisearch index at collection-index time via the same collection_ids field ProductFilters(collectionId:) filters against. Documented in docs/collections.md, including the reindex-ordering gotcha (product_count needs the product index reindexed first).
• Modules\Core\Catalog\Services\ProductIndexer adds a filterable in_stock boolean — true if any variant currently passes ProductVariant::canBeFulfilledAtQuantity(1) (Lunar's own purchasability rule, not a naive stock > 0 check). Modules\Core\Catalog\DTOs\ProductFilters gets a matching inStockOnly flag. Reflects stock as of the last reindex only — nothing currently reindexes a product when an order decrements its stock, since that's a cart/checkout concern this doesn't attempt to solve; see docs/product-listing.md ("Stock goes stale between orders").
• Modules\Core\Catalog\Services\ProductService::facets(string $field, ?ProductFilters $filters = null): array returns Meilisearch facet value counts (e.g. ['Brand A' => 48, 'Brand B' => 135]) for a discrete-value filterable field, scoped to the given filters. Uses Scout's plain ->options(['facets' => [...]]), merged directly into the raw Meilisearch query the same way filter/sort already are — no adoption of Lunar's separate SearchManager/Search facade needed. ProductService::priceRange(?ProductFilters $filters = null): array{min, max} covers the numeric-field case facets() explicitly doesn't (price would otherwise return one "facet" per exact price) — backed by Meilisearch's facetStats, not facetDistribution. priceRange() always excludes minPrice/maxPrice from the filter it builds (via a new $exclude parameter on the private buildFilter()), so a price slider's own bounds don't shrink to whatever range is already selected on it; other filters (collectionId, brand, inStockOnly) still apply normally. Documented in docs/product-listing.md.

Changed

• Breaking: Renamed the Product module to Catalog, flattened. Every class under Modules\Core\Product\* (Contracts, DTOs, Enums, Services, Observers, Filament\Extensions, OptionTypes) now lives under Modules\Core\Catalog\* at the same sub-path — e.g. Modules\Core\Product\Services\ProductService is now Modules\Core\Catalog\Services\ProductService, Modules\Core\Product\DTOs\ProductFilters is now Modules\Core\Catalog\DTOs\ProductFilters. Class names themselves are unchanged (still ProductService, ProductIndexer, ProductFilters, etc.) — only the namespace/folder moved, to make room for Collection as a sibling concern under the same Catalog umbrella rather than a disconnected top-level module. Consuming apps must update every use Modules\Core\Product\... import and any FQCN reference (config/lunar/search.php's indexer registration, service provider bindings).
• Breaking: Modules\Core\Providers\ProductServiceProvider renamed to Modules\Core\Providers\CatalogServiceProvider (composer.json's provider list updated accordingly) — it now only wires Catalog-namespace classes (ProductOptionTypeManager, ProductOptionReindexObserver), so the name follows the same by-concern convention as LocalizationServiceProvider/ReviewServiceProvider.
• Breaking: Modules\Core\Review's flat Extensions//Pages/ folders now nest under Filament/, matching the strict per-concern subfolder convention already applied to Product(now Catalog)/Localization. Modules\Core\Review\Extensions\ProductResourceExtension is now Modules\Core\Review\Filament\Extensions\ProductResourceExtension; Modules\Core\Review\Pages\ManageProductReviews is now Modules\Core\Review\Filament\Pages\ManageProductReviews. Modules\Core\Review\Models\ProductReview is unchanged.
• Breaking: ProductFilters(collectionId: ...) now matches a product in that collection or any of its descendant collections, not just direct assignment. Products in a Shopify-imported tree are typically attached only to leaf collections, so filtering strictly on direct assignment meant a parent/root category page (CollectionFilters(rootOnly: true)'s results, or any non-leaf collection) always returned zero products even though real products existed several levels down. Modules\Core\Catalog\Services\ProductIndexer adds a new filterable collection_ids field — every directly-assigned collection's id unioned with all of its ancestors' ids (via the newly eager-loaded collections.ancestors) — and ProductService::buildFilter() now filters collectionId against collection_ids instead of the old collections.id. The display-only collections field ({id, name}, direct assignments) is unchanged and no longer filterable.

[0.6.1] - 2026-08-27

Added

• Modules\Core\Product\Contracts\ProductOptionTypeInterface describes how a category of Lunar\Models\ProductOption (e.g. "Color", "Size") behaves — what structured data its values carry in their free-form meta jsonb column, and how an admin edits it via Filament — without introducing a new model. Registered via Modules\Core\Product\Services\ProductOptionTypeManager::get()->register([...]) (a singleton registry, same shape as Modules\Core\Notification\NotificationRegistry) from a service provider's boot(). An admin then picks one per ProductOption from an "Option Type" dropdown on the option's own edit form (added by Modules\Core\Product\Filament\Extensions\ProductOptionResourceExtension), stored in ProductOption::meta['option_type'] — deliberately not tied to the option's handle, since a shop's own handle naming shouldn't have to match a type's key. Modules\Core\Product\Filament\Extensions\ValuesRelationManagerExtension hooks Lunar's own ValuesRelationManager (both extensions via LunarPanel::extensions(), registered in CorePlugin) to append the resolved type's meta form fields to the stock "Values" tab — no fork of Lunar's classes needed. Ships a reference implementation, Modules\Core\Product\OptionTypes\ColorOptionType, registered automatically by the new Modules\Core\Providers\ProductServiceProvider. Documented in docs/product-options.md.
• Modules\Core\Product\Services\ProductIndexer::mapVariant() now includes each option's handle (alongside its translated name) in a variant's indexed options[] — previously only the translated option/value names and meta were indexed, with no stable, locale-independent identifier for which option a value belongs to.
• Modules\Core\Product\Observers\ProductOptionReindexObserver, wired in the new Modules\Core\Providers\ProductServiceProvider, keeps Meilisearch in sync when a ProductOption or ProductOptionValue is saved or deleted — e.g. picking an Option Type or editing a color's hex. ProductIndexer::mapVariant() embeds each option value's meta directly into a product's indexed document, but saving the option/value never fires the product's own save events, so without this a changed hex would only reach the index on that product's next unrelated reindex. The observer resolves every Lunar\Models\Product whose variants use the changed option (or option value) via the product_option_value_product_variant pivot, and calls ->searchable() on each.

Changed

• Breaking: Modules\Core\Product\Services\ProductIndexer's indexed collections field is now an array of {id, name} objects instead of two parallel arrays (collections as bare ID strings, collection_names as translated names joined only by array index). collection_names is removed. Filtering by collection now targets the nested field collections.id (Meilisearch supports filtering on nested object fields), not bare collections — Modules\Core\Product\Services\ProductService::buildFilter() updated accordingly; ProductFilters(collectionId: ...)'s public API is unchanged. Run php artisan lunar:meilisearch:setup then lunar:search:index --refresh after upgrading (see docs/product-listing.md "Gotchas").
• Breaking: ProductIndexer's indexed review_count/average_rating top-level keys are folded into the existing reviews key: reviews is now {items, count, average_rating} instead of a bare array with review_count/average_rating as separate sibling keys. reviews (the array of review items) moved to reviews.items.

[0.6.0] - 2026-08-27

Added

• Modules\Core\Localization\Models\LanguageLine extends spatie/laravel-translation-loader's LanguageLine to fall back to the store's actual default language (LanguageCache::defaultLocale(), backed by Lunar's languages.default flag) instead of the package's stock behavior of falling back to the static config('app.fallback_locale') — the two were previously disconnected, so changing the default language via the Filament Languages resource had no effect on which locale an untranslated storefront label silently fell back to. Swapped in automatically via config('translation-loader.model') in LocalizationServiceProvider::register(); no consuming app changes needed. Documented in docs/localization.md ("Fallback locale follows the store's default language").

Changed

• Breaking: Modules\Core\Catalog\ProductService::list() now returns a real Illuminate\Pagination\LengthAwarePaginator (built from the localized Meilisearch hits) instead of a plain array{data, meta} — gives callers normal Laravel pagination behaviour ($products->links(), standard JSON serialization) without ever touching Scout's raw paginateRaw() response directly. getById()/getBySlug() are unaffected (still return ?array).
• ProductService::withLocalizedFields() (used by list(), getById(), getBySlug()) no longer hardcodes name/description as the only translated fields — it now reads every TranslatedText attribute on Product from Lunar\Base\AttributeManifest (the same source Lunar's own indexer reads), so a store's own custom translated attributes (e.g. seo_title, seo_description) are resolved and locale-stripped automatically with no code change here. Raw {handle}_{locale} keys (e.g. name_el, seo_title_en) are now stripped from every returned product, not just name_*/description_*.
• Extracted Modules\Core\Localization\Services\LanguageCache (cached read layer over Lunar's languages table: all(), defaultLocale(), availableLocales(), forget()) out of LocaleMiddleware, which previously owned this as private/static methods despite not being middleware-specific behavior. LocaleMiddleware now takes LanguageCache via constructor injection. LocaleMiddleware::defaultLocale()/forgetLanguagesCache() (static) are removed — use app(LanguageCache::class) or inject LanguageCache directly.

Fixed

• Modules\Core\MigrateImport\JudgeMe\Resolvers\ProductResolver::resolve() picked whichever lunar_urls row matched a slug first, which can be a soft-deleted product left behind by an earlier import batch rather than the current live one — a store can easily end up with more than one Product row sharing the same slug across re-imports, since a soft-deleted product's URL row isn't cleaned up. This silently broke every downstream lookup for that handle (e.g. Modules\Core\MigrateImport\JudgeMe\JudgeMeExportImporter logging "no product found for handle, skipping review" and dropping the row, even though a live product with that exact handle existed). Rewrote as a join against lunar_products — via Product::query(), so Eloquent's SoftDeletes global scope excludes trashed rows — so only a URL pointing at a live product resolves.
• Modules\Core\Review\Models\ProductReview had no registerMediaConversions() at all, unlike Product/ProductVariant which get one automatically from Lunar's own Lunar\Base\StandardMediaDefinitions. Modules\Core\Search\ProductIndexer::mapMedia() is shared across product, variant, and review media and always requests the small conversion — the first time a review had an attached image, indexing it threw Spatie\MediaLibrary\MediaCollections\Exceptions\InvalidConversion, silently failing the product's MakeSearchable queue job (and everything queued after it, since Scout batches). Added a matching small conversion (300×300, same fit/border/background as Lunar's standard one) directly on ProductReview.

Breaking

• Merged Modules\Core\Catalog and Modules\Core\Search into a single Modules\Core\Product concern, since both existed purely to serve Product (browsing/filtering vs. indexing/full-text search — two services, one concern), following a stricter subfolder convention (Contracts/, Enums/, Services/, DTOs/, Models/, etc. per concern) going forward:

  • Modules\Core\Catalog\ProductService → Modules\Core\Product\Services\ProductService
  • Modules\Core\Catalog\ProductFilters → Modules\Core\Product\DTOs\ProductFilters
  • Modules\Core\Catalog\ProductSort → Modules\Core\Product\Enums\ProductSort
  • Modules\Core\Search\ProductIndexer → Modules\Core\Product\Services\ProductIndexer
  • Modules\Core\Search\ProductSearchService → Modules\Core\Product\Services\ProductSearchService

  Consuming apps must update any direct references — notably config/lunar/search.php's 'indexers' map, which points at ProductIndexer by FQCN. Modules\Core\Catalog\ProductOptionTypeInterface (in-progress, not yet wired to anything) was deliberately left in place rather than moved.

• Reorganized Modules\Core\Localization under the same stricter per-concern subfolder convention — Events/, Filament/, Listeners/ were already correctly categorized; four loose root files moved into typed buckets by structural role:

  • Modules\Core\Localization\LocaleMiddleware → Modules\Core\Localization\Middleware\LocaleMiddleware
  • Modules\Core\Localization\LanguageCacheObserver → Modules\Core\Localization\Observers\LanguageCacheObserver
  • Modules\Core\Localization\TranslationReader → Modules\Core\Localization\Services\TranslationReader
  • Modules\Core\Localization\TranslationService → Modules\Core\Localization\Services\TranslationService

  Modules\Core\Localization\Services\LanguageCache (added earlier in this same unreleased version) already lived at its correct final path — unaffected. The 'locale' route-middleware alias (registered in LocalizationServiceProvider) is unaffected for consuming apps using it by string alias rather than FQCN.

[0.5.4] - 2026-08-26

Added

• Modules\Core\Catalog\ProductService::list() accepts a sort parameter (new ProductSort enum: PriceAsc, PriceDesc, Newest), translated into a Meilisearch sort clause — list() previously had no way to order results, since it always searches with an empty query string and so has no relevance score to fall back on. Modules\Core\Search\ProductIndexer::getSortableFields() now also marks price sortable (Lunar's base indexer only marks created_at/updated_at/skus/status). Requires re-syncing index settings (php artisan lunar:meilisearch:setup) on existing stores. Documented in docs/product-listing.md ("Sorting").

[0.5.3] - 2026-08-26

Fixed

• Modules\Core\Search\ProductIndexer::toSearchableArray() threw column reference "id" is ambiguous on Postgres when computing channel_ids — $model->channels()->wherePivot('enabled', true)->pluck('id') joins lunar_channels and lunar_channelables, both of which have an id column, and the unqualified pluck('id') left Postgres unable to resolve which table's column to select (SQLite/MySQL tolerated the ambiguity). Qualified as pluck('lunar_channels.id').

[0.5.2] - 2026-08-26

Fixed

• Modules\Core\Localization\LocaleMiddleware's shared view data only ever surfaced a single alternate locale (altLocale/altLocaleUrl, found via firstWhere('code', '!=', $current)) — correct by coincidence for a 2-language store, but silently dropped every locale past the first "other" one found for a 3+ language store, with no error. Replaced with altLocales, a collection of every other configured language (code, name, url for the current route each), so a language switcher or hreflang tags scale to any number of locales. Documented in docs/localization.md ("Shared view data — language switcher and hreflang tags").

[0.5.1] - 2026-08-25

Added

• Modules\Core\Search\ProductIndexer now indexes channel_ids (filterable) — Lunar's base indexer only marks status as filterable, not channel assignment, so storefront search couldn't otherwise scope results to products actually assigned and enabled on the current sales channel. Computed from $product->channels()->wherePivot('enabled', true). Ported from an older Products branch whose remote had been deleted; the branch's other, now-superseded ProductIndexer changes were dropped in favor of the richer indexer already on master (collections, price, variants, reviews — see 0.5.0).

[0.5.0] - 2026-08-24

Added

• Modules\Core\Catalog\ProductService: storefront product listing/filtering (list()) and single-product lookup (getById(), getBySlug()), reading directly from the Meilisearch index rather than the database — one data source, no ->get() model hydration. Returns plain arrays (not Eloquent models), meant to be called directly from a consuming app's controllers.
  • ProductFilters DTO: optional collectionId, brand, minPrice, maxPrice, translated into a Meilisearch filter expression.
  • Listing results are locale-aware: withLocalizedFields() resolves name/description from the indexer's per-locale fields, falling back to the store's default language (via LocaleMiddleware::defaultLocale()) when the current locale has no translation yet, instead of rendering blank.
  • Modules\Core\Search\ProductIndexer expanded well beyond its original collection/price additions to carry everything a detail page needs: id/slugs (filterable — getById()/getBySlug() resolve purely from the index, no database read), collection_names, tags, the full media gallery, per-variant data (sku, stock, purchasable, translated option/value names + meta for swatches, per-currency prices, variant media), and reviews (reviews, review_count, average_rating — public-safe fields only, reviewer_email deliberately excluded).
  • Modules\Core\Providers\ReviewServiceProvider (newly registered): re-indexes a product whenever one of its reviews is created/updated/deleted, since a review write doesn't touch the Product row and so never fires the product's own model events.
• Modules\Core\Search\ProductSearchService: locale-aware full-text product search on top of the same Meilisearch index, for use by a storefront's search bar — separate from ProductService, which is for browsing/filtering without a query term.
• docs/product-listing.md and docs/product-search.md — usage, full field reference, and design notes for the two services above.
• docs/lunar.md "Gotchas": three new entries hit while building this — ProductOption/ProductOptionValue::name isn't attribute_data (so translateAttribute() silently returns null for it), a running queue:work process not picking up an edited Scout indexer class, and Scout's paginateRaw()->items() on the Meilisearch driver returning the whole raw response rather than a hit list.

Fixed

• The admin login form (Modules\Core\Auth\Filament\Pages\Login) had no way back from the OTP-entry step to the email step short of reloading the page. A back() method resets to the email step; a "← Back" link/button is shown on the OTP step only.

[0.4.0] - 2026-08-06

Added

• Locale-prefixed routing (Modules\Core\Localization\LocaleMiddleware): a locale route-middleware alias, opt-in per shop (not pushed onto the web group globally, since admin/Livewire/webhook routes must not be locale-redirected). Reads the first URL segment against Lunar's own languages table, sets App::setLocale(), and redirects unprefixed/unknown-locale requests to a resolved locale (Accept-Language match → default language → first language). Every locale is prefixed, including the default (/el/..., /en/...), never a bare root — avoids the hreflang/duplicate-content ambiguity of a bare-root default locale.
  • Language list cached with Cache::rememberForever(), invalidated via Modules\Core\Localization\LanguageCacheObserver dispatching LanguageCreated/LanguageUpdated/LanguageDeleted events (see below) rather than doing the work itself.
  • Language rename safety: renaming a Language::code (e.g. el → gr) no longer strands existing translations. MigrateTranslationsForRenamedLanguage (listening on LanguageUpdated) migrates every affected LanguageLine.text key from the old code to the new one and flushes both codes' translation caches — closing a real data-loss gap where a rename would otherwise make existing LanguageLine translations permanently unreachable.
• Storefront UI label translations: pulled in spatie/laravel-translation-loader (self-registers via Composer package auto-discovery; its loader extends Laravel's file-based FileLoader and merges DB translations on top — existing Filament/Lunar vendor lang/ strings are unaffected). Labels are looked up via Laravel's native __('storefront.nav.cart'), kept in its own storefront group so nothing collides with Lunar/Filament's own translation groups.
  • Modules\Core\Command\InstallLunarCommand (overriding lunar:install) seeds a starter set of ~15 common e-shop labels (nav.*, cart.*, product.*, auth.*, search.*, English + Greek), idempotently guarded so it's safe on every boot.
  • Modules\Core\Localization\TranslationReader::group('storefront') returns the whole reduced/cached label array for a locale (backed by LanguageLine's own forever-cache) — for sharing to a view as $labels or @json()-ing to JS, on top of __() for single-key Blade lookups.
  • Admin UI: Modules\Core\Localization\Filament\Resources\LanguageLineResource (registered in CorePlugin) lists/searches/filters language_lines and edits each row's group, key, and one text input per locale currently in lunar_languages — locale columns/inputs are generated dynamically from the language list, so a new language needs no resource changes.
  • Event-driven writes: Modules\Core\Localization\TranslationService (create/update/delete) is the single write path for LanguageLine — the Filament resource's Create/Edit/Delete pages route through it rather than Filament's default direct-model writes. Dispatches TranslationCreated/TranslationUpdated (carries the full pre-update {group, key, text} snapshot, so a bare rename is tracked the same as a text edit)/TranslationDeleted, each handled by two listeners:
    • FlushTranslationCache — closes a real gap in LanguageLine's own self-invalidation, which only flushes locales/groups present after a save. Flushes the union of old and new group+locale combinations, so a locale removed from text, or a group/key rename, can't leave a stale cached array behind.
    • LogTranslationActivity — audits every write via the existing Modules\Core\Logging\ActivityLogService (lunar activity log channel), same created/updated/deleted shape as every other domain write in this project. Properties are flattened with Arr::dot() before logging (text.en, text.el instead of a nested text object) since Filament's Activity resource renders properties with a flat KeyValue field that can't display nested arrays.
• Modules\Core\Providers\LocalizationServiceProvider — split out of the growing CoreServiceProvider (per this project's own "split when a provider does too much" convention) to own all locale/translation middleware, observer, and event-listener registration.

[0.3.0] - 2026-07-12

Added

• Meilisearch product search: pulled in lunarphp/search (Lunar's driver-agnostic search abstraction — database/meilisearch/typesense engines, selectable via Scout's own SCOUT_DRIVER config) and lunarphp/meilisearch, wiring Meilisearch in as the search engine for products.
  • Search\ProductIndexer overrides Lunar's own indexer to strip HTML tags from string fields (e.g. name_en, description_en) before they reach the search index — Lunar's default indexer sends raw attribute HTML straight through, which pollutes relevance ranking and highlighting with markup.
  • Meilisearch itself is treated as app-level infrastructure, not a boboko-core concern: the actual Meilisearch container, host port, and master key live in each consuming app's own docker-compose.yml/.env (e.g. 3dealer), the same way Postgres and Valkey do — boboko-core only declares the PHP package dependency and the indexing code.

[0.2.0] - 2026-07-10

Added

• Product reviews (Modules\Core\Review): a new ProductReview model + product_reviews table (plain, unprefixed — same convention as import_mappings), linked to Lunar's Product via a Product::reviews() macro (registered in CorePlugin, since Lunar\Models\Product is a vendor model and can't be edited directly).
  • JudgeMe CSV review importer (MigrateImport\JudgeMe\JudgeMeExportImporter), wired into the existing boboko:migrate:import --source=judgeme --type=export command: reads a Judge.me review export, resolves each row's product_handle to a Lunar product via Lunar\Models\Url, and creates/updates ProductReview rows idempotently via import_mappings (source=judgeme, source_type=review, keyed on Judge.me's metaobject_handle). Rows with no matching product are skipped with a logged warning rather than failing the whole import.
  • Review images (picture_urls in the CSV) are downloaded and stored as real media via Spatie MediaLibrary (ProductReview::IMAGES_COLLECTION), not just linked by URL — consistent with how product images are handled.
  • Admin UI: a new "Reviews" sub-navigation page on the product edit screen (Review\Pages\ManageProductReviews, wired via Review\Extensions\ProductResourceExtension), listing rating/title/reviewer with View, Reply, and Delete actions. The Reply action lets staff write/edit a reply directly from the table, setting replied_at. The View modal shows full review detail (body, reviewer email, location, source, dates, reply, downloaded images).

Fixed

• Shopify\ShopifyExportImporter never wrote a Lunar Url (slug) row for imported products, despite docs/shopify-import.md specifying it should — meaning no code outside the importer itself could resolve "which Lunar product has handle X" (only the importer's own private import_mappings bookkeeping could). It now creates/updates a default Url row (slug = Shopify handle) per product on every import, which the new JudgeMe review importer depends on for product resolution.

[0.1.0] - 2026-07-09

Added

• Shipping: registered Lunar's lunarphp/table-rate-shipping plugin (ShippingPlugin) directly on CorePlugin, so table-rate shipping is available to every consumer app without per-app wiring.
• Product migration/import framework (Modules\Core\MigrateImport): a source-agnostic pipeline for importing a vendor's product catalog into Lunar.
  • boboko:migrate:import Artisan command — interactively prompts for source, type (export/API), and credentials or file path, then dispatches the import as a queued job (RunMigrateImportJob) on the default queue. The file-path prompt resolves relative to storage/app/private/imports/, so answering e.g. shopify picks up the first CSV found in imports/shopify/ automatically.
  • ImportSpec, Importer interface, and ImporterFactory (source+type → importer class) as the extension points for future sources (WooCommerce, etc.) and mechanisms (API vs. file export).
  • import_mappings table + ImportMapping model: a polymorphic (source, source_type, external_id) → model mapping used by every resolver to make imports idempotent and safely re-runnable.
  • DefaultLocale helper wrapping Lunar's Language::getDefault()->code, used anywhere a translatable field needs a locale key, instead of assuming app()->getLocale() matches Lunar's configured default.
  • Shopify CSV export importer (Shopify\ShopifyExportImporter), the first working source/type combination, verified end-to-end against a real 183-product/693-variant/332-image Shopify export (row counts in the CSV match 1:1 with imported Products/Variants/Media):
    • ShopifyCsvReader + ProductGroup group Shopify's flat, repeated-handle CSV rows into one row-group per product (product row, variant rows, image rows).
    • Ten resolvers under Shopify\Resolvers, each responsible for idempotently resolving-or-creating one Lunar entity: TaxClassResolver, ProductTypeResolver (auto-attaches system attributes to new types), BrandResolver, TagResolver, CollectionResolver (multi-level, multi-collection support via >-delimited breadcrumbs), ProductOptionResolver (dedupes options/values by slugified name so case variants like "Size"/"size" resolve to one row), AssetResolver (Spatie MediaLibrary via Product::addMedia(), matches local export images by UUID first, filename fallback), PriceResolver (minor-unit conversion per currency), ImportAttributeResolver and ProductAttributeResolver (custom cost_per_item/seo_title/seo_description attributes, field-type-aware attribute_data writing).
  • docs/shopify-import.md — full CSV-to-Lunar field mapping reference and import design notes.
  • docs/lunar.md — new "Gotchas" section documenting non-obvious Lunar behavior hit while building the importer (table-prefix/nested-set race, required ProductOption.handle, per-group Attribute.position, etc.).
  • CONTRIBUTE.md — local dev setup (path-repo + bin/dc-core.sh), and the manual DB-verification workflow used to build this feature.

Fixed

• ProductOptionResolver created duplicate ProductOption/ProductOptionValue rows when the same option or value appeared with different casing across products (e.g. Shopify export rows using both "Size" and "size"), and could create a duplicate value within a single product's own variant rows due to relying on a stale lazy-loaded relation. Both now resolve by normalized (slugified) identity queried fresh from the database.
• boboko:migrate:import could dispatch an import job with a blank file path (silent no-op failure) if the file-path prompt was answered empty; it now re-prompts until a valid, existing file is given.

[0.0.1] - 2026-07-03

First release.

Added

• OTP-based authentication built around User instead of Customer (UserOtpService, UserOtpMail), replacing the earlier customer-scoped OTP flow.
• UserCreated event with a CreateCustomerForUser listener to provision a Lunar customer automatically when a user is created.
• UserRelationManager for managing users from the customer resource in the panel.
• Stoic image UI component (resources/views/ui/stoic-image.blade.php) and its YAML-driven config/service (see Stoic::class).
• config/core.php for module-level configuration.
• AuthServiceProvider and CustomerServiceProvider now register alongside CoreServiceProvider.
• Migrations: add OTP to users, drop OTP from Lunar customers, drop password from users, make name nullable on users and Lunar customers.
• docs/modules.md documenting module structure.

Removed

• CustomerOtpMail and CustomerOtpService, superseded by the user-based OTP flow.

Dependencies

• Added explicit symfony/yaml requirement (used directly by Stoic::loadConfig()).