Weave Code
Laravel Magento Prices Laravel Package
justbetter/laravel-magento-prices
A Laravel package that brings Magento pricing into your application, letting you retrieve and work with Magento product prices through simple helpers so storefronts and integrations can display consistent, up-to-date prices.
Package to send prices to Magento from a Laravel application using a configurable source.
Frequently asked questions about Laravel Magento Prices
- How do I install justbetter/laravel-magento-prices in a Laravel application?
- Install it with Composer using composer require justbetter/laravel-magento-prices, pinning to ^2.6.1 rather than 2.6.0 because of the async update flag fix. The package registers through a standard Laravel service provider, so no manual provider entry is normally needed. Publish the config file with php artisan vendor:publish and set your price source and Magento connection details there. If you use the asynchronous write path, make sure a queue worker is running before you rely on prices reaching Magento.
- Which Laravel and PHP versions does justbetter/laravel-magento-prices support?
- The package targets the standard Laravel stack of service provider, published config, facade/contract binding and queue jobs, and the surrounding ecosystem has moved through Laravel 9, 10 and 11. The 2.6.1 release notes do not restate version constraints, so check the require block in the package's composer.json against your framework and PHP versions. Also confirm which Laravel and queue driver combinations are actually exercised in CI before committing to it.
- What does version 2.6.1 of justbetter/laravel-magento-prices fix?
- Release 2.6.1 is a single-line patch titled Do not set update to false after async update, delivered in PR #44. It corrects internal state handling at the end of an asynchronous price update, where the package previously cleared the update flag after the job ran. Left unfixed, that is a lost-update pattern: a price change arriving mid-flight could be marked as already handled and never reprocessed, leaving a stale price in the storefront. The release adds no new configuration keys, no migrations and no signature changes, so adopting it is effectively a composer update plus validation of your assumptions about when a price counts as settled.
- Does the package push prices to Magento synchronously or through a queue?
- It does both. Reads of Magento pricing data are synchronous, exposed through simple helpers so your storefront or integration can display consistent prices. Write-back is asynchronous and queue-driven, which is why the 2.6.1 update-flag fix matters and why queue worker and retry configuration become part of your deployment checklist. Behaviour differs between the sync driver and Redis, SQS or database queues, so test the driver you actually run in production.
- What does configurable source mean for justbetter/laravel-magento-prices?
- The package sends prices to Magento from a source you define in its published configuration rather than hard-coding where prices originate. That lets you point it at your own pricing tables, an ERP feed or another internal service without touching package code. Version 2.6.1 introduces no new configuration keys, so existing overrides should reconcile cleanly, but re-publish the config if you carry local customisations and diff it against the new default.
- Is the async price update idempotent if a queue job is retried or duplicated?
- The 2.6.1 release notes do not address idempotency, retry or backoff, so those remain your responsibility to verify. In practice you should confirm that replaying the same price job for a SKU does not corrupt state on the Magento side, and you should check ordering when several price changes for one SKU are queued concurrently. Configure sensible retry and backoff limits on the queue connection the package uses. Treat the async machinery as something to test explicitly rather than assume.
- Does justbetter/laravel-magento-prices require database migrations?
- Release 2.6.1 references no migrations, and the description does not indicate that the package ships schema of its own. The safest step before deploying is to diff the package's migrations directory between tags so you know whether anything new appears. If your own application stores the update flag the patch touches, confirm how that state is persisted, whether as a column, a cache key or in-memory state, because it changes how long a record stays marked as needing an update.
- What are the alternatives to justbetter/laravel-magento-prices?
- The main alternative is building your own integration against Magento's APIs and owning the price pipeline, queue jobs and retry logic yourself. That gives full control at the cost of maintaining a seam this package already provides, including service provider registration, published config and queue-driven write-back. The package fits best when Magento is the system of record for catalog and pricing and Laravel handles presentation, orchestration or B2B logic. It is a poor fit if you want Laravel to be the pricing authority, since the write path assumes Magento is downstream but authoritative.
- Is justbetter/laravel-magento-prices production ready and actively maintained?
- It is a focused community package from a single maintainer, so set support expectations accordingly. Release 2.6.1 is a one-line patch, which suggests a modest cadence rather than rapid feature development, and there is no guarantee of long-term roadmap visibility. Technically the integration risk is low to moderate, and this release reduces it, but the residual risk sits in queue worker configuration, retry behaviour and Magento-side write idempotency, all of which you must validate yourself.
- Will upgrading to 2.6.1 repair prices that were incorrectly marked as updated under 2.6.0?
- The release notes describe a forward-looking state-handling fix, not a data repair, so do not assume existing stale rows are corrected by the upgrade alone. The fix stops the flag being cleared incorrectly in future async updates; it does not state that previously mis-flagged records are re-marked as needing an update. Plan a manual full resync of affected SKUs, or verify whether your stored flag lifecycle naturally re-queues them. Confirm the flag's storage and lifecycle in your own setup before deciding the recovery path.
Weaver
How can I help you explore Laravel packages today?