Laravel Updater Laravel Package

Getting Started

Start with the package README and the Filament page registration; this package is primarily consumed through a Filament admin “Updates” page rather than a long-lived public API.

Minimal setup:

1. Install via Composer (composer require tomaszboloz/laravel-updater) and follow the package’s publish steps for config, migrations, and assets.
2. Register the Updates page/plugin in your Filament panel provider.
3. Run migrations if the package ships any.
4. If you use Filament Shield, install/enable it before or alongside this package; v3.3.0 adds a Shield permission for the Updates page.
5. Clear caches (php artisan optimize:clear, plus Shield/permission cache if applicable) and verify the page appears in the admin navigation.

Where to look first:

• config/ for the package config (permission key, page settings).
• The Filament page/plugin class to see how navigation and authorization are wired.
• Your panel provider to confirm the page is registered exactly once.

First use case: an administrator opens the Updates page, reviews available updates, and triggers the update flow from the UI. In v3.3.0+, if Shield is installed, access can be restricted to users/roles holding the package’s Shield permission.

Implementation Patterns

Filament panel integration

• Register the Updates page/plugin in the panel where update management belongs (often a restricted admin panel).
• Keep the page out of public panels; treat it as an operational tool.
• If you have multiple panels, register it only where intended to avoid duplicate navigation entries and permission confusion.

Shield permission workflow

• With Filament Shield installed, v3.3.0 exposes a permission for the Updates page.
• Assign the permission through Shield’s role UI or seed it into roles in your seeder.
• Use Shield’s standard role/permission management rather than adding a parallel authorization layer.
• The fix in v3.3.0 reads the Shield permission key through its facade, so ensure you are on 3.3.0+ if you rely on Shield-based access control.

Day-to-day operational pattern

• Use the page for on-demand checks and updates.
• If the package provides console commands, schedule checks in non-production or staging first, and surface results in the Filament page.
• Log or audit update actions (who ran them, when, and result) using your existing activity log or Laravel events if the package dispatches them.

Environment separation

• Restrict update execution to trusted roles and non-production environments by default.
• In production, consider a maintenance-window workflow: check availability in the UI, then execute through your deployment pipeline rather than ad-hoc UI clicks.

Gotchas and Tips

• Shield is optional, not required. If Shield is not installed, the permission integration should be skipped. Do not make Shield a hard dependency unless your app already standardizes on it.
• Permission cache is the usual culprit. After installing/upgrading Shield or changing roles, clear permission caches (php artisan permission:cache-reset for Spatie, and php artisan optimize:clear). A missing permission or a 403 on the Updates page is often stale cache, not a code bug.
• v3.3.0-specific: the permission key is resolved through the Shield facade. If you are pinning an older 3.3.x build or a fork, verify the facade-based read is present; otherwise permission resolution may fail silently or throw.
• Check the registered page name/permission key in config before assigning roles. Shield permission names are easy to mistype in seeders.
• Do not confuse Shield permissions with Filament policies. The page permission controls access to the Updates page; model policies control resource CRUD. They are separate layers.
• Avoid duplicate registration. Registering the page in multiple panel providers can produce duplicate navigation items and inconsistent authorization behavior.
• Production safety: the UI can be a powerful operational tool. Gate it to a narrow role, consider IP allowlisting or a separate admin panel, and prefer deployment pipelines for actual production updates.
• Extension point: if the package exposes a config key for the permission name or page visibility, override it in config/ rather than editing vendor files; republish config after upgrades if the package adds new keys.