Upgrading Public Forms from Filament 4 to Filament 5 and Livewire 4

A public form upgrade is successful when visitors can still render, validate, upload, navigate, and submit—not when Composer finally resolves. Filament 5 requires Livewire 4 and Tailwind 4, so the browser-facing behavior deserves its own migration plan.

FilaForms went through this transition. The durable lesson was to start with a compatibility gate and behavioral baseline, use the official upgrader, then review the public request path that automated rewrites cannot understand.

Confirm the platform gate

Filament 5 requires PHP 8.2+, Laravel 11.28+, Livewire 4+, and Tailwind CSS 4+. Audit every Filament plugin before changing constraints; the official upgrade guide warns that third-party packages may not yet support the new major.

Record the current application and lockfile, run dependency/security audits, and establish a passing focused test suite. Do not begin from a broken baseline.

Capture public-form behavior first

Your pre-upgrade tests should cover:

• anonymous public GET;
• required, email, select, and nested validation;
• conditional visibility and live bindings;
• multi-step forward/back navigation;
• local and S3-compatible upload flows;
• invalid and valid submission;
• double-submit/loading behavior;
• queued notification dispatch;
• authenticated submission administration;
• mobile viewport and JavaScript console smoke checks.

Take query/payload timings if performance matters. A passing migration can still regress Livewire payload size or upload rate limiting.

Run the official upgrader, then review

The documented sequence begins with Filament's temporary upgrade package and vendor/bin/filament-v5, followed by the Composer commands it prints. Treat its output as a proposed patch, not an authority on application semantics.

Review namespace and schema changes, published views, custom components, plugins, Tailwind sources, and JavaScript hooks. Rebuild frontend assets and clear application caches after dependency changes.

Check Livewire 4 behavior that forms depend on

The Livewire 4 upgrade guide includes several public-form traps:

• component tags must close explicitly because slots are supported;
• child wire:model events no longer bubble by default; use .deep only intentionally;
• .blur and .change synchronization semantics changed; .live.blur or .live.change retains network updates where required;
• old wire:transition modifiers were replaced by the View Transitions API;
• navigate scroll persistence uses wire:navigate:scroll;
• update endpoints include an APP_KEY-derived hash;
• custom update-route handlers must preserve the generated path;
• file uploads are chunked/resumable by default;
• older JavaScript request/commit hooks are deprecated.

Search the application for each affected directive and hook, then exercise it in a browser. A static text replacement cannot decide whether model bubbling was actually intended.

Update standalone Filament form patterns

Filament 5 standalone forms use the schema APIs: Schema, HasSchemas, InteractsWithSchemas, a form(Schema $schema) method, statePath(), fill(), and getState().

Old examples built around earlier Form, HasForms, and InteractsWithForms APIs should be rewritten before being copied into production. Verify custom components and action namespaces against the installed version.

Protect the new endpoints and uploads

If a CDN, WAF, reverse proxy, or monitoring rule expects /livewire/update, it may reject Livewire 4's hashed endpoint. Update exact-path rules without allowing arbitrary new routes.

Chunked uploads create many requests. A throttle designed for one upload request can block legitimate files mid-stream. Recalculate request limits, test abort/retry behavior, and configure S3 lifecycle cleanup for incomplete multipart uploads. The upload security guide covers content and storage controls that version upgrades do not solve.

Verify queues and cached artifacts

Restart queue workers so they load new code. Confirm serialized jobs/events remain compatible or drain old jobs before deployment. Rebuild production assets, recache configuration/routes/views where used, and verify published package views do not shadow updated vendor templates unexpectedly.

Run composer audit, static analysis, the focused Pest suite, and real browser tests. A server-side feature test will not catch a missing asset or JavaScript directive regression.

Roll out with a canary

Use a staging copy with production-like storage and queue configuration. Then expose one low-risk public form, monitor Livewire errors, validation failures, upload errors, submission counts, queue failures, and response time before expanding.

Keep the previous release artifact and database compatibility plan ready. If a migration is destructive, rollback becomes an application/data project rather than a deployment switch.

What to document after the upgrade

Record exact package versions, plugins replaced, automated edits reviewed, manual fixes, asset/WAF changes, and the browser matrix. This becomes the next upgrade's baseline and makes “works on my form” evidence reusable.

Our public Filament form guide reflects the schema-versus-lifecycle architecture after the upgrade. The FilaForms architecture article explains why public rendering exercises more than the admin panel.

The safest sequence is straightforward: inventory, baseline, upgrade, review, browser-test, canary, observe. Composer resolution is a milestone in that sequence—not its definition of done.