Quazar Laravel Package

Getting Started

Quazar is a pre-1.0 e-commerce layer that sits on top of Grafite CMS, with a lineage going back to 2017. The situation has changed from the previous assessment: a v0.0.1 beta has been published, so the "archived and frozen" read no longer holds. What replaces it is not "healthy" — it's "alive but unstable." The release note is a single sentence soliciting feedback, with no changelog, no compatibility statement, and no migration guide. Before writing a line of code, accept that 0.0.x means no backwards-compatibility promise: the caret range ^0.0.1 resolves only to 0.0.1 anyway, and the next tag may rewrite migrations, rename models, or change the checkout flow.

The package still carries zero dependents, so there is no community knowledge base, no Stack Overflow corpus, and no third-party tutorials. The service provider wiring, Blade views, and (unless the tag says otherwise) the illuminate/* and grafite/cms pins still assume Laravel 5.3/5.4 and PHP 7.0/7.1. The release note says nothing about relaxing those constraints — do not assume it did.

Minimal path to a running evaluation:

1. Read composer.json at the v0.0.1 tag first. The release note is the entire changelog. Confirm whether the framework constraints moved; if they didn't, everything below applies unchanged.
2. Build a throwaway legacy environment. Docker with php:7.1, MySQL 5.7, and a fresh Laravel 5.4 skeleton. Pin composer require yab/quazar:0.0.1 exactly — no range, no dev-master.
3. Install Grafite CMS first. Quazar's admin UI (products, orders, subscriptions) is registered as Grafite modules, so the CMS is a hard prerequisite and must boot before Quazar.
4. Register providers in config/app.php if you're below Laravel 5.5 — Grafite CMS providers first, then Yab\Quazar\QuazarServiceProvider. On 5.5+ confirm package discovery actually picked it up.
5. Publish and migrate: php artisan vendor:publish --provider="Yab\Quazar\QuazarServiceProvider" then php artisan migrate against a clean database.
6. Log into /admin and look for the Quazar menu entries. If they're absent, the provider boot order is wrong or the CMS migrations didn't run.

Where to look first, in order:

• composer.json at the tag — the real compatibility contract, and the only place the truth lives.
• The commit history between the last pre-release state and v0.0.1 — the release note won't tell you what changed; git log will.
• src/QuazarServiceProvider.php — bindings, publishes, route and admin-module registration.
• config/quazar.php — payment keys, currency, shipping settings.
• database/migrations/ — the actual schema for products, orders, transactions.
• src/Http/Controllers/ and resources/views/ — the storefront and checkout flow.

First use case to prove the stack: create one physical product in the admin, add it to a session cart via the storefront route, run a checkout against Stripe test keys, and confirm both an orders row and the confirmation email. That single loop exercises product CRUD, cart, checkout, gateway, persistence, and notifications — if any of those are broken, you'll know immediately whether the package is salvageable for your needs.

Implementation Patterns

Pin the exact tag and vendor the lock file. With 0.0.1 there is no semver safety net; composer update on a 0.0.x line is a coin flip. Commit composer.lock, and treat every upstream tag bump as a breaking change requiring a read of the diff, a migration check, and a fresh evaluation on a clean database.

Treat the beta invitation as a channel, not a promise. The maintainer asked for feedback to "move this forward" — that means issues and PRs are genuinely welcome, which is a better first move than forking. But it also means there is no SLA, no triage history, and no release cadence. File the issue, open the PR, and simultaneously keep a fork ready. Do not block a delivery on an upstream fix landing.

Treat products as typed strategies, not string switches. Quazar distinguishes physical, digital, and subscription products; the type drives shipping, delivery, and billing. Don't scatter if ($product->type === 'digital') through controllers. Add scopes (Product::digital()), a small ProductType value object, and route behavior through it. This is also the cleanest seam if you later port off the package.

Wrap checkout in a service class. The package's controllers will happily create orders from a cart, but you want your own PlaceOrder action that: validates the cart, creates the order, charges the gateway, records the transaction, fires events, and clears the session. Keep the package's controller as a thin adapter that delegates to it. That's the difference between a demo and something you can test — and it's what lets you survive a 0.0.x controller change.

Own the payment boundary. Quazar's payment integration is built on an old stripe-php; the API version is pinned in the vendor tree, and webhook signature verification is either absent or outdated. Define your own PaymentGateway interface, implement a Stripe adapter, and bind it. Record gateway transaction IDs on the order, make webhook handlers idempotent, and verify signatures yourself. Never let raw gateway responses dictate order state directly.

Drive subscriptions from the gateway, not a cron. The package models subscriptions, but you do not want to hand-roll recurring billing. Use Stripe subscriptions as the source of truth and sync status back via webhooks into Quazar's subscription records. A scheduled command that "renews" cards locally is a compliance and correctness trap.

Gate digital delivery on paid status. Store file references on the product (private disk, not public/), and only issue a temporary signed URL after the order is marked paid. Check the package's download route — if it serves files directly from public/, replace it.

Extend the admin through Grafite, not by editing vendor. Quazar registers its CRUD modules with Grafite's module system. Add custom fields in your own migrations against the package tables rather than editing vendor migrations, and publish/override views under resources/views/vendor/quazar. If you need a new admin screen, use Grafite's CRUD scaffolding rather than building a parallel admin.

Keep your code in app/Shop (or similar) and never patch vendor/. Contribute the fix upstream first while the beta window is open; if it isn't merged on your timeline, fork yab/quazar into your org, point composer at the VCS repo, and maintain it. With 0.0.x churn, expect to rebase that fork on every upstream tag.

Test the loop, not the package. Write feature tests that hit your checkout action with a faked gateway, plus factories for products/orders. The package's own test suite won't run on modern PHPUnit, so the tests you write are the only safety net you'll have.

Gotchas and Tips

• Beta is not a stability signal — it's the opposite. 0.0.1 is the first tag, which usually means the author is still finding the shape of the API. Expect renames, schema rewrites, and behaviour changes between 0.0.x releases with no deprecation path. Budget for a read-the-diff ritual on every bump.
• Re-verify the archive assumption per release, not per assessment. A publish doesn't guarantee sustained maintenance — one tag after a long silence can be a one-off. Check commit frequency, issue responsiveness, and whether the next tag arrives before you commit a roadmap to it.
• Migrations may be rewritten between beta tags. With pre-1.0 packages, editing an existing migration instead of adding a new one is common and legitimate. Never assume php artisan migrate is additive; diff database/migrations/ before upgrading anything with real data.
• Provider order is load-bearing. Grafite CMS must boot before Quazar or the admin menu, routes, and module registrations silently disappear. Same for publish order. When something is "missing," check config/app.php before anything else.
• Watch for table collisions. The migrations create products, orders, and transaction tables. If you already have any of those names, the first migrate on an existing database will fail or, worse, merge into your schema. Always evaluate on a clean DB.
• Money units are the classic 100x bug. Check whether the schema stores prices in cents or decimals before you write a single price. Normalize at the boundary and never mix representations between the package and your code.
• Config caching bites old packages. Several Laravel 5.x-era packages read config at boot in ways that break with config:cache. After publishing, run php artisan config:clear and test with the cache enabled before deploying.
• Stripe drift is the sharpest edge. An old stripe-php will reject current API versions and may not implement webhook signature verification the way you expect. Pin the API version explicitly, verify signatures in your own handler, and add idempotency keys to charge creation.
• Tax, refunds, and multi-currency are almost certainly thin or absent. Budget for building them. Don't assume the package's order totals match your accounting requirements.
• Admin routes are only as safe as Grafite's middleware. Confirm the middleware group on the admin routes and that Grafite roles are enforced. An unprotected /admin is a one-line catastrophe.
• Debugging is manual. No Telescope on Laravel 5.4. Use Xdebug, DB::listen, and explicit logging around gateway calls. Package exceptions tend to be terse; log the raw request/response payloads so you can reproduce failures — and so you have something useful to paste into an upstream issue.
• Extension points to rely on: the published config file, container bindings in QuazarServiceProvider, Eloquent model events, and view overrides. Anything requiring subclassing a package model is fragile unless that model is resolved from the container — verify before committing, especially across a 0.0.x bump.
• Plan the exit. Use Quazar as a working reference for schema and flow, but for anything long-lived evaluate Lunar, Aimeos, or Laravel Cashier + custom models. A beta tag is a reason to prototype with it, not a reason to build a business on it.