- How do I install Vesper in a Laravel Filament application?
- Run composer require suraj-kashyap-dev/vesper, then register the plugin on your panel inside the PanelProvider using $panel->plugin(VesperPlugin::make()). The integration surface is limited to Composer and PanelProvider files, so there are no migrations, service providers, or storage changes to manage. Once the plugin is registered you can start configuring theming through the fluent API.
- Which Filament and PHP versions does Vesper 2.0 support?
- Vesper 2.0 is shipped as a Filament panel plugin, so its Composer constraints track a specific Filament major and PHP version. The release note does not spell out the constraint diff from 1.x, so compare the require block in composer.json for both versions before upgrading. Confirm compatibility in a branch against your installed Filament version rather than assuming it carries over.
- How do I migrate from the Vesper 1.x config file to the 2.0 fluent API?
- Every previously published config key maps one to one onto a fluent method on VesperPlugin: preset, branding, header, sidebar, fonts, colors, tokens, and layout. Translate the values from config/vesper.php into chained calls in each PanelProvider, then delete the migrated keys or remove the file entirely. Do it one panel at a time and run a visual regression pass before merging.
- Is config/vesper.php still supported in Vesper 2.0?
- Yes, but only as a transitional fallback layer that sits beneath the fluent calls, which keeps existing 1.x installs rendering after the upgrade. The nested config/vesper/tokens.php and config/vesper/presets files are removed and ignored in favor of package-owned theme data. Treat the fallback as temporary and remove the file once everything is configured fluently, otherwise you maintain two sources of truth.
- Why did my custom tokens and presets stop applying after upgrading Vesper?
- In 2.0 the presets and tokens config files are removed and ignored; theming now resolves from package-owned src/Theme classes and the active plugin. If you customized those files in place, the values are dropped silently, so the panel renders defaults with no error raised. Re-implement the customizations through tokens() fluent calls or a custom preset class instead of editing package config.
- Do I need to republish or edit my Blade overrides after upgrading to Vesper 2.0?
- Published Blade views and TopbarNavigation now read branding, header, and sidebar from the active plugin instead of config('vesper.*'). Any locally published or forked view that reads config('vesper.*') directly will silently render defaults or blanks. Diff your overrides against the package versions and replace those reads with VesperPlugin::current(); if you never customized the views, no action is needed.
- How does Vesper behave with multiple Filament panels?
- VesperPlugin::current() implies awareness of the active panel, so branding and theming resolve against whichever panel is rendering. Behavior for mixed registration, where some panels use the plugin and others do not, is not documented in the release notes. Configure each panel explicitly in its own PanelProvider and test every panel rather than relying on a single global setup.
- Can I create my own custom theme preset in Vesper 2.0?
- Yes. Version 2.0 introduces a Preset contract and an AbstractPreset base class as a public extension point so presets live as versioned, testable classes instead of copied config arrays. Extend AbstractPreset, register it, and add a test that confirms precedence between your preset and any tokens() calls. Contract stability across the 2.x line is not yet proven, so pin the version and review changes when upgrading.
- Does Vesper add database tables, migrations, or runtime overhead?
- Vesper is a presentation-layer package for Filament panels, and the release implies no database, queue, or storage footprint. Integration is a Composer dependency plus PanelProvider edits, which keeps the blast radius small and rollback cheap. Any runtime cost is confined to theme resolution and asset loading during rendering, and themeAsset and themeId are the entry points worth verifying in your environment.
- How do I roll back if Vesper 2.0 breaks my panel?
- Because the integration is limited to Composer and PanelProvider files, reverting means re-requiring ^1.0 and restoring the config-driven theming. Version 1.x is not described as end-of-life, so it remains a valid short-term option while you audit published views and config. Land the migration as a single PR so the revert is one clean step.