So far, we've managed to bundle some custom Filament components into a plugin, and those components can now be used by anyone who installs the plugin. But what happens if you have something like a panel resource like this, and you want to be able to bundle this up and ship it in a plugin? Now, it's pretty similar. So, let's go and try and just move over this resources directory into our plugin. So, packages from the toolkit source. Going to move the entire thing into there. And phpsong is going to do its best to move everything over with a new namespace. But it's missed these references to the pages here. So, let's update those. So, place that with Filament toolkit. Okay. So, now let's refresh the page. And we have a 404. And the reason for this is because in the AdminPanelProvider, we are discovering resources that are in the app path. So, in the Filament resources directory there.

a 404. And the reason for this is because in the admin panel provider, we are discovering resources that are in the apps path. So, in the filament resources directory there. And we're registering anything that belongs in that namespace. So, app/filament/resources. But obviously now our UserResource doesn't have that namespace, nor does it live at this path. So, how do we handle this? Now, if you're a plugin developer, you have a couple of options. What you could do in your installation guide is tell users to add new resources. Cool like that. And this can then be used to pass an array of resources to register manually. There we can put in our UserResource. Pass in the class name. Now, when I refresh the page, our UserResource is back. And we can use it as normal. This is fine. But what happens if you have ten resources that you're going to be registering? Now, this is where a plugin

our UserResource is back. And we can use it as normal. This is fine. But what happens if you have ten resources that you're going to be registering? Now, this is where a plugin object comes in. And a plugin object is specifically used to change the configuration of a panel from a plugin. I'll show you exactly how it works. So, essentially what we're going to try and do is move this resources call into its own file. And then the user can just include that file in this panel and it should just work. So, what we need to do to make our plugin object is go into our source directory. And I like to name the plugin object after the plugin itself. So, I like to call it in this case FilamentToolkit. Or even just Toolkit since all filament plugins won't need that prefix. So, we have this Toolkit class in the filamentToolkit source directory. Now, this class is going to implement an interface.

since all filament plugins won't need that prefix. So, we have this Toolkit class in the filament Toolkit source directory. Now, this class is going to implement an interface. And that interface is going to be Plugin. And this is in filament contracts. Let's create the class. And as you can see, we now implement the interface. And we have some default methods. Now, these methods are required by the interface. So, we have getID, register, and boot. getID is going to be used to return a unique ID to reference this plugin later. So, I'm just going to call it Dan Haren Toolkit. But you can call it whatever you want as long as it's unique within that user's application. So, we now have our Toolkit plugin. Now, this register method here is going to be used to interact with the panel object. And it's going to be called by that admin panel provider. It's going to be run on every single request.

register method here is going to be used to interact with the panel object. And it's going to be called by that admin panel provider. It's going to be run on every single request. So, here is where we're going to be putting our resources. So, I'm just going to cut that, copy it into this register method. And we can chain on panel and then pass our resources in. I'm going to leave this boot method for now. I'm going to go back into the admin panel provider and register this plugin in the admin panel provider. So, to do this, we can use the plugin method. And then we pass a new instance of that plugin. So, new Toolkit to the plugin method. And how this works is when you call the plugin method, it's going to call the register method and pass in the current plugin. So, what we're essentially doing is abstracting away all of this resource registration into its own file. So, any users who want

call the register method and pass in the current plugin. So, what we're essentially doing is abstracting away all of this resource registration into its own file. So, any users who want to do it just have to require that plugin. And if you add any new features in the future to your plugin, you can just add them to this Toolkit plugin object in the register method. And when the user updates the plugin, it will just be there. This really simplifies the installation process. This boot method here is slightly different. It's only run when the panel is actually being used. So, when this panel is used, there is a specific middleware in the filament core that loops through all of the plugins and calls the boot method on them. Now, there are some really good use cases for this boot method. One of them is being able to access the current user who's using the panel and maybe registering

method on them. Now, there are some really good use cases for this boot method. One of them is being able to access the current user who's using the panel and maybe registering something based on the user. So, for example, you could have panel and then register certain colors depending on the user. So, you could register like auth user color, for example, as the primary color. And then whatever color string we have here will then be converted into a color and used as the primary color. Now, we couldn't do this in the register method because this is too early in the app's lifecycle. This is being run from middleware after the user's been authenticated, whereas this is being run when the application's being booted. So, that's kind of the gist of why we'd use that boot method. Let's remove this for now. I'm going to show you another cool thing you can do with plugin objects. So, plugin objects,

So, that's kind of the gist of why we'd use that boot method. Let's remove this for now. I'm going to show you another cool thing you can do with plugin objects. So, plugin objects, since they're just normal PHP objects, you can pass any configuration to them. So, maybe we can make it even a fluent plugin object with a public function make and we can make it static and it can return toolkit. And we can just return a new instance of the toolkit. Now we can refactor this to use toolkit make. Once we have that, we can now chain on anything we want as configuration. So, let's have a look at this resource. For example, maybe you want to toggle on and off this email_verified_at column. And some users might want it in their panels and some others might not. Let's add a new public function emailVerifiedAt. This is going to accept a Boolean condition and going to return an instance of the plugin.

their panels and some others might not. Let's add a new public function emailVerifiedAt. This is going to accept a boolean condition and going to return an instance of the plugin object. So, we're going to return $this, store the condition, hasEmailVerifiedAt. Now the property here, so protected boolean hasEmailVerifiedAt. Set it to false. And then we need a getter. So, public function hasEmailVerifiedAt. It's going to return a boolean of our property. So, now what we can do is actually use this configuration method we've added to this plugin object right here. So, we can go emailVerifiedAt(false), for example. And we haven't actually consumed this configuration yet. So, let's do that. In our UserResource, we can access the plugin object for the current panel by referencing its ID. And you can do that with the FilamentHelper. So, the FilamentHelper accepts the

In our user resource, we can access the plugin object for the current panel by referencing its ID. And you can do that with the Filament Helper. So, the Filament Helper accepts the ID of a plugin you've registered to the current panel. And the ID of this plugin is Dan Haren Toolkit. So, let's copy that over into the Filament Helper. And this is going to return our toolkit instance. So, now we can do hasEmailVerifiedAt. Copy that. And we can paste it into this emailVerifiedAt hidden method. So, what we've done here is we've now made it so that column is only showing conditionally. And in our configuration, we can say emailVerifiedAt true. And now it's showing. Now, since this plugin object, this instance here is specific to this panel, if the user has multiple panels in their apps, they can use this plugin across multiple panels, but with different configuration. So, it gives

instance here is specific to this panel, if the user has multiple panels in their apps, they can use this plugin across multiple panels, but with different configuration. So, it gives you much easier flexibility than something like a traditional Laravel configuration file would simply because it can be customized contextually based on the panel.