Laravel Magento Prices Laravel Package

Getting Started

Install the package and publish its configuration and migrations:

composer require justbetter/laravel-magento-prices
php artisan vendor:publish --tag="magento-prices-config"
php artisan vendor:publish --tag="magento-prices-migrations"
php artisan migrate

Then wire up the Magento connection in .env (base URL plus the integration/API token the package uses) and open config/magento-prices.php before writing any code — it is the single most important file to read, because it controls the store/website scope, currency handling, queue connection, and the async-update behaviour that the rest of the package hangs off.

The fastest first use case is a single price lookup: fetch the price for one SKU and render it on a product detail page. Once that round-trip works, promote it to a scheduled sync (a console command in routes/console.php or the scheduler) so the local price table stays warm, and only then introduce async updates. Doing it in that order means you discover connection/scope problems at the cheapest possible point.

Implementation Patterns

Scheduled bulk sync as the backbone. Most installations run a recurring command that pulls the price feed for the configured store scope and writes it into local tables. Schedule it off-peak, keep it idempotent, and make it safe to re-run — a full sync should be able to overwrite everything without side effects.

On-demand refresh for long-tail products. For catalogues too large to sync constantly, trigger a targeted update for a single SKU when a product page is viewed and the local price is older than a threshold. Gate this behind a cache/last_updated check so a traffic spike doesn't turn into an API spike.

Async updates via the queue. The package supports deferring price updates to a job. Dispatch the job from your sync command or from a model observer, and let workers do the HTTP work. This is the pattern the 2.6.1 release touches, so it is clearly the intended production path for anything beyond small catalogues.

Attach prices to your own models. Rather than scattering package calls through controllers, expose a price accessor or relationship on your Product model and let views/blade components consume that. It keeps the Magento dependency at the edge of the application and makes it trivial to swap in a stub during tests.

Store/currency scoping at the call site, not globally. Pass the store or website context explicitly per lookup where the package allows it. Multi-store setups that rely on a single global config value tend to produce cross-contaminated prices the moment a second storefront is added.

Test with HTTP fakes. Because the package is fundamentally an API client, Http::fake() around the underlying Magento endpoints gives you deterministic tests without touching config. Assert on the persisted price rows, not on the client internals.

Gotchas and Tips

Upgrade to 2.6.1 if you use async updates. Release 2.6.1 fixes a bug where an internal update flag was set to false after an async update completed (PR #44). The practical symptom on 2.6.0 was that prices would sync once and then silently stop being flagged for further updates — a failure mode that looks like "the scheduler is broken" but is actually state corruption. After upgrading, re-verify that a second sync cycle still picks up changed prices.

Restart queue workers on deploy. Any change to package config or job classes is invisible to long-running workers until php artisan queue:restart runs. A large share of "the price didn't update" reports trace back to this.

Watch API rate limits and payload size. Bulk syncs against Magento can be slow and throttled. Batch requests where the package supports it, keep the scheduled job's timeout generous, and log the elapsed time so you notice when the catalogue outgrows a single run.

Cache TTL must be shorter than your sync interval. If you cache rendered prices for longer than the sync cadence, users see stale numbers and blame the sync. Align the two, or invalidate cache entries from the sync job itself.

Token expiry is a silent killer. Integration tokens rotate or expire; when they do, syncs fail quietly if you aren't logging failures. Add alerting on the scheduled command's exit status rather than relying on the absence of errors.

Migrations before first sync. Running the sync command against an unmigrated database fails in a confusing way. Keep the publish-migrations step in your deploy script, and confirm the table names in the config match what your own code queries.

Extension point: model observers. The cleanest place to hook custom behaviour (cache busting, price-change events, Slack notifications) is an observer on the package's price model, not a subclass of the client. It survives package upgrades far better.