Duplicator Laravel Package

Technical Evaluation

Architecture fit. Duplicator is not a general-purpose Laravel package; it is a Statamic addon. Its architectural fit therefore reduces to one question: does the target estate run Statamic, and on which major version? If it does not, the package is out of scope. If it does, the addon sits at the Control Panel UX layer — it adds a "Duplicate" action to supported content types and copies field data. It does not own routing, schema, storage, or business logic beyond that copy. That is a small footprint and a narrow blast radius, which is the strongest thing one can say about it. Confirm whether current Statamic already offers native duplication for the relevant collections; if so, this package is a redundant convenience.

Integration feasibility. Installation follows the standard Statamic addon pattern: Composer require, service provider auto-discovery or registration, optional config publishing. Real feasibility is governed by three version axes — Statamic major, Laravel major, and PHP minor — and the addon has been archived since May 2023. It is unlikely to declare or be tested against Statamic 4/5 or PHP 8.2/8.3. composer why-not against a current project will answer installability faster than any release-note reading. Do not assume installability; verify it.

Technical risk.

• Archived upstream. This is the dominant risk. An archived repository receives no security patches, no compatibility updates, and no bug fixes. Any defect we hit becomes ours to fix by fork. MIT license makes forking lawful, not free.
• Compatibility drift. The last release predates likely Statamic major versions in current use. The failure is not always a hard install error; it can be an addon that installs and then behaves subtly incorrectly in the Control Panel.
• Low adoption signal. 15 stars and a low composite score indicate a small user base. Fewer users means fewer eyes on edge cases — nested fields, relations, assets, localization, permissions — which are exactly where duplication routinely misbehaves.
• Version hygiene precedent. v4.0.1 "added back PHP 8.1 support," implying v4.0.0 removed it. A patch-level platform reversal in one release cycle is a SemVer and testing-discipline smell; expect similar volatility if the line were still active.
• Duplication correctness. "Preserves field values and related data" is deceptively hard: relations, asset references, unique slugs, entry URIs, and multi-site placement must each be handled deliberately. A misduplicated entry creates bad content state that editors may publish.
• Permission modelling. A duplicate action must respect the authoring permissions of the source and target collections. Verify the addon enforces Statamic's permission layer rather than bypassing it.

Key questions.

1. Which Statamic major, Laravel major, and PHP minor does each target environment run, and does the archived composer.json admit them?
2. Is the package still resolvable from Packagist, or has it been abandoned/name-squatted since archiving?
3. Does Statamic now ship native content duplication, making this addon redundant?
4. How does the addon handle relations, assets, unique slugs/URIs, and multi-site localization on duplicate?
5. Does it enforce Statamic permissions, or copy across boundaries an editor should not cross?
6. Is maintaining a fork an acceptable cost, or is the correct decision to drop the capability?
7. Confidence in this assessment is low-to-moderate: it rests on package metadata and a one-line release note, not on a code or artifact review.

Integration Approach

Stack fit. The relevant matrix is Statamic major × Laravel major × PHP minor per environment, not PHP alone. The addon is viable only where that triple intersects its declared constraints. Environments outside the window are not candidates; do not stretch the window with --ignore-platform-reqs.

Migration path.

1. Inventory every Statamic environment and its Statamic/Laravel/PHP versions.
2. Review the archived repo's composer.json, config, service provider, and action classes; flag Statamic APIs that may have moved since 2023.
3. Make an explicit build-vs-adopt decision: native Statamic duplication > actively maintained third-party addon > archived addon > internal fork. Archived code should be the fallback, not the default.
4. If adopting: install in one staging environment and exercise duplication across the full field-type matrix — text, assets, relations, grids, Bard, multi-site.
5. If forking: fork under our org, patch compatibility, and publish via a private registry so the dependency is owned rather than merely inherited.

Compatibility. Test against the addon's stated supported versions and against our actual ceiling versions. Archived addons commonly pass their historical CI and fail our matrix. Treat the Control Panel as the test surface: an addon that loads but throws on action click is a production surprise, not a dev-time one. Validate asset and relation copying explicitly, since those are the most likely silent failures.

Sequencing.

• Phase 0: version inventory and manifest review. Gate: viability decision documented per environment.
• Phase 1: build-vs-adopt decision with a named owner. Gate: approved direction.
• Phase 2: staging pilot on one environment, full field-type matrix, permission checks. Gate: duplication output correct and authorized.
• Phase 3: roll out to compatible environments, or fork-and-publish if patching is required.
• Phase 4: log the archival exception with an owner and a re-evaluation date.

Operational Impact

Maintenance. Archival shifts all maintenance onto us. Any defect, compatibility break, or security finding requires a fork, a patch, and a release process — disproportionate for a convenience button. Unless the capability demonstrably saves editor time at scale, the maintenance cost likely exceeds the benefit, and the right answer is to replace or retire it.

Support. First-line support is near zero in the happy path; the burden concentrates at upgrade time. Every Statamic, Laravel, or PHP upgrade is a potential break with no vendor response. Record a standing exception naming the archived status, the pinned version, the owning team, and the trigger for retire-or-fork. Without that record, the exception becomes invisible debt.

Scaling. Per-request overhead is negligible — the action fires on click, not on render. The scaling concern is content-side: bulk duplication can silently inflate entries, asset references, and search indexes. Set a convention for when duplication is appropriate, and confirm the addon does not auto-duplicate on publish or schedule without explicit user action.

Failure modes.

• Install or upgrade failure once Statamic/Laravel/PHP move past the addon's constraints — the most likely long-run outcome, unrecoverable without a fork.
• Silent misduplication of relations, assets, or slugs — content that looks fine in the CP but breaks on the front end or in SEO.
• Permission bypass, letting an editor duplicate content they cannot edit.
• Multi-site leakage, where a duplicate lands in the wrong site or locale.
• Archive/security drift — a future advisory against the addon or a transitive dependency with no upstream remedy.
• Composer resolution surprise if archived package metadata becomes unavailable or a transitive dependency disappears from Packagist.

Ramp-up. Effectively zero for editors — it is a one-click action. Developer ramp-up is one to two hours to read the manifest, provider, config, and action classes, and to verify field-type coverage. The real cost is governance: version inventory, build-vs-adopt analysis, exception logging, and the eventual fork-or-retire call. Budget one engineer-day for assessment and pilot; treat fork-or-retire as a separately estimated effort if Phase 0 finds compatibility gaps.