heidkaemper/statamic-import-image-metadata
A Statamic addon that reads metadata embedded in your images and imports it into asset fields, so EXIF and IPTC details like camera, location, and copyright are available in the control panel and templates without manual entry.
Context and confidence. This is the first assessment for this package; there is no prior baseline and no repository metadata, dependency manifest, or issue-tracker data supplied. The sole signal is a one-line changelog entry: "Support for Statamic 5." Everything below is therefore a structured hypothesis to be validated, not a confirmed finding. The assessment should be re-issued once composer.json, the diff for the 1.2.0 tag, and the CI matrix are available.
Architecture fit. The release confirms the package occupies the Statamic addon/integration tier of the Laravel ecosystem rather than being a framework-agnostic library. That is a favourable fit for our stack if we are already on Statamic: addons register through a Laravel service provider and an addon manifest, publish config and assets, and extend Antlers via tags, modifiers, and fieldtypes. The practical consequence is that the package's runtime surface is coupled to Statamic's internals — tag registry, fieldtype lifecycle, blueprint/stache behaviour, and control-panel assets — not just to Laravel's public contracts. Statamic majors are the dominant compatibility axis, more so than Laravel majors.
Integration feasibility. Low-to-moderate effort, contingent on one unknown: whether 1.2.0 is additive (constraint widened to allow statamic/cms ^4.0|^5.0) or a hard cut (constraint moved to ^5.0 only). Statamic 5 requires PHP 8.2+ and Laravel 10/11; Statamic 4 supported PHP 8.0+ and Laravel 9/10. If the package moved its floor to Statamic 5 unconditionally, then a minor version bump (1.2.0) carries a de facto breaking change for anyone still on Statamic 4 — semver on the package version does not communicate that, and our upgrade tooling will not flag it. This is the single most important thing to verify before scheduling anything.
Technical risk. Medium, concentrated in three areas. (1) Support-matrix ambiguity: the note does not state whether Statamic 4 remains supported; dual support doubles the test matrix and is a standing drag on maintenance. (2) Opaque change surface: a one-line note for a major-CMS compatibility release is a documentation smell — Statamic 5 brought control-panel changes (Vue 3), revised Antlers behaviour, and data/stache migrations, so a genuinely working port usually touches more than a constraint. A one-line note may mean the port was trivial, or that the changelog is under-maintained. Both are risks, in opposite directions. (3) Transitive conflict: our own statamic/cms pin, plus any other addons, must resolve jointly with this package's constraint.
Key questions.
composer.json — widened range or new floor? Is Statamic 4 still in the require constraint and in CI?Stack fit. Target state is PHP 8.2+, Laravel 10 or 11, Statamic 5. Confirm our application already meets the PHP and Laravel floors before touching the package; if we are on Laravel 9, this release is not reachable and the conversation is moot until the framework upgrade lands.
Migration path. Treat this as a two-step upgrade, not one. Upgrade Statamic 4 → 5 first (including Statamic's own data migrations, cache/stache invalidation, and any blueprint or Antlers fixes), get the application green on Statamic 5 with the package absent or pinned to its old version, then install 1.2.0. Doing both in a single change collapses two independent failure domains into one debugging session.
Compatibility. Pin explicitly ("^1.2") rather than floating, and record the resolved statamic/cms version in the lockfile. If 1.2.0 is a hard cut, treat it as a major-version upgrade in our internal change classification regardless of what the package's semver says, and require an owner sign-off. If it is additive, it is a routine bump and can ride the normal patch cadence.
Sequencing. (1) Pull the 1.2.0 diff and composer.json; answer the constraint question. (2) Verify Statamic 5 upgrade prerequisites in our app. (3) Run the package's test suite against our PHP/Laravel matrix in a scratch branch, not just the maintainer's. (4) Stage deploy with control-panel and Antlers rendering smoke tests — fieldtypes and CP assets are where addon ports break silently. (5) Production, with a documented rollback to the prior pinned pair.
Maintenance. The recurring cost is the CI matrix. If the package supports Statamic 4 and 5 simultaneously, expect slow drift: fixes landing for one major and not the other. If it dropped Statamic 4, we inherit an upgrade obligation on the maintainer's timeline rather than ours. Either way, add a recurring check that our pinned package version still declares support for our pinned Statamic version — this class of breakage is invisible until a composer update.
Support. Documentation and Marketplace metadata are the support surface for addons. A one-line changelog suggests documentation may lag the release; budget time for the team to read source rather than docs during ramp-up. Confirm whether the maintainer offers any support channel and what the historical response time is.
Scaling. No meaningful impact expected. Addon overhead is request-time tag/fieldtype resolution and CP asset loading, neither of which changes materially between Statamic majors. If the package does anything at boot — registering broad listeners, eager-loading, or touching the stache — that is worth a look, but nothing in this release note suggests a performance change.
Failure modes. Watch for: composer resolution conflicts against our other addons; silent Antlers rendering differences after the Statamic 5 upgrade; fieldtype or blueprint data that reads correctly in the CP but fails on save; asset-container/Flysystem behaviour differences; and CP assets stale in cache after deploy. The dominant risk, though, is organisational — a minor version number that hides a major compatibility cut, discovered in production rather than in review.
Ramp-up. Low for developers already fluent in Statamic; the concepts (addons, tags, fieldtypes, Antlers) carry across majors. Budget roughly a day for a developer unfamiliar with Statamic 5's control-panel and Antlers changes to work through the upgrade in staging, plus review time for whoever owns the dependency policy. The larger time cost is not learning the package — it is confirming what the release note declined to tell us.
How can I help you explore Laravel packages today?