Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

altdevD's avatar

Trouble With Routing To Custom Vendor Class

Clearly, I'm missing something obvious here.

I have replaced part of the base path with "base-path-hidden", but I verified the real path was correct multiple times by copying and pasting it from the error messages and using the cd command to get to that specific directory to ensure it wasn't something stupid like a typo.

In the web.php file I started with:

Route::get('/my-test', function () { $path = base_path('vendor') . '/testvendor/testproject/providers'; return 'Hello Test!' . $path; });

Returns the full "Hello Test" in the web browser along with the full path to the class dir. Again, I then pasted the path onto the CLI. Using cd I got to the class dir as expected.

##########################################

I then changed the web.php to route it to my custom plugin provider class.

This however is where I'm missing something obvious. I'm still new to Laravel and the MVC approach and I feel like I'm going in circles trying to figure this out and the docs don't cover a custom vendor route in enough detail for me to resolve this. I've tried a lot of tweaks and variations, but so far haven't gotten past this stupid class not being recognized. I just know it's going to be a full facepalm when someone points out the obvious thing I'm missing.

My intention here is to develop this as a plugin versus adding it to the root app. I realize my life would probably be easier if I just did it in the main App dir, but I need to get comfortable with creating plugins and how to do this. I think it would be easier/cleaner in the long run anyway to keep it separate. Maybe I'm just missing something obvious with that approach too. :)

web.php:

Route::get('/my-test', base_path('vendor') . '/testvendor/testproject/providers/TestServiceProvider@register::class');

After clearing the route, etc. on the CLI, this is what I get in the browser.

Target class [/base-path-vendor-hidden/vendor/testvendor/testproject/providers/TestServiceProvider] does not exist.

Again, I paste that full path (minus the class name) and get right to my test providers dir. I vi into the TestServiceProvider.php file and the contents are below.

What am I doing wrong?

use Illuminate\Support\ServiceProvider;

class TestServiceProvider extends ServiceProvider { /** * Register services. * * @return void */ public function register() { return('TSP - TEST SUCCESS!!!!!!!!'); }

/**
 * Bootstrap services.
 *
 * @return void
 */
public function boot()
{
    //
}

}

I've also tried psr-4 and namespaces too, but couldn't make either of them work either. I get the basic concept of both of those, but clearly, I am missing something there too. I only mention it in case someone suggests that as my solution.

In fact, I would love to know how to do this both manually like I'm trying, and with namespaces and psr-4. I really need to learn all three approaches and I thought I got the basics, but clearly not.

Thank you in advance to anyone willing to help!

0 likes
8 replies
martinbean's avatar

@altdevd If you’re still “new to Laravel and MVC” then actually learn how to use Laravel before deciding it’s wrong and you need to develop everything as a package.

There’s no point picking a framework to work with if you’re then not going to trust that framework and not use the framework how it’s intended to be used.

altdevD's avatar

@martinbean I never said I thought the Laravel approach was wrong. I simply want to understand how to make a plugin that eventually can go into the marketplace. I assumed from what I've read so far that was the way to approach it. If I made it part of the main app, wouldn't that require others to install my full app versus a plugin that won't have to worry about name collisions, etc.?

When I learn new stuff I tend to throw myself into the deep end first to experiment and break things so I can learn what does what. I've learned a ton already tinkering with all of it. I'm just trying to understand a basic concept that I know I should learn. If you don't want to be bothered by that, I apologize. I'm just trying to learn in a way that works for me. I meant no offense!

martinbean's avatar

@altdevD I meant no offence either, but you should really get to grips with the basics of the framework first. Then you’ll have a better idea on how to develop framework packages once you understand how the framework itself actually works.

The Laravel docs even has a section on package development that covers package routes, so it might be worth reading that.

1 like
altdevD's avatar

@martinbean I think I understand the basic concepts and approach to MVC. I just don't have the syntax down and not enough experience to avoid making stupid mistakes. For me, I skim the basics and then go hands on breaking code until I get it. :) The more I work with new code, the faster I learn it. It's just how my brain's wired.

Thank you for pointing out that package development is in the docs. I just googled it and got right to that section. Skimming it already answered the basic question. I just need to play around with it now. For the record, I thought I looked for it in the docs, but couldn't find it in the menu. Maybe I was just running one of my 24-hour code marathons. ;) Oh, and I fully plan on doing it the Laravel way, including hacking our own local setup. I'm more than sold on Laravel. Before I knew about it I had written my own classes in PHP to just pass an array to classes that did insert, update, and delete. It would convert the array into a PDO call. Once I saw Laravel, I knew I had the right idea but was light years behind Taylor. So, here I am adapting so I can get up to speed for my dream project. I feel like a kid in a candy store when I think about how I'm going to use all of this. I also have a plan to give something back to the open-source community, but one thing at a time.

martinbean's avatar

@altdevD It sounds like you need to make better use of your time.

Yes, you may get the same end result by just breaking stuff until it works. Of you could just read docs and learn how things work the first time around and get to grips with a topic in a fraction of the time instead of “24-hour code marathons” where you’re just smashing nuts until they crack.

altdevD's avatar

@martinbean Believe me I see your point. The problem for me is that the docs usually sound like 1970's stereo instructions written in a foreign language until I have the hands-on experience to make sense of them. I'm self-taught, so I suspect someone with a stronger foundation would have fewer issues with it than me. Across the industry, I find a lot of documentation makes assumptions that I already know aspects that I don't. So, I spend a lot of time learning those aspects as I go too. And I've heard the same complaint from others. Yes in a perfect world, I should go back and fill in that knowledge before tackling the next thing. Unfortunately, I have a lot more going on than just this, so I'm trying my best to find balance. I am, however attempting to improve my base skills in my spare time and as part of learning all this. I'm learning new things every day and my code quality is definitely improving dramatically as I go. I feel extremely comfortable hacking code and debugging, but my foundational knowledge and understanding of all approaches is still lacking. It's getting better every day, but I have a long way to go.

That said, now that I did torture myself. The docs make so much more sense to me and I realized yesterday that I missed a subtle yet very important step the first time around. I had found the page in the docs that references "php artisan make:filament-resource ", but thought it sounded like a cool advanced feature initially to come back to once I had a better grasp. Ironically, using it yesterday solved a question I had further in the docs that kept saying do this in your resource file... I had no clue that running that command would create the resource file. Once I did, the rest of that section made total sense and it all started clicking last night. I had been trying to modify the default resource file and it didn't have the getPages() function. I was stuck on that until I ran the artisan command and generated the file.

If I was writing the docs, I would have flagged that section and said in giant bold text, don't proceed until you have run this command and reviewed the corresponding files it creates, but that's just me. :)

jlrdw's avatar

@altdevD You do realize that this site has complete free courses on laravel also, right.

1 like
altdevD's avatar

@jlrdw I did not! I've only come across the paid ones so far. Maybe google is biased. ;) Thanks for the tip though. Honestly, it is really starting to click with me now. I'm learning Models now so I can do all the CRUD stuff. And yes I'm aware of the artisan commands for it too. I already like the default auto increment id being assumed and created_at, edited_at defaults. I'm going to have to rethink some of my table naming, but I like that it defaults that if you follow the schema correctly. I really appreciate those little touches.

Please or to participate in this conversation.