Locale Lander Laravel Package

Getting Started

This release is a compatibility release: v3.3.0 adds Statamic 6 support. There is no new feature surface to learn, so the first job is verifying that your application and this addon are on compatible versions.

1. Check constraints before upgrading. Confirm the package’s composer.json accepts the Statamic version you run. A typical constraint should look like "statamic/cms": "^5.0|^6.0"; if it only allows one major, you may be forced onto a specific Statamic line.
2. Install/upgrade:

   composer require vendor/package:^3.3
   

   If the package publishes config or assets, republish and diff rather than overwrite:

   php artisan vendor:publish --provider="Vendor\\Package\\ServiceProvider"
   

3. Clear caches after upgrading, especially Statamic’s:

   php artisan config:clear
   php artisan cache:clear
   php artisan view:clear
   php artisan statamic:stache:clear
   

4. First place to look: the package README and its service provider (src/ServiceProvider.php). For a Statamic addon, that is where bootstrapping, tags, fieldtypes, and CP routes are registered.
5. First use case: open the Statamic control panel, confirm the addon’s fieldtype/tag/widget appears where expected, and exercise one existing content entry or Antlers template that uses it. That validates the upgrade path without needing to understand every feature.

Implementation Patterns

• Auto-discovery: Statamic addons are normally discovered via Composer. After install, confirm the addon is listed in the CP addons area and that its service provider boots without errors.
• Feature entry points: Depending on the package, day-to-day usage will be through one or more of:
  • a fieldtype added to a blueprint (edit the blueprint YAML and select the fieldtype);
  • an Antlers tag or modifier used in templates, e.g. {{ package_tag }};
  • a CP nav item / utility / widget registered by the addon;
  • config-driven behaviour in config/package.php.
• Bootstrapping pattern: Statamic-specific registration generally belongs inside Statamic::booted(...) or the addon’s service provider boot() method, not in register(). Follow the package’s existing conventions rather than moving registrations around.
• Configuration over code: publish the config file and commit it. Use environment variables for environment-specific values so staging and production do not diverge.
• Testing: use Statamic’s testing helpers (Statamic::fake(), addon test cases) where available. If you maintain custom tests, run the suite against both Statamic 5 and 6 if the package supports both.
• CI matrix: if your application is mid-upgrade, install this release in a branch and run the full suite before merging. The meaningful risk is not the addon’s API, but interaction with Statamic 6/Laravel platform changes.

Gotchas and Tips

• “Statamic 6 support” can mean dropped Statamic 5 support. Inspect the Composer constraint. If v3.3.0 moved from ^5.0 to ^6.0, that is effectively a breaking change for applications still on Statamic 5. Pin to the last 3.2.x release if needed.
• Platform requirements move with Statamic majors. Statamic 6 may require a newer PHP/Laravel baseline. Verify your runtime before upgrading; Composer will usually catch this, but Docker images and CI images often lag.
• Clear the Stache after any Statamic upgrade. Stale Stache indexes are a common source of “the fieldtype/tag exists but nothing renders” behaviour:

  php artisan statamic:stache:clear
  php artisan statamic:stache:warm
  

• Republish config and migrations, then diff. Blindly running vendor:publish --force can overwrite local customisations. Publish to a temp location or review the diff.
• Check for deprecated APIs in logs. After upgrading, exercise the addon’s CP screens and front-end templates with APP_DEBUG=true and review storage/logs/laravel.log for deprecation notices from Statamic 6.
• Antlers and Blade rendering can change across Statamic majors. If the addon ships templates, verify output on the front end, not just in the CP.
• Extension points to inspect: the package’s events, hooks, and any custom tags/modifiers. These are the safest integration seams if you need to customise behaviour without forking.
• Debugging checklist: confirm the service provider is discovered (php artisan about / package discovery output), confirm config is published and cached correctly, clear caches, then isolate by disabling other addons. Most “it stopped working after upgrade” reports are cache or version-constraint issues rather than addon logic.
• Treat this as a maintenance release. There are no new features to adopt; the correct action is a compatibility validation pass, not a feature rollout.