Organizing as Package0:00
So think about it. To allow for this honeypot functionality, we had to create a middleware, and you can find that here. Next, we needed configuration, and you'll find that over here. And then we needed a component, and you'll find that here. And in real life, you'll probably have one or two more files. So sometimes it's a shame to have one piece of functionality dispersed throughout your entire codebase. What if, let me close this out, what if instead we acted as if we were building a package, even if you never distribute it?
Moving Files into Directory0:28
What if, let me close this out, what if instead we acted as if we were building a package, even if you never distribute it? That might take the shape of something like this. Create a directory here called honeypot. I'm now going to move all of the relevant files there. So honeypot goes there. Next our Vue, in fact, let's just do this. Let's copy this and move it over there, and then get rid of the components that are irrelevant. So notice I'm kind of keeping the same directory structure, and again, this is often what you'll do when you're making a package.
So notice I'm kind of keeping the same directory structure, and again, this is often what you'll do when you're making a package. All right, so we have our middleware, we have our component. What else do we need? The configuration file. Let's grab this. Well, actually, real quick, before we do that, let's add a directory for config, and then drag it there. Okay, so now, real quick in my settings, let's set up a custom scope, just to make it easy to see.
Okay, so now, real quick in my settings, let's set up a custom scope, just to make it easy to see. Add a local scope, and that's only going to include this directory. Okay, that's only to show you, I can now scope it down here, and this is what our package would basically look like. Notice now, everything is contained within a single directory. The only problem is, now, nothing is going to work. Fill it out. Target class middleware does not exist. So we do need to update a few places.
Fixing Namespaces and Routes1:52
Target class middleware does not exist. So we do need to update a few places. First, let's go into our middleware and update the namespace. This will be app\Honeypot, like so. I should also go back to my routes file now and update this, like so. So give it a refresh. Next, it's still failing because it's trying to read from a config file that doesn't exist. So that's our next step. How can we tell Laravel that we have a custom location that we wanted to look for configuration files?
Creating Service Provider2:23
How can we tell Laravel that we have a custom location that we wanted to look for configuration files? Here's how. We're going to create a service provider, HoneypotServiceProvider. Now, a service provider has a register method for registering things into the container, and then a boot method that will be called after all of the service providers in your application have been registered. So think of this as, once everything is loaded, do you want to do something? To start, let's go ahead and extend. What is it?
To start, let's go ahead and extend. What is it? ServiceProvider. Here we go. And yeah, what we're going to do is merge our config from, and you'll see we want to give it a key. The key is going to be basically what our package name is. It's a prefix. We'll call it honeypot. The path is going to be where to look for this config.
We'll call it honeypot. The path is going to be where to look for this config. It's going to be in the current directory, and then into the config folder, and then honeypot.php. Okay, so now we're telling Laravel, we had this config file at this path, and we want that included. So now, if we were building a real package, we can tell Laravel to automatically load its service provider, but we're not doing that yet. So I will manually do it within your config/app.php file. Come on down here.
So I will manually do it within your config/app.php file. Come on down here. HoneypotServiceProvider. So now, Laravel is going to load this as part of its bootstrapping process. Okay. Come back, give it a refresh, and there we go. We are once again detecting spam. So let's see. Let's go on back. Now, let's make sure we see those hidden inputs, and we do.
Registering Blade Component4:19
Yeah, okay. So this is working. I misled you a little bit. This is working only because it's still reading from the original location for that component, but we copied that over earlier. So if I remove that, okay, at least I feel better because I was confused how that was working. It can't find our component now. So let's come on back. First, I haven't even updated the namespace.
So let's come on back. First, I haven't even updated the namespace. That will be app Honeypot. Let's see, views component. That's right. But I still don't think that'll work. No, because it's looking in the default location. So what we can do is tell Laravel that we want to register a custom component. What is it? I don't do this every day.
What is it? I don't do this every day. I guess it is components. Let's see what it needs here. The class and alias. So I think what I can do is say, we're going to call it honeypot, and the path will be the full path to that component. And actually, why don't we, we have some overlap. Let's make this an alias called honeypot component. I think that'll work.
Let's make this an alias called honeypot component. I think that'll work. So now our provider is registering a custom Blade component. And let's see, fingers crossed. It still didn't work. I wonder if I can, is this a situation where I clear my cache? Oh, it did work. Great. Okay. Yeah, that's something you can run into.
