Filament Open Hours Laravel Package

Getting Started

Treat 3.0.0 as a Filament 5.x compatibility major. Confirm your application is already on Filament 5.x before requiring it; if you are still on Filament 4, stay on the previous package major.

Minimal setup:

1. Check the package README/UPGRADE notes and the Filament 5 upgrade guide for renamed namespaces, panel registration changes, and asset commands.
2. Require the new major explicitly:

   composer require vendor/package:^3.0
   

3. Register the package plugin in the relevant Filament panel provider. The exact method depends on the package, but it will typically be one of:

   ->plugin(PackagePlugin::make())
   // or
   ->plugins([
       PackagePlugin::make(),
   ])
   

4. Publish and review any config, migrations, views, or assets the package exposes. Publish tags may have changed in v3, so check the service provider or docs rather than assuming v2 tags still exist.
5. Run migrations if applicable, then rebuild Filament assets:

   php artisan migrate
   php artisan filament:assets
   

6. Smoke-test one panel page, one resource list/create page, and one package-specific widget or action before rolling out to all panels.

First use case: register the plugin on a non-production panel, open a Filament resource that uses it, and verify the package’s primary UI surface renders and persists data. That gives you a quick signal on Filament 5 compatibility before doing a wider upgrade.

Where to look first:

• Package README, UPGRADE.md, and CHANGELOG.
• The package service provider for publish tags and registration behavior.
• Your PanelProvider for plugin registration and panel discovery.
• Filament 5 upgrade notes for breaking changes that affect the package’s UI, actions, forms, tables, or Livewire components.

Implementation Patterns

Pin the compatibility track. Use ^3.0 only on Filament 5 applications. Keep Filament 4 applications on the previous major and upgrade Filament first, then the package. Avoid floating constraints during the transition.

Register per panel, not globally by default. If the application has separate admin, staff, or tenant panels, register the plugin only on panels that need it. This limits blast radius and makes it easier to test Filament 5 behavior incrementally.

Keep package configuration publishable. Publish config into config/ and override per environment rather than editing vendor files. If the package exposes extension points such as custom views, themes, navigation items, or actions, prefer those over subclassing internals.

Integrate through Filament primitives. Use the package’s resources, pages, widgets, actions, or form/table components inside normal Filament resources and pages. Keep business logic in your own actions/services and let the package own presentation and panel integration.

Test the panel integration, not just the package. Add at least one Livewire/Filament test that boots the panel, loads a page using the package, and asserts the expected component or data is present. This catches registration and namespace issues that unit tests miss.

Handle deployment as a Filament release. In CI and deploy scripts, include asset rebuilds, config/route/view cache refreshes, and migrations where applicable. A package major that targets Filament 5 can fail at runtime if cached panel components or stale assets remain.

Use a short compatibility matrix. Track application Filament version, package major, PHP version, and asset build step. Filament majors often move together with Livewire/Tailwind expectations, so document the supported combination.

Gotchas and Tips

• This is a major-version compatibility release, not a drop-in feature update. Do not assume v2 configuration, publish tags, plugin registration, or namespaces carry over unchanged. Read the upgrade notes before changing composer.json.
• Filament 4 applications should not force this upgrade. If composer why-not vendor/package 3.0.0 shows a Filament constraint conflict, resolve the Filament upgrade first rather than overriding constraints.
• Clear caches aggressively after upgrading. Filament caches panel components and Laravel caches config/routes/views. Run the relevant clear commands and rebuild assets when behavior looks stale.

  php artisan config:clear
  php artisan route:clear
  php artisan view:clear
  php artisan filament:clear-cached-components
  php artisan filament:assets
  

• Config cache can hide registration changes. If the plugin works locally but not in staging, check whether config:cache was built before the new config was published.
• Plugin registration errors often look like container or Livewire failures. Verify the panel provider is actually registered, the plugin class exists under the Filament 5 namespace, and the panel is not using a cached component manifest.
• Publish tags and service provider behavior may have changed. Inspect the package service provider if vendor:publish does not produce expected files. Do not copy v2 publish commands blindly.
• Rebuild frontend assets. Filament 5 upgrades commonly require a fresh asset build. If styles or scripts are missing, check the package’s asset registration and run the Filament asset publish command.
• Use the package’s extension points before overriding internals. Prefer published config, custom views, panel hooks, and documented actions. Editing vendor files or monkey-patching panel registration will make the next major upgrade harder.
• Debug with php artisan about and panel discovery. Confirm the application reports Filament 5.x, the package is installed at 3.0.x, and the panel provider is discovered. Then isolate by registering the plugin on a single minimal panel.