An admin panel upgrade is complete when editors can reliably finish their work. Installing the new dependencies is one part of that change. The rest is proving that a user can sign in, find a record, edit it, upload a file, and save the intended result with the correct permissions.
Filament’s January 2026 announcement explains that the v5 release introduced Livewire 4 support. At launch, that integration was the difference from v4. For an existing application, custom Livewire behavior therefore deserves particular attention.
The Filament 5 upgrade guide lists PHP 8.2+, Laravel 11.28+, Livewire 4+, and Tailwind CSS 4+ as requirements. Other application dependencies may impose higher minimums. Review the complete Composer graph rather than treating one package’s minimum as the application’s target.
composer show filament/filament
composer show livewire/livewire
composer prohibits filament/filament '^5.0'Inventory panel plugins and custom integrations before changing constraints. For each plugin, record the installed version and the maintainer’s declared compatibility. When a required plugin blocks the upgrade, resolve that dependency explicitly. Removing a feature changes the product and should be a deliberate decision.
From a committed working tree, the documented starting commands are:
composer require filament/upgrade:"^5.0" -W --dev
vendor/bin/filament-v5Follow the commands that the script prints for your application and review the resulting changes. The guide also directs applications with custom Livewire code to the Livewire upgrade guide. Finish dependency resolution and asset compilation before opening the panel for verification.
For a course platform, use an article with rich content, a course with several episodes, and an account with restricted access. These examples exercise different parts of the panel and are easier to reason about than clicking through every navigation item without a purpose.
Create a draft article, add formatted text and a link, save it, reopen it, and compare the persisted content.
Edit an existing public article without changing its slug; confirm its public URL still resolves to the same record.
Reorder course episodes, reload the editor, and confirm the public course follows the saved order.
Upload an image, save the record, and open the resulting image URL from a separate browser session.
Sign in as a restricted user and try both ordinary navigation and direct URLs for protected records.
Verify outcomes in the persisted record as well as the interface. A successful toast can coexist with an omitted field, a stale relationship, or an upload that points to a disk unavailable to the web server. Compare the public page with the editor whenever both render the same content.
Capture the panel at desktop width and at a narrow viewport. Include an open action modal, a validation error, a long table row, and the rich editor. Check that primary actions remain visible and keyboard focus follows the interaction. Use the same sample record before and after the upgrade so differences are easy to inspect.
For permission checks, pair the screenshots with automated assertions around the policy or protected action. Hiding a button improves the interface, but the server must still reject an unauthorized operation. A screenshot proves what was displayed; an authorization check proves what the account was allowed to do.
Repeat the critical editing workflow after deployment using the production asset build. Inspect browser errors and failed requests while opening forms and saving changes. Record the deployed revision beside the screenshots so that the evidence refers to the version editors will use.
Keep the upgrade report short and specific: dependency versions, workflows completed, records checked, and any unresolved failure. That makes the result useful to the next person maintaining the panel and gives you a clear boundary for what has actually been verified.