Laravel Magento Prices Nova Laravel Package

Getting Started

This package is the Nova presentation layer for JustBetter's Magento pricing stack: it lets a Nova resource surface (and optionally edit) Magento 2 product prices — base price, special price and its date window, cost, and tier prices — without leaving the admin panel. The important mental model is that Nova is not the source of truth: every value shown comes from a Magento API call made by the underlying justbetter/laravel-magento-prices package, and the Nova field is a thin UI on top of it.

Minimum path to a first working field:

1. composer require justbetter/laravel-magento-prices-nova — this pulls in the core pricing package and registers its service provider. Confirm the Nova major version in composer.json matches what the release supports (see Gotchas — 4.5.0's Laravel 13 support is the constraint that will bite first).
2. Publish and fill in config: php artisan vendor:publish --tag="magento-prices-config" (check the README for the exact tag). You need the Magento base URL plus credentials — an integration access token is the usual choice for server-to-server, and it expires, so plan for refresh rather than a hardcoded literal.
3. Add the field to a single Nova resource's fields() method before touching anything else. One resource, one SKU, detail view only.
4. Verify the round trip by opening that resource in Nova and comparing the rendered price against Magento's admin. If they differ, the problem is almost always store/website scope or currency, not the field.

Where to look first when something is wrong, in order: the package README (field name, options, and whether a view needs publishing), config/magento-prices.php from the core package (connection, cache, store scope), then the core package's service class — that is where the actual HTTP call and any caching live, so it is the right place to dd().

The first genuinely useful use case is a read-only price column on a product resource that mirrors Magento, followed shortly by an "edit special price" flow. Do not start with editing: reads fail loudly and safely, writes fail in ways that look like success.

Implementation Patterns

Detail-view-first, index-view-later. The natural instinct is to drop the field into the resource and see prices on the index table. Resist it — an index with 50 rows becomes 50 (or more) outbound API calls. Ship the field on the detail view, confirm correctness, and only then consider the index, ideally backed by the core package's caching layer or a locally synced prices table.

Pair the field with a refresh action. Because values are fetched live, stale-looking prices are a normal operational complaint. A Nova action that busts the cache for the selected resources (or re-syncs them if you use the package's persistence option) is far more useful to editors than any field option, and it puts the "make it current" affordance where they already are.

Treat the field as read-mostly and gate writes behind policies. If the field is writable, saving in Nova pushes to Magento. In multi-store setups this is where scope bugs surface: an editor saving on a store-view resource can silently write to the default scope. Wrap write access in a policy/canSee/readonly callback so only users who understand the store context can mutate prices, and let everyone else read.

Scope explicitly, don't inherit implicitly. Every price lookup needs a store or website code, and the correct one is rarely "whatever the default is". Pass the store code from the Nova resource's own context (a store_id column, a request parameter, a relation) rather than relying on the package default. This is the single pattern that prevents the most support tickets.

Compose rather than replace. The field renders values; it should not become your price-editing system. If you need bulk price updates, scheduled imports, or approval flows, keep that in the core package/queue layer and let Nova stay a viewer with a narrow write path.

Integration with a local price cache. The core package can persist fetched prices locally. If you enable that, do the initial population in a queued job or artisan command and warm it on a schedule — never on a web request, and never inside a Nova index resolve.

Testing. Http::fake() the Magento endpoint in feature tests and assert the field resolves; you do not want CI hitting a real Magento instance. Keep one integration test (manually run) against a staging Magento to catch API shape drift, since Magento's price payloads are the part most likely to change under you.

Gotchas and Tips

Laravel 13 support is the 4.5.0 headline, and it is a compatibility cliff, not a feature. This release adds nothing functional — it widens framework constraints. Before upgrading, check that your Nova version supports Laravel 13 and that the core laravel-magento-prices package has a matching release. If you are on Laravel 11/12, 4.5.0 buys you nothing; stay on 4.4.1 and upgrade when you move the framework. If you are mid-upgrade to Laravel 13, this is the release that unblocks you, and you should expect to bump Nova at the same time.

Expiring integration tokens are the most common "it broke overnight". Magento integration tokens have a TTL; a hardcoded token in .env works for weeks and then throws 401s in production. Either use an admin user/password flow with token refresh, or build the refresh into config. Log the response body on 401 — Magento's error messages are actually informative here.

Currency mismatch is silent. Magento returns base-currency values with no formatting; Nova renders whatever you give it. If your storefront currency differs from base currency, the field will look "wrong" while being technically correct. Decide deliberately whether the field shows base price or converted price, and label it.

Multi-store scope and use_default. In Magento, a store-view price can be unset, meaning it inherits from the default scope. Editors see a number and assume it is set at their level. Surface inheritance or restrict editing to the default scope, otherwise you get phantom overrides nobody can explain.

Special-price date windows are timezone-sensitive. special_from_date / special_to_date come back in Magento's configured timezone, which is frequently UTC while your admins are not. A special price that "expired early" is usually an off-by-hours conversion. Store and display in a single, documented timezone.

Tier prices are a nested structure, not a scalar. They do not fit a simple text field; plan for a repeater or a read-only table, and be aware that writing them back means replacing the whole set, not patching one row.

Attribute-level blockers for writes. Even with valid credentials, a price attribute not enabled for the relevant scope or not in the API-visible attribute set will reject updates. If saves appear to succeed but nothing changes in Magento, check the attribute's scope and used_in_forms before debugging your code.

Debugging tip. When a value is wrong, log the raw API response from the core service rather than inspecting the Nova field. By the time the field renders, the data is already whatever Magento said — the field has no transformation logic worth suspecting.

Extension points. The Nova field's resolve/fill behaviour and the core package's price resolver are the two seams to override (via subclassing or container binding) if you need custom formatting, store resolution, or a fallback to a local prices table when Magento is unreachable. Prefer the resolver seam: it keeps the caching and retry logic intact.

Downtime behaviour. Decide now what the field shows when Magento is down or slow — blank, cached value, or an error. The default of a failed request surfacing as an empty field trains editors to distrust the panel; a cached-value-plus-stale-indicator is worth the small effort.