Weave Code
Tomato Plugins Laravel Package
tomatophp/tomato-plugins
Tomato Plugins is a Laravel plugin manager for the TomatoPHP ecosystem, letting you install, enable, disable, and organize modular plugins from a single dashboard so you can extend your application with reusable features without touching core code.
Plugins installer for Tomato PHP framework
Frequently asked questions about Tomato Plugins
- How do I install tomatophp/tomato-plugins in a Laravel application?
- Install it with composer require tomatophp/tomato-plugins, then publish the package config so plugin paths and namespaces are registered, and let the service provider's auto-discovery take over. The package is an application composition layer rather than a feature library, so there is no per-feature wiring to do by hand. Check the composer.json constraints before installing to confirm it supports your Laravel and Filament majors.
- How does plugin discovery and registration work in this package?
- Plugins are discovered through their own service providers, which the package registers automatically so each plugin's routes, views, migrations, translations and Filament resources boot with the application. You do not edit core code or maintain a central manifest to add a module. Because discovery is provider-driven, a plugin that fails to boot shows up as an application-level error rather than an isolated broken widget, so stage new plugins before production.
- Can I enable or disable a plugin without deploying new code?
- Yes. The package exposes per-plugin enabling and disabling through Artisan commands and a manager API, and in TomatoPHP setups through the admin dashboard. That lets you switch feature sets at runtime instead of shipping a new build. Decide in writing up front whether disabled means a reversible feature flag or a one-way door, because that choice dictates how you treat the plugin's data.
- What happens to a plugin's database tables and data when I disable it?
- The package documents enable, disable and removal workflows but does not impose a data-retention policy for you, so treat it as a product decision to settle before launch. Typically disabling stops the plugin's providers, routes and migrations from loading while already-migrated tables stay behind as orphans. If removal workflows drop tables or seeded data, confirm the exact behaviour in the source before any non-engineering user touches the toggle in production.
- Does tomatophp/tomato-plugins work with config:cache, route:cache and artisan optimize?
- Auto-discovered migrations, routes and assets are a known failure point under config:cache, route:cache and php artisan optimize, so run a full caching pass with plugins both enabled and disabled. Some plugins ship their own cached manifests or need a rebuild step after toggling. Treat cache clearing as part of every enable or disable operation in your deployment runbook.
- Which Laravel and Filament versions does this plugin manager support?
- The supplied package information does not state explicit version constraints, so read composer.json and the release history before committing. Treat any support claim as binding only when it is enforced in composer.json rather than merely implied by the README. If you rely on plugins registering Filament resources, pin the Filament major version you actually validate against.
- Is tomatophp/tomato-plugins safe to run in a production Laravel application?
- It is a pre-2.0 package with a single maintainer and a small adoption footprint, yet it changes how your application assembles itself, so a defect surfaces as a broken deployment rather than a broken widget. Pin an exact version, review the tagged source you intend to install, and confirm the release artefact matches the package you evaluated. For anything beyond an internal pilot, plan a fork or vendored copy you control.
- Can plugins be installed from a remote source, and does that create a supply-chain risk?
- The overview describes installation and removal workflows for third-party plugins but does not say whether plugins are fetched remotely or only loaded from directories already on disk. If installation can fetch or execute external code, you inherit a supply-chain boundary that must be reviewed before a non-engineering user can install anything. Restrict installation to vetted directories or an internal registry if remote sources cannot be verified.
- Does it work with multi-node deployments, read-only filesystems and queue workers?
- Discovery runs at boot in every process, so each web node and each queue worker must see the same plugin directories and the same enabled state. If enabled state lives in the database all nodes agree, but a toggle only takes effect at the next boot or cache clear; if it lives in config, you need it reproducible across dev, staging and production. Read-only filesystems are fine for loading but break any workflow that writes plugin manifests, so verify before containerising.
- What alternatives should I consider instead of a runtime plugin manager?
- If your roadmap is a single deployment with one feature set, plain Composer packages, Laravel package discovery and feature flags already give you modularity without adding a second lifecycle for code. nwidart/laravel-modules is the more established option for module organisation, and Filament's own plugin and panel registration covers many admin-extension cases. Choose a runtime plugin manager only when you genuinely ship variable feature sets such as tiers, per-client add-ons or per-tenant capability sets.
Weaver
How can I help you explore Laravel packages today?