Laravel Magento Products Laravel Package

Getting Started

The package pulls Magento catalog products into Laravel as Eloquent models, so most day-to-day work is "install, configure credentials, run the import command, then react to events."

1. composer require justbetter/laravel-magento-products
2. Publish config and migrations:

   php artisan vendor:publish --provider="JustBetter\MagentoProducts\ServiceProvider"
   php artisan migrate
   

3. Add Magento connection values to .env (base URL, API token/credentials, store view) and confirm the generated config/magento-products.php points at the right store scope.
4. Seed the local table by running the package's import/sync command (check php artisan list | grep magento — names shift slightly between minor versions), ideally queued and chunked.

Where to look first:

• config/magento-products.php — table name, queue connection, model overrides, API settings.
• src/Models/ — the product model and its scopes; this is what you'll query.
• src/Events/ — ProductCreated, ProductUpdated and friends; this is the main integration seam.
• src/Jobs/ and src/Commands/ — how fetching and persistence are batched.

First real use case: get a SKU into Laravel and do something on arrival. Run the import for one SKU, then register a listener on the creation event and Event::fake() it in a test to confirm wiring. As of 1.9.2 the creation events are dispatched reliably, so this is now a safe hook point rather than an update-only one.

Implementation Patterns

Event-driven fan-out (the primary pattern). Treat the package as a source of truth for "a product appeared/changed" and push side effects into queued listeners:

Event::listen(ProductCreated::class, SyncProductToStorefront::class);
Event::listen(ProductUpdated::class, SyncProductToStorefront::class);

Implement listeners as ShouldQueue so import runs stay fast and a slow downstream (search index, ERP, image pipeline) can't stall the sync. Route them onto a dedicated queue in config/magento-products.php rather than default.

Full sync on a schedule, targeted sync on demand. Schedule the bulk import command nightly in routes/console.php/Kernel, and dispatch the package's single-product update job for one-off SKUs — after a price change, from an admin action, or from a webhook receiver. Keep the on-demand path idempotent since it can race with the bulk run.

Mapping into your own domain. Don't scatter Magento field access through your app. Add one mapper/service that translates the package model into your local Product/Variant models, and keep custom columns on your own tables so package upgrades can't clobber them.

Scoping by store view. If you sell across websites, import per store view and key your local records by (sku, store_id). Doing a "global" import and then filtering by store in queries almost always ends in price/visibility bugs.

Testing. Use RefreshDatabase plus Event::fake() to assert listeners fire for both creation and update. For integration tests, bind a fake Magento client into the container rather than hitting the API; keep one or two contract tests against a recorded response fixture.

Gotchas and Tips

• Creation events are new in 1.9.2. Prior to this release, only updates dispatched events, so if you built a workaround (polling for new rows, a created_at sweeper, or a saved model observer), remove it — you'll otherwise double-process every new product.
• Listeners registered for ProductUpdated only will silently miss initial imports. When you first enable the package, every product arrives as a creation. Audit existing listeners now that 1.9.2 fires them, and make sure your handler is safe to run for a product it has never seen.
• Events fire inside the import path. If a listener throws synchronously (non-queued), it will abort the surrounding batch. Queue listeners, or wrap side effects in try/catch with logging.
• Idempotency is on you. Re-running an import can re-emit creation events for rows that were deleted locally, or emit updates for unchanged data. Key your downstream writes by SKU, not by event instance.
• SKUs are strings and can be long/odd. Don't cast to integer or assume VARCHAR(64); Magento allows up to 64 chars plus edge cases like leading zeros and hyphens.
• Queue backlog is the usual failure mode. A large catalog plus a slow listener produces a queue that never drains. Set a separate queue, a worker count, and a retry_after that exceeds your listener's worst-case duration.
• Debugging tip: run the import for a single SKU with the queue connection set to sync in a local .env. If the event doesn't fire there, the problem is in configuration/model overrides, not your listener.
• Config quirks: table name and model class are overridable in config — if you swap the model, re-check that it still dispatches the package events, since custom models that don't extend the base can drop them.
• Extension points, in order of safety: event listeners → published config → published migrations → subclassing the product model. Avoid editing vendor files; this package ships frequently enough that you'll lose the changes.