filament icon indicating copy to clipboard operation
filament copied to clipboard

Plugin [filament-edit-profile] is not registered for panel [app]

Open cweagans opened this issue 8 months ago • 5 comments

Package

filament/filament

Package Version

v3.3.10

Laravel Version

v12.8.1

Livewire Version

v3.6.2

PHP Version

8.3.17

Problem description

If I create two panels and enable a plugin in one of them, I get Plugin [filament-edit-profile] is not registered for panel [app]. I specifically do not want to register the plugin in the app panel -- only in the user panel.

Expected behavior

I should be able to enable a plugin in one panel and not the other.

Steps to reproduce

  1. Create two panels - app and user
  2. Set the path on the app panel to be / and the path on the user panel to be /user
  3. Enable a plugin in the user panel

This is all reliably reproduced with the repo below. The only other thing I changed is the panel color so I can differentiate between the two panels prior to enabling the plugin. That repo also includes a ddev setup in case you want to reproduce the exact environment that I'm using locally.

Reproduction repository (issue will be closed if this is not valid)

https://github.com/cweagans/filament-plugin-bug

Relevant log output


cweagans avatar Apr 10 '25 05:04 cweagans

Prior art: https://www.answeroverflow.com/m/1192802009548595320

I could not find a related bug for @awcodes ' repo linked on that page.

cweagans avatar Apr 10 '25 05:04 cweagans

This issue happens when a plugin is registering a page slug dynamically based on something like a $plugin->slug('my-custom-slug') method. It's very convenient for users but it can be unhandy when having a plugin only registered in some panels. In my case, adopting the plugin to the following code fixed the issue:

Image

Though it would be cool if the getSlug method could get access to the current $panel that the route is being registered to, like eg by accepting a $panel parameter.

ralphjsmit avatar Apr 22 '25 13:04 ralphjsmit

I have the same issue.

The problem comes from filament/routes/web.php.

When routes are registered, current panel is not set and all plugins works with default plugin.

A fix will be to temporarily set the current panel in the filament/routes/web.php:

Route::name('filament.')
    ->group(function () {
        foreach (Filament::getPanels() as $panel) {
            /** @var Panel $panel */

            filament()->setCurrentPanel($panel);  // <---------- THIS WILL FIX THE ISSUE
            
            $panelId = $panel->getId();
            $hasTenancy = $panel->hasTenancy();

With this fix, all plugins will work with the correct configuration from the correct panel.

icaliman avatar Apr 25 '25 06:04 icaliman

I have a workaround until the issue is solved. Instead of using:

Plugin::get()->getSlug();

If in your plugin you use:

Plugin::make()->getSlug();

It works properly, but the problem is you're creating a new instance of the plugin itself and it's not configurable. But by now it works. I hope this will be useful for someone.

EDIT: Another option is to set slug into config file.

gboquizosanchez avatar May 23 '25 10:05 gboquizosanchez

In V4, the getSlug() method will receive the current $panel parameter, so then you can do it like this:

public static function getSlug(?Panel $panel = null): string
{
    $panel ??= Filament::getCurrentOrDefaultPanel();

    if ($panel->hasPlugin(...)) {
        return $panel->getPlugin(...)->getSlug() ?? parent::getSlug($panel);
    }

    return parent::getSlug($panel);
}

This will always return the correct $panel that the route is registered for, so then if a user has the plugin registered only in their non-default panel, then $panel will be that non-default panel and you can still correctly retrieve the configuration. So I would say that this issue can be closed.

ralphjsmit avatar Jun 09 '25 16:06 ralphjsmit

Thanks @ralphjsmit

danharrin avatar Jun 22 '25 22:06 danharrin