darinlarimore/statamic-3d-field
A Statamic fieldtype for uploading and managing 3D model files, with an interactive control-panel preview powered by Google's model-viewer. Easily add GLB/GLTF assets to entries and render them on your site.
Architecture fit: This is a Statamic Control Panel fieldtype addon delivered through Composer, so its Laravel/PHP integration surface is limited to package discovery, service provider registration, config/assets, and Statamic bootstrapping. The material change in 1.1.0 is frontend: the CP fieldtype moves from Vue 2 to Vue 3 and now registers inside Statamic.booting(). That aligns with Statamic 6’s Vue 3 Control Panel architecture while attempting to preserve Statamic 5 compatibility via a widened statamic/cms constraint.
Integration feasibility: Feasible for existing Laravel + Statamic applications via normal Composer update and Statamic addon registration. The widened constraint ^5.0|^6.0 reduces upgrade friction for teams moving from Statamic 5 to 6. However, the released artifact is a single Vue 3/IIFE build claimed to be backwards compatible with Statamic 5, so feasibility depends on that bundle behaving correctly in both CP runtimes. The FieldtypeMixin banner shim, externalized Vue, and model-viewer custom element registration are implementation details that should be validated in real CP screens rather than assumed from the release note.
Technical risk: Medium. Risks include dual-version support drift, Vue 3 template compilation differences, custom element lifecycle issues with model-viewer, replacement of toggle-input with ui-switch causing visual or behavioral regressions, and asset caching causing stale CP bundles after upgrade. Externalizing Vue is generally correct for Statamic 6, but it raises a compatibility question for Statamic 5 if the host CP runtime differs. The IIFE bundle and banner shim are pragmatic compatibility mechanisms but increase build complexity and debugging cost.
Key questions:
model-viewer loaded from a CDN, bundled, or expected to be provided by the host app? What happens if it fails to load?toggle-input with ui-switch?Stack fit: Fits Laravel applications using Statamic as the CMS. The package is not a general Laravel library; value depends on Statamic CP fieldtype usage. The 1.1.0 release is primarily a Statamic 6 readiness update, so it is most relevant to teams planning or performing a Statamic major-version upgrade.
Migration path: For existing Statamic 5 users, treat this as a normal patch/minor upgrade but require CP smoke testing: edit content using the fieldtype, confirm the model-viewer field renders, confirm the ui-switch control works, and verify assets are not stale. For Statamic 6 upgrades, update the addon first or alongside the CMS upgrade, run composer update, clear Statamic/Laravel caches, republish assets if the package requires it, and verify the fieldtype appears and saves correctly.
Compatibility: The declared Composer constraint now supports statamic/cms ^5.0|^6.0. That is necessary but not sufficient. The practical compatibility claim should be proven through a test matrix covering Statamic 5 and 6, supported Laravel/PHP versions, CP asset compilation, and browser behavior. Because the frontend was ported to Vue 3, backward compatibility with Statamic 5 is the highest-risk compatibility claim.
Sequencing: Recommended sequence: pin current addon version and capture baseline behavior; upgrade addon in a staging environment on Statamic 5; run CP fieldtype regression tests; then perform Statamic 6 upgrade or validate a fresh Statamic 6 environment; clear caches and rebuild/publish assets; verify create/edit/read/save flows and browser console for Vue/custom-element errors. Avoid bundling this addon upgrade into a larger CMS migration without isolated validation.
Maintenance: The addon now carries a dual-support obligation: a Vue 3 build that must remain compatible with Statamic 6 while not breaking Statamic 5. Maintainers must track Statamic CP API changes, Vue build tooling, model-viewer behavior, and UI component changes such as ui-switch. The IIFE/banner-shim approach should be documented so future maintainers understand why it exists and when it can be removed.
Support: Support load may increase around Statamic 5/6 mixed environments, especially where users report the field rendering but not saving, missing custom elements, or broken toggle controls. Support runbooks should include browser console checks, cache clearing, asset republishing, and confirmation of the installed Statamic version.
Scaling: Runtime scaling impact is low for typical CMS usage because this is a CP fieldtype, not a high-traffic request path. The main scaling concern is asset delivery: externalizing Vue avoids duplicate Vue payloads in Statamic 6, but the IIFE bundle and model-viewer dependency still affect CP page weight. Validate behavior with many fieldtype instances on a single entry if the fieldtype is used heavily.
Failure modes: Likely failure modes are fieldtype not registering under Statamic.booting(), Vue 3 template compile/runtime errors, model-viewer not defined or not upgraded, ui-switch styling/behavior mismatch, stale published assets after Composer update, and Statamic 5 compatibility gaps despite the widened constraint. Most failures would surface in the CP rather than in public site rendering.
Ramp-up: Low for Laravel developers familiar with Composer and Statamic addons; moderate for frontend maintainers because the release introduces Vue 3 build changes, custom elements, and a compatibility shim. Teams should budget a short CP regression pass rather than a full application QA cycle, unless they are simultaneously upgrading Statamic major versions.
How can I help you explore Laravel packages today?