Weave Code
Tomato Forms Laravel Package
tomatophp/tomato-forms
Tomato Forms is a form builder for TomatoPHP and Filament that lets you create dynamic, database-backed forms and manage submissions from your admin panel, with reusable field components so you can add custom forms to any Laravel app without boilerplate.
Tomato Forms is a dynamic form builder for Laravel and Filament applications, part of the TomatoPHP ecosystem. It lets you define forms and fields visually, render them anywhere in your app, and collect submissions without writing repetitive boilerplate.
- Visual form and field builder with drag-and-drop ordering
- Wide range of field types (text, select, date, file, and more)
- Built-in submission storage, listing, and management
- Seamless Filament resource integration
- Extensible architecture for custom fields and validation rules
Frequently asked questions about Tomato Forms
- What is tomatophp/tomato-forms and what does it do?
- Tomato Forms is a dynamic form builder plugin for Laravel and Filament, part of the TomatoPHP ecosystem. It lets you define forms and fields visually with drag-and-drop ordering, render them in your app, and store and manage submissions from a Filament admin panel. It ships migrations, a config file, and two Filament resources, and is MIT licensed. It is a capture and rendering layer rather than a system of record.
- How do I install Tomato Forms in a Laravel application?
- The install path is short and standard: run composer require tomatophp/tomato-forms, publish the config and migrations, run php artisan migrate, then register the plugin in your Filament panel provider. Before installing, check the filament/filament constraint in the package's composer.json against your current major. Pin an exact version such as 1.1.19 and commit the lock file rather than using a floating constraint.
- Does Tomato Forms support Filament v4?
- Probably not. The package is a Filament v3 plugin and its last release was May 2024, which predates Filament v4. Treat it as incompatible with v4 until a spike proves otherwise. Read the filament/filament constraint in composer.json before starting any install work, and expect fork effort if you are already on a newer major.
- How are form submissions stored - do they create new database columns?
- No. Answers are written as key/value rows against the user record in a user meta table rather than as new schema columns, which is the core value of the package for config-driven, admin-authored capture. That design also means there is no schema versioning: renaming or retyping a field leaves historical submissions unmappable to the current definition. Plan accordingly if you ever need reporting or billing-grade data.
- Can I add custom field types to Tomato Forms?
- Yes. The package is described as extensible for custom fields and validation rules, and the surface is small enough to read end-to-end in an afternoon. In practice you will be extending field classes and their views inside your own fork, so budget for that work. Keep the fork diff small and documented, since upstream should be treated as a starting point rather than a merge target.
- Is per-field validation enforced on the submit endpoint?
- Validation is stored as JSON configuration per field, not as a database constraint, so do not assume it is enforced server-side until you have proven it is. Audit the submit path on day one and confirm the payload is whitelisted against the current form definition. If validation is missing or partial, add it in your fork before exposing any form to real users.
- Can I render and submit a Tomato Forms form outside the Filament admin panel?
- The package is built as a Filament v3 plugin with admin resources, and the docs do not confirm a non-panel render or submit route. If you need front-end or customer-facing forms, assume you own the Blade renderer and the submit endpoint. That integration work is usually the bulk of the effort, so scope it before committing.
- What happens to stored submissions when I delete a form or field?
- There is no documented cascade or cleanup on form or field deletion, so deleting a definition will almost certainly strand meta rows with no removal path. Write a cleanup job and audit the meta namespace before going live. Also decide in writing whether user meta is a staging area or the system of record; if it is the latter, add a typed submissions table now, before responses accumulate.
- How does Tomato Forms handle file uploads?
- File upload behaviour is largely undefined in the package: disk, storage path, retention policy, and MIME validation are all open questions. Expect to implement most of this yourself in your fork. Add MIME whitelisting, size limits, private disk storage, and a deletion path for orphaned files.
- Is Tomato Forms actively maintained and safe to use in production?
- It has zero stars, zero dependents, a single maintainer, and a last release in May 2024, so treat it as dormant and plan to fork and own it under MIT. Watch specifically for silent data loss from unprefixed field keys colliding in a shared user-meta namespace, and for stored XSS if labels, help text, or option text are rendered unescaped. Pin the exact version, lock the file, and if that risk profile is unacceptable, a small in-house builder or a actively maintained form builder package may be the better fit.
Weaver
How can I help you explore Laravel packages today?