Statamic Admin Log Laravel Package

Getting Started

This release (v1.1.0) is primarily a compatibility release: it adds Statamic 5 support. If you are still on Statamic 4, there is no urgent reason to upgrade unless you are planning a Statamic 5 migration. If you are already on Statamic 5, this is the version to use.

Minimal steps:

1. Confirm your environment meets Statamic 5 requirements (typically PHP 8.2+ and a compatible Laravel version).
2. Require the package with Composer: composer require vendor/package:^1.1.
3. Publish any package assets/config if the README instructs it: php artisan vendor:publish --provider="Vendor\\Package\\ServiceProvider".
4. Clear caches: php artisan config:clear, php artisan cache:clear, php artisan view:clear, and php please stache:clear if using Statamic’s Stache.
5. Verify the addon is registered and visible in the Statamic control panel under Addons.

Where to look first:

• README.md for installation and usage examples.
• The package’s composer.json to confirm the statamic/cms constraint includes ^5.0.
• The service provider to see what is registered (tags, modifiers, fieldtypes, events, permissions, etc.).
• The published config file, if any, for runtime options.

First use case: install the package, confirm it appears in the Statamic CP, then use its provided tag/modifier/fieldtype in a test entry or template. For example, if it provides an Antlers tag, add it to a template and confirm output in a local environment before rolling out to staging.

Implementation Patterns

Upgrade pattern for existing projects

• Bump the package to ^1.1 and statamic/cms to ^5.0 together in composer.json.
• Run composer update vendor/package statamic/cms --with-dependencies.
• Run any package migrations and re-publish config only if the release notes or README instruct you to.
• Smoke-test the control panel, frontend templates, and any custom fieldtypes or tags that depend on the package.

Day-to-day usage patterns

• Use the package’s tags/modifiers directly in Antlers or Blade where provided. Keep usage centralized in partials or components so future breaking changes are easier to isolate.
• If the package exposes fieldtypes, add them to blueprints through the CP. Test the fieldtype in a small blueprint first before applying it to production content models.
• If the package provides config-driven behavior, prefer environment-specific config over hardcoding values in templates.
• When the package emits events or exposes extension points, hook into those rather than modifying vendor code. This keeps upgrades to v1.1+ straightforward.
• For multi-site or team projects, pin the package version in composer.json and commit the lock file so all environments resolve the same Statamic 5-compatible version.

Integration tips

• Register any package-provided middleware, tags, or permissions in the service provider only if the package does not already auto-register them. Statamic addons often use auto-discovery, so check before duplicating registrations.
• If the package includes caching behavior, verify it respects Statamic’s static caching and multi-site context. Clear caches after configuration changes.
• Use Statamic’s testing helpers and Laravel’s test suite to assert that the addon boots correctly under Statamic 5. A simple test that resolves the package service provider and renders a template using its tag can catch most compatibility regressions.

Gotchas and Tips

• Statamic 5 is the compatibility target. The release notes only mention “Statamic 5 Support,” so treat v1.1.0 as the first version safe for Statamic 5 projects. If you are on Statamic 4, verify whether v1.1.0 still supports it before upgrading; if not, stay on the previous minor version.
• Clear caches after upgrading. Statamic’s Stache, config cache, and view cache can mask addon registration or config changes. Run php please stache:clear, php artisan config:clear, and php artisan cache:clear.
• Re-publish config carefully. vendor:publish can overwrite local config customizations. Compare the package’s default config with your published copy after upgrading, especially if v1.1.0 added new keys for Statamic 5.
• Check the Composer constraint. If the package allows both Statamic 4 and 5, Composer may not force the upgrade you expect. Explicitly require statamic/cms:^5.0 and the package ^1.1 in the root composer.json.
• Watch for deprecated Statamic APIs. Statamic 5 may deprecate or remove APIs used by older addon versions. If you see errors in the CP or logs after upgrading, check the package’s issue tracker and confirm you are on v1.1.0.
• Run migrations if present. Some addons add tables or columns. Check the package’s database/migrations directory and run php artisan migrate after upgrading.
• Debugging: enable APP_DEBUG=true locally, inspect storage/logs/laravel.log, and use php please commands to inspect addon registration. If the addon does not appear in the CP, confirm the service provider is auto-discovered or manually registered in config/app.php/bootstrap/providers.php as appropriate for your Laravel version.
• Extension points: prefer the package’s published events, config, and service provider bindings over monkey-patching. This is especially important when moving between Statamic major versions, because internal APIs are more likely to change than the package’s public extension points.
• Test in a staging environment first. Because this release is a framework compatibility update, verify frontend rendering, CP editing, and any queue/console commands that use the package before deploying to production.