In Other Shops Laravel Package

Technical Evaluation

Architecture fit This is a Laravel/PHP commerce support package (Filament admin schema + storefront actions + support helpers). v0.54.0 reinforces a contract boundary the package had only implicitly held: catalog display text is a model-level concern (getAttribute() via InteractsWithTranslations), not a database column. The new Support\ModelLabel::for(Model) makes that the sanctioned resolution seam, which is the right architectural move — it gives consumers one blessed path instead of ad-hoc pluck('name') / orderBy('name') calls. The fix itself is two call-site corrections; the durable change is the contract plus the doc rule.

Integration feasibility Low effort, high urgency. No new dependencies, no config, no migrations, signatures unchanged. Column-backed consumers (in-other-worlds) see genuinely zero behavior change. Translatable-catalog consumers (bianka) are currently 500-ing on every order show/edit page — this is a hotfix, not a feature adoption, and should be scheduled as such.

Technical risk

• The contract is documented, not enforced. Nothing prevents the next where('name', …) from shipping. ModelLabel::for() is opt-in; there is no query-builder guard or static check.
• Query→model shift. pluck('name','id') replaced by per-instance attribute resolution — plausible N+1 on order pages with large orderable option sets.
• Storefront search semantics are unclear. The broken where('name'/'description','like') and orderBy('name') clauses were removed; the notes don't state what replaces them. For translatable catalogs this could be a silent functional downgrade (search/sort stops working) rather than just a 500 fix.
• Silent label degradation. The name → title → label → slug → "{alias} #{id}" chain never fails, which means a misconfigured model renders opaque keys in the admin UI with no error signal.
• Test harness blind spot (most important). SQLite turns Laravel's double-quoted identifiers into string literals, so missing-column reads become WHERE 'name' … (always false) or no-ops instead of errors. 1065 green tests did not catch a production-wide 500, and two of the new tests passed against broken code until fixtures were rearranged. Green suite ≠ MySQL-correct.

Key questions

• What now provides search and sort in ListBrowsables for translatable catalogs — is filtering restored, deferred, or dropped?
• Is ModelLabel::for() invoked per row on order pages? What's the query profile at realistic option counts, and is eager loading required?
• Will the "catalog text is not a column" rule get an architecture test / static analysis, or stay doc-only?
• Is a MySQL CI lane on the roadmap, or is MySQL verification manual per release?
• Which other consumers have translations-backed catalogs and simply haven't reported the 500 yet?

Integration Approach

Stack fit Laravel + Filament admin + storefront actions. No new runtime requirements; PHP/Laravel support matrix unchanged.

Migration path Straight composer bump. No schema changes, no data backfill, no config publication. The {alias}:{id} option-key format is unchanged, so persisted references (order line option keys, session carts) remain valid — that materially lowers migration risk.

Compatibility

• Additive and non-breaking per release notes; public signatures untouched.
• bianka: required bump — order admin is broken without it.
• in-other-worlds: unaffected; normal cadence.
• Consumers must be classified by catalog shape (column-backed vs translations-backed) before rollout is scheduled.

Sequencing

1. Inventory consumers by catalog shape; flag all translations-backed sites as at-risk.
2. Patch bianka (and any other translatable consumers) first; verify order show/edit and storefront search against MySQL with representative data.
3. Post-deploy regression check: existing order line option keys still resolve to correct labels.
4. Adopt ModelLabel::for() in consumer-side custom Filament resources to converge on the shared seam.
5. Stand up a MySQL-backed CI lane before the next catalog-touching change.

Operational Impact

Maintenance Small, contained surface: one support class, two call-site fixes, +10 tests, one doc section. docs/periphery.md → "Catalog text is not a column" is the durable artifact — fold it into the code-review checklist for anything touching browsable/cartable models.

Support Expect a short tail of reports from translatable-catalog consumers who hit the 500 pre-patch. Support script: "bump to v0.54.0, then verify against MySQL with real data." No new configuration means no configuration-support burden.

Scaling Watch buildOrderableOptions() on high-volume tenants. Per-row attribute resolution on order pages with large option sets may add queries or memory where a single pluck previously sufficed. Benchmark at realistic catalog sizes rather than assuming parity.

Failure modes

• Regression recurrence: any future query-level where/orderBy on display fields reintroduces this class of outage — detectable only on MySQL.
• Silent label fallback: admin UI shows {alias} #{id} instead of names, with no error. Add logging/metrics when the terminal fallback fires.
• Search degradation: storefront search/sort behavior may have changed for translatable catalogs; monitor search usage post-deploy.
• False-green CI: the suite cannot fail on this bug class. Treat green as necessary, not sufficient.

Ramp-up Low. The fix is transparent to developers; the learning is the contract rule plus the SQLite caveat. Brief the team once on (a) ModelLabel::for() as the default way to render model labels, and (b) mandatory MySQL verification for changes touching browsable/cartable models.