Manually registering Filaments routes
Is there a way to disable the automatic registration of routes with Filament, so that I can manually register them?
I don't want to build the routes myself, I just want to be able to have something like the following:
22 Replies
What exactly do you want to do? You can group them already? That's what the path is... you can also add middleware with ->middleware()
So not sure what you want...
I want to wrap every filament route in a group, rather than have to add all the details from that route group to every panel
I was trying to find a way to do it that doesn't involve overriding stuff and hacking it about
It's a multitenancy thing that's outside of Filaments multitenancy functionality
Filament already does that by the panel path
What do you mean?
In the filament provider for the panel, you set the path. The path is the ID by default… like ‘admin’ all filament routes are grouped under that.
Which sets the path of the panel. I want to wrap every route that Filament creates in a route group
A very specific route group that is also automatically generated, and I don’t want to have to manually create it for every single panel
That sets it as a panel, but it also sets it as a group… just include the resources/pages in the additional panels?
The route group is this:
Recreating the route group created by that, manually, it's going to be complex and will break if anyone changes any config
I suspect I'm going to have extend
Filament\Panel
, which is fine
I was just hoping for something simplerSo Panel by default groups all resources and pages within that panel to it's $panel->id() if $panel->path() is not set. This is how we can have multiple panels with resources with the same names.
If you have multiple resources that you want to register in multiple panels then you can add more in the discorer i.e.
->discoverResources(in: app_path('Filament/AppPanel/Resources'), for: 'App\Filament\AppPanel\Resources')
->discoverPages(in: app_path('Filament/AppPanel/Pages'), for: 'App\Filament\AppPanel\Pages')
Except the problem is that I need to apply several routing characteristics to the panel, except I do not know them
Routing charachteristics like?
Yeah, domain, path, middleware, etc
Except I do not know them, and parts of the URI will sometimes have parameters in that I do not know the name of
The URL can have paths in the paths of the resource
But ideally you should be using query strings if need to pass in additional params.
you can also use ->moddle() to apply special routing charachteristics too.
I think you're misunderstanding what I need
I have a third-party package that automatically creates a route group for me
I want the filament panels I'm creating to exist within that route group
But at no point do I know the structure of that route group unless I run the
route:list
command and attempt to recreate itSo in the panel provider (panel) get the group string from your plugin, and pass that into the path of the panel.
What group string?
The route group comes from here:
From what ever you are using to create the groups?
To create the groups I call this:
That is a mixin added to
Router
which does a whole host of things internally, including reading config to load and create a driver, before then asking that driver to create the route group
I do not have access to the details of the route group
The third-party package is mine, but I'm not adding the functionality to do that
I'm trying to create a nice way to make Filament work with my multitenancy package, and because of how the package works, it doesn't need to touch Filaments multitenancy functionalityRight so you want Filament to be under your package opposed to at the route, but because filament was designed to be an admin panel we set our own rights at the primary level
Sort of, yes
Honestly, I could probably create a very quick PR for Filament that would allow you to do this, however, I assume that there's no desire for that since it can't already be done
I'll create a compatibility plugin that overrides a few things
Cool, you'll be surpirsed how open dan is to PRs that are low maintenance
It would be low maintenance, but most likely changes a fundamental base part
I'll probably throw the problem at Alex anyway, see if he has some secret insider knowledge I don't lol
Thanks for your help