Statamic Entries Export Laravel Package

Getting Started

This release (2.1.1) is the one that makes the package usable on Statamic 5. If you are still on Statamic 4, nothing here changes for you — 2.1.1 is additive, not breaking. If you are planning a Statamic 5 upgrade, this is the release that unblocks it.

First steps:

1. composer require <vendor>/<package>:^2.1 — pin to ^2.1 rather than * so you get the Statamic 5 compatibility branch.
2. Check the resolved matrix before writing code:

   composer show <vendor>/<package>          # confirm the installed version
   composer why-not statamic/statamic ^5.0   # surfaces any addon still holding you back
   

3. Publish config/assets if the package ships them:

   php artisan vendor:publish --provider="<Vendor>\<Package>\ServiceProvider" --tag=config
   

4. Warm everything back up: php artisan config:clear && php artisan statamic:stache:clear.

Your first real use case is almost certainly the thing you were already doing on Statamic 4 — a fieldtype, tag, modifier, or middleware hooking into Statamic's content pipeline. Since 2.1.1 is a compatibility patch, the public API on the Laravel side is unchanged; the work is in getting the surrounding app onto Statamic 5's requirements (PHP 8.2+, Laravel 10 or 11).

Implementation Patterns

Treat 2.1.1 as the version floor, not the target. In composer.json, require "<vendor>/<package>": "^2.1" alongside "statamic/cms": "^5.0". Because Statamic 5 requires PHP 8.2+ and Laravel 10/11, your CI matrix should be updated in the same PR that bumps this package — otherwise you'll get green builds on PHP 8.1 that can't actually install the dependency graph.

Upgrade path for existing installs. The realistic sequence:

composer require <vendor>/<package>:^2.1 --with-dependencies
php artisan statamic:upgrade        # if you're crossing the Statamic 4 -> 5 boundary
php artisan migrate
php artisan statamic:stache:clear
php artisan statamic:static:clear

Then run the full test suite. Feature tests that boot Statamic are the ones that catch breakage; unit tests that mock the package's classes usually won't.

Pin the addon in your own addon, if you maintain one. If your package depends on this one, widen the constraint (^2.0|^2.1) rather than hard-pinning, or you'll propagate a conflict to every consumer still on Statamic 4.

Test against both majors if you support both. A two-entry GitHub Actions matrix — Statamic 4 on Laravel 10, Statamic 5 on Laravel 11 — is the cheapest way to honour the "supports both" claim this release implies. Use --prefer-lowest on at least one leg.

Wire it into the content layer, not around it. The idiomatic integration point is a Statamic addon ServiceProvider registered through Statamic::booted() / Statamic::afterInstalled(), with the package's facade or bindings resolved from the container inside tags, modifiers, and fieldtypes. Keeping the package's services behind its published config means the Statamic 5 transition is a composer change, not a code change.

Gotchas and Tips

• A 2.1.1 in an addon's release notes does not mean your whole app is Statamic-5-ready. This release cleared this package's blocker. composer why-not statamic/statamic ^5.0 will show you the remaining ones; expect a handful.
• Cache is the number-one false alarm. After upgrading, a stale Stache or config cache mimics breakage — missing fields, blank templates, old behaviours. Clear stache, cache, config, and view before you start debugging code.
• Watch for composer.lock drift across environments. Bumping an addon on your machine and not committing the lock file produces the classic "works locally, 500 in staging" on an unrelated-looking class.
• Check the package's composer.json requirements directly rather than trusting the release note. The supported-Statamic range and supported-Laravel range are the ground truth; if it declares statamic/cms: ^4.0|^5.0 you're safe on both sides.
• Static caching and multi-site are the usual regression surfaces. If the package touches content resolution, test on a multi-site install after upgrading — Statamic 5 didn't change the shape of these APIs much, but addons that cached resolved data across sites historically broke here.
• Extension points are the safe place to customise. Prefer the package's published config and container bindings over subclassing its internals; internals are exactly what a major-Statamic compatibility release may have adjusted.
• Report breakage upstream with versions pinned. If something fails only on Statamic 5, an issue containing composer show output for the package and statamic/cms gets fixed far faster than "it's broken on v5".
• Don't assume the next patch is also additive. This release happened to be non-breaking. Read the changelog for each 2.x bump before composer update in a production branch.