Duplicator Laravel Package

Getting Started

1. Install. composer require doublethreedigital/duplicator — Statamic addons are auto-discovered through the extra.statamic block in the package's composer.json, so no manual provider registration is normally needed on Statamic 3/4.
2. Pin the exact version. Use "doublethreedigital/duplicator": "4.0.1" rather than a caret range. v4.0.1 is the last release (2023-05-10) and is the version that restores PHP 8.1 support — if you're still on PHP 8.1, you must be on 4.0.1 exactly, because earlier 4.x builds required a newer PHP.
3. Publish the config (if a config tag ships with the version you pin). Run php artisan vendor:publish --tag=duplicator-config (verify the tag in the package's README; tags differ between addons). Skip this if you're fine with the default "all supported collections" behavior.
4. Clear caches. If the action doesn't appear, run php artisan statamic:stache:clear and php artisan cache:clear. Statamic's Stache caches collection/tree metadata and a stale cache is the most common reason a new CP action is invisible.
5. Where to look first.
   • Collections → any non-singleton collection listing → row actions (…) menu → look for Duplicate.
   • Pages / structured collections → the page tree → context menu → Duplicate.
6. First use case. Build a "master" page or entry once (hero, sections, SEO scaffolding), then use Duplicate from the page tree to spin up a new landing page. Rename the slug, edit the copy, publish. This is the highest-value day-to-day pattern: it replaces "create blank page and rebuild every Replicator set."

Because the package is archived (last release 2023-05-10) and the only post-archival maintenance has been a PHP 8.1 compatibility fix, treat the first install as a spike: confirm it works with your pinned Statamic/PHP versions before rolling it out to a team.

Implementation Patterns

Template-based content authoring. Keep one canonical "page template" per layout in a dedicated collection (or hidden from navigation). Editors duplicate it, rename, and fill in copy. This is the workflow the addon is designed for and the one that saves the most time.

Iteration on published content. Duplicate a live entry, make changes in the copy, then swap statuses. Use the duplicate as a staging draft so the live page is never edited in place. Pair this with Statamic's revisions for auditability.

Seasonal / campaign variants. Duplicate last quarter's landing page, update dates and copy, publish. Because field values (including Replicator/Grid structures) are copied, campaign pages that differ only in text are a few clicks instead of a rebuild.

Scoping the action to the right collections. Restrict duplication to collections where a shallow copy makes sense (pages, editorial entries, banners). Disable it for collections heavy in entries/assets relationships or singleton-style config, where a duplicate will silently point at the original's relations.

Structured collections. Duplicates in tree-enabled collections typically land as siblings or at the root depending on the version — after duplicating, drag the new page into position in the tree. Expect to do this manually rather than relying on inherited parentage.

Permission gating. Because the action maps to Statamic's Action API, it respects the user's create permission on the underlying collection. Use this to expose duplication to editors but not to restricted roles. Test with a non-super user before relying on it.

Complement with programmatic duplication. If you need scheduled, bulk, or API-driven duplication, don't try to trigger the CP action — write an Artisan command using Statamic's Entry API (Entry::make() plus copying data()) inside your own app code. The addon is CP-only by design.

Multisite. Verify whether a duplicate is created in the current site only or propagated to all sites. If per-site, use duplication for site-local variants; if propagated, be careful about which site's content you're editing afterwards.

Gotchas and Tips

• Archived and unmaintained. Pin the exact version in composer.json (e.g. "doublethreedigital/duplicator": "4.0.1"), not a caret range, so a future Composer resolve can't surprise you. Check the addon's composer.json for a Statamic constraint that blocks a Statamic 5 upgrade before you plan one.
• PHP 8.1 requires 4.0.1. v4.0.1 exists solely to add back PHP 8.1 support. If you're on PHP 8.1, earlier 4.x tags will fail composer install on the platform check; don't "downgrade to fix a bug" without re-checking your PHP constraint. Conversely, this release changes nothing at the PHP 8.2+/8.3 level — no API, config, or behavior changes to test against.
• Action not showing up. 90% of the time it's a stale Stache or the collection type being unsupported (singletons, taxonomies, globals won't get a duplicate action). Clear the Stache, then confirm the collection is a plain entries collection or a structured/page collection.
• Slug collisions. Duplicates get a generated slug (often original-1). If your project stores redirects, sitemap entries, or cross-links by slug, update them or you'll ship a duplicate that's orphaned from your navigation.
• Draft status surprise. New copies are frequently created as drafts. Editors who duplicated a published page and expected it live will be confused — either document this or add a "Duplicate & publish" step to your editorial workflow.
• Shallow copy, not deep clone. Replicator/Grid field data is copied by value, but related entries/assets/terms fields still reference the originals. If your duplicate needs independent relations, plan to re-pick them manually.
• Revision history resets. The duplicate starts with a fresh revision history — you don't get a link back to the original's revisions. If auditability matters, note the source entry ID in a field or a comment before duplicating.
• Static caching. If you use Statamic's static cache, a duplicated-and-published entry may not show until the cache is warmed or invalidated. Build a cache-clear step into the "duplicate then publish" workflow.
• Permissions edge cases. Confirm with a restricted role that the action is hidden or rejected when the user lacks create rights. The Action API should enforce this, but always verify against your role setup rather than assuming.
• Extension point if you need to change behavior. Because it's a Statamic Action, the cleanest long-term path — given the package is archived — is to copy the action class into app/Actions/** and register it as your own. That gives you control over slug format, default status, and auto-populated fields without carrying an unmaintained dependency.
• Low adoption signal. 15 stars, an archived repo, and a maintenance release that touched only a PHP constraint mean few people are exercising edge cases (multisite, Statamic version bumps, permission combinations). Budget time for your own testing and treat bugs as something you'll fix locally rather than upstream.