Filament Footer Laravel Package

Getting Started

Install the plugin

composer require tapp/filament-footer

Then register it on each panel you want a footer on, inside the panel provider (app/Providers/Filament/AdminPanelProvider.php):

use Tapp\FilamentFooter\FilamentFooterPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        ->plugin(FilamentFooterPlugin::make());
}

Where to look first

1. vendor/tapp/filament-footer/README.md — the canonical list of builder methods; this package is small enough that the README is effectively the API docs.
2. vendor/tapp/filament-footer/config/ — if a config file is shipped, publish it before touching any code:

   php artisan vendor:publish --tag="filament-footer-config"
   

3. vendor/tapp/filament-footer/resources/views/ — the Blade view is the real source of truth for what renders and which CSS classes you can override.
4. vendor/tapp/filament-footer/src/FilamentFooterPlugin.php — confirms which fluent methods exist for chaining.

First use case

The 80% case is a copyright line on a single admin panel:

->plugin(
    FilamentFooterPlugin::make()
        ->copyright('© ' . date('Y') . ' Acme Ltd.')
)

Clear your view cache (php artisan view:clear) after registering — Filament caches panel configuration and the footer renders as part of the layout, so a stale cache is the most common "nothing happened" cause.

Implementation Patterns

Chain configuration in the panel provider, not a service provider. This keeps the footer scoped per panel. Multi-panel apps (Admin + App + Vendor) frequently want different footers, and registering globally makes that awkward.

Centralise strings. Rather than hardcoding the copyright in the panel provider, pull from config or an env-backed settings source so legal copy doesn't require a deploy:

->copyright(config('app.copyright'))

Multi-panel pattern — apply consistently via a shared trait or a small helper method on your panel providers:

protected function footer(): FilamentFooterPlugin
{
    return FilamentFooterPlugin::make()
        ->copyright(config('app.copyright'));
}

Then ->plugin($this->footer()) in each provider. Adding links or a version string later is a single edit.

Theme integration. The plugin injects markup into Filament's layout, so it inherits your panel's colour scheme. Style it through a custom theme (->viteTheme(...)) targeting the footer's wrapper class rather than editing vendor views. If the package exposes a ->view() or view-override hook, publish and customise the view into resources/views/vendor/filament-footer/ instead of forking.

Auth-aware footers. When the footer needs user/session context, resolve it at render time in a custom view rather than in the panel provider — panel providers run during container boot and are a poor place for auth()->user() calls.

Testing. Footer output is layout-level, so assert on it in a simple panel smoke test: $this->get('/admin')->assertSee('©'). This catches the "plugin registered on the wrong panel" class of bug cheaply.

Gotchas and Tips

• Register on every panel, not once. Filament plugins are per-panel. If the footer is missing on a secondary panel, check that provider's panel() method — this is the single most common mistake.
• Cache after deploy. php artisan filament:optimize (or your usual config:cache + view:cache) bakes panel config; forgetting filament:optimize-clear/view:clear produces phantom behaviour between local and production.
• date('Y') vs a fixed year. Using date('Y') looks convenient but changes silently on January 1st with no diff to review. Prefer an explicit config value updated deliberately.
• Long copyright strings wrap badly on mobile. The footer sits below the main content area; on narrow screens a verbose string plus links will stack or overflow. Keep the copy short or test at 375px.
• Forking the vendor view is a trap. Overriding the view in resources/views/vendor/ is safer than editing vendor/ directly, which composer install will overwrite. If the package doesn't support view publishing, wrap your customisation in CSS instead.
• Zero dependents / low stars means treat it as unmaintained. With 5 stars and no dependents, expect no timely fixes. Pin the version ("tapp/filament-footer": "^x.y") and be ready to inline a ~30-line Blade partial if it breaks on the next Filament major — a footer is trivial to replace, so don't architect around it.
• Check Filament version compatibility in composer.json. Filament v3 → v4 changed plugin and layout APIs; verify the constraint before upgrading your panel.
• Extension points are thin. Realistically the extension surface is: fluent config methods, the config file, and the Blade view. If you need conditional footers (e.g. hide on certain resources), do it in the view or via a small custom Livewire/Blade partial rather than fighting the plugin.
• Debugging tip: if the footer renders in php artisan serve but not in your Docker/staging environment, compare php artisan about output — a cached config from a different .env is the usual culprit.