Duplicator Laravel Package

Product Decisions This Supports

• Editorial velocity as a measurable line item. "Duplicate" removes a repetitive, error-prone task (re-keying a page or entry to create a variant). Before committing roadmap space, instrument it: if authors create N derivatives per week and each takes 10–20 minutes, the annual hours recovered are the business case. This package exists precisely to make that number visible cheaply.
• Feature parity / table-stakes assessment. Editors expect duplicate-and-edit in any modern CMS. This addon lets us answer "is this a real authoring pain point?" with a one-week pilot rather than a quarterly build. The result feeds the CMS investment decision either way.
• Build vs. buy (really: build vs. adopt). The capability is a small action in Statamic's Control Panel — a one-to-two-day in-house implementation with tests we control. The real decision is not "buy a feature" but "take a small, low-adoption dependency into a content-critical path." Low score (0.13), ~15 stars: treat the addon as a reference implementation and requirements spec first, and only then weigh it as a runtime dependency.
• Maintenance risk is now a moving target, not a fixed conclusion. The current release (v4.0.1) restores PHP 8.1 support, which reverses the earlier "archived / last release May 2023" read: the package is being patched and the maintainer is responding to compatibility issues. That materially weakens the "abandoned dependency" argument and shifts the burden of proof onto platform fit (Statamic major, PHP matrix) rather than liveness. We should re-verify status before quoting the prior assessment internally.
• Roadmap adjacency. Duplication is the thin end of a wedge that includes content templating ("start from this page"), seasonal/campaign page cloning, localization and multi-site variants, and staging-to-production content seeding. Piloting duplicate with authors tells us which of those to prioritize next and gives us a UX pattern to extend.
• Scope boundaries that shape the spec. What should not be copied — relationships, assets, child pages, entry URIs/slugs, publishing status, authorship — is a product decision, not an implementation detail. Getting it wrong produces duplicate URLs, orphaned relations, or accidentally-live drafts. Capture these as acceptance criteria regardless of build path.
• Governance signal. The package carries no audit trail or permission granularity. If editors duplicating live content is a compliance or brand-safety concern, that constrains the rollout to draft-only duplication with role gating — a policy decision we should make before, not after, launch.

When to Consider This Package

Consider it when:

• You are already running Statamic 3/4 and authors are actively asking for one-click duplication — the pilot value is real and immediate.
• You need a short-lived evaluation artifact: install in staging for a week to observe author behavior and quantify demand, then remove.
• You want a working specification: the field-copy semantics and configuration surface are a useful, MIT-licensed reference when writing our own action.
• Your Statamic and PHP versions fall inside the addon's declared support matrix. v4.0.1 explicitly re-adds PHP 8.1 support; PHP 8.2+ and Statamic 5 compatibility are not confirmed by the release notes and must be checked against the package's composer constraints before anyone installs it.

Look elsewhere (or build in-house) when:

• You are on a Statamic major that the v4 line does not declare support for. The PHP matrix is being actively adjusted, but Statamic version support is the constraint that actually breaks Control Panel actions.
• Duplication must preserve relationships, asset references, or multi-site/localization structure correctly. That logic is where these addons typically under-deliver and where silent data corruption is most expensive; it needs to be specified and tested by us.
• You need role-based permissions, audit logging, or draft-only enforcement around the action.
• You cannot absorb the migration cost of a v4 major bump. A patch that "adds back" PHP 8.1 support implies the v4.0.0 release narrowed the matrix — review the v4.0.0 changelog for breaking changes before treating this as a drop-in upgrade.
• This is a long-lived product and the capability is cheap to own. Revived maintenance lowers the risk premium but does not remove the dependency; a bus-factor-one package in a content-critical path is still a liability we can retire in ~1–2 engineering days.

Decision rule: the "archived, therefore never adopt" rule no longer holds. Use instead: adopt only behind a flag for a time-boxed pilot with a documented removal date, and only after confirming Statamic-major and PHP-version fit; otherwise replicate the behavior in-house.

How to Pitch It (Stakeholders)

To executives (one paragraph). Our authors currently rebuild pages and entries by hand whenever they need a variant — a seasonal landing page, a localized copy, a campaign refresh. This addon demonstrates a one-click fix, and we can validate demand with a cheap two-week pilot. Its maintenance picture has improved — a new release restores PHP 8.1 support, so it is no longer fair to call it abandoned — but it still has a very small user base and no confirmed support for our exact platform versions, and its compatibility matrix is being patched reactively. Recommendation: approve a small in-house build (~1–2 engineering days) that reproduces the capability under our own tests, using the addon as a reference. The upside is author hours recovered per month; the downside of the alternative is a single-maintainer package in a content-critical workflow whose compatibility we do not control.

To engineering. The behavior is narrow and well-understood: copy field values and content structure into a new entry from the Control Panel listing and page tree, with configuration to opt collections in. Treat it as a spec exercise first, dependency second. Verify two things before any install: the declared Statamic version range, and whether v4.0.0 introduced breaking changes that v4.0.1 only partially walks back. The parts that matter are the ones the release notes are silent on — relationship and asset re-linking, slug/URI uniqueness, published-status default, child-page handling, and multi-site behavior. Deliver as a first-party action with tests covering those cases, plus a permission gate so duplication of live content is deliberate. If we need a stopgap, install in staging only, behind a flag, with an agreed removal date.

To content/editorial leads. We hear that building a page from scratch to make a small variant is slow and error-prone. We are validating that with a small pilot before committing. In parallel, please send us the three or four real examples where you last rebuilt content manually — those samples will define exactly what a duplicate should and should not copy, so the shipped version matches how you actually work rather than how a package guessed.