Filament Info Alert Laravel Package

Getting Started

rectitude-open/filament-info-alert is a small Filament plugin that ships an InfoAlert component for surfacing informational callouts inside Filament panels (forms, pages, widgets). It is a presentation helper, not an application layer — expect to reach for it whenever you need a styled hint, notice, or onboarding message in an admin screen.

1. Install and register

   composer require rectitude-open/filament-info-alert
   

   Register the plugin in your panel provider (app/Providers/Filament/AdminPanelProvider.php):

   ->plugin(\RectitudeOpen\FilamentInfoAlert\FilamentInfoAlertPlugin::make())
   

2. Where to look first

   • The src/ directory for the InfoAlert component and its namespace (v1.0.1 changed this — see Gotchas).
   • The resources/views/ folder for the Blade template if you need to restyle.
   • The README for the exact make() / fluent API supported in your Filament major version.

3. First use case — drop an alert into a resource form schema:

   use RectitudeOpen\FilamentInfoAlert\Components\InfoAlert; // verify exact namespace for v1.0.1
   
   public static function form(Form $form): Form
   {
       return $form->schema([
           InfoAlert::make()
               ->title('Heads up')
               ->body('Changes here affect live data.'),
           // ...rest of schema
       ]);
   }
   

Implementation Patterns

• Form schema insertion — the primary pattern. Place InfoAlert::make() at the top of a form() schema or between sections to explain fields before the user reaches them. Combine with ->columnSpanFull() so it spans the grid.
• Conditional messaging — wrap in ->visible(fn ($record) => $record?->isLocked()) to show contextual warnings only when relevant (e.g. read-only records, draft states, missing prerequisites).
• Page headers / widgets — the same component can be rendered inside a custom page or dashboard widget, making it a consistent way to surface release notes or environment banners (e.g. "You are on staging").
• Blade reuse — if you need the alert outside a Filament schema, render the published Blade view directly (<x-filament-info-alert::... />) rather than duplicating markup. Publish views first (see below) to control the markup.
• Fluent chaining — treat it like any Filament component: chain ->title(), ->body(), ->icon(), ->color() where exposed. Check the README for the supported chain per version; not every Filament component option is wired through.
• Extraction — if the same alert appears in multiple resources, wrap it in a small static helper or an AlertFactory so copy/colour live in one place.

Gotchas and Tips

• v1.0.1 namespace change (the headline fix). The InfoAlert component's namespace was corrected. If you scaffolded against v1.0.0, your use statements or any class-string references (e.g. inside ->schema([...]) or config arrays) may point at the old FQCN and will break. Grep your codebase for the old namespace and update, then clear caches:

  composer dump-autoload
  php artisan filament:cache-components
  php artisan view:clear
  

• Filament version pairing. This is built for a specific Filament major (v3 line). Mixing it with a Filament v2 panel or a future v4 will produce missing-method / missing-view errors. Pin both filament/filament and this package together in composer.json so bumps stay in lockstep.
• Publish the views before restyling. Don't edit vendor/ — publish and override:

  php artisan vendor:publish --tag="filament-info-alert-views"
  

  Re-publish after upgrades if the upstream template changed, or your copy will go stale silently.
• Caching masks changes. Filament aggressively caches components and Blade views. After any upgrade (especially a namespace fix like 1.0.1) a stale component cache is the usual cause of "class not found" or "old markup still rendering." Always run filament:cache-components + view:clear.
• Asset registration. If the plugin registers CSS/JS, ensure php artisan filament:assets runs in your deploy pipeline; otherwise the alert renders unstyled in production but looks fine locally.
• Extension points. The clean levers are: published views (markup), component fluent API (content/colour/icon), and wrapping the component in your own class if you need app-wide defaults. Avoid monkey-patching the vendor class — the 1.0.1 namespace churn shows the internals are still settling.
• Semantic HTML / a11y. Info alerts sit in the page flow; if you render them inside dense forms, verify screen-reader roles (role="status" / aria-live) survive any view customisation you apply.