docs VS Laravel

Laravel Documentation : The official Laravel documentation (https://laravel.com/docs) is a resource for of all levels. It undergoes regular updates and comprehensively covers everything from basics to advanced features.

Laravel has the most extensive and thorough documentation and video…

Laravel has the most extensive and thorough documentation and video tutorial library of all modern web application frameworks, making it a breeze to get started with the framework.

What have you tried from the documentation?

As we've already seen above, Markdown can help provide semantic meaning to your content; and in most cases, it doesn't need to be rendered for you to understand it. This is useful when multiple people are contributing to a file because familiarity with the styling of the output is not required. For example, the contents of the Laravel documentation are contained within a repository on GitHub (laravel/docs). It's completely open for anyone to contribute to it without needing to know about CSS classes or styling that the site will use during rendering. This means that anyone familiar with Markdown can jump right in and start contributing with a minimal amount of blockers.

After learning a little more about How To Use RESTFUL Resource Controllers In Laravel, we can see how useful are the tools that Laravel provides for creating and manipulating API data. Always remember to stay on top of the official Laravel documentation, which is always kept up to date (Laravel Documentation)

The documentation is also top notch... you have everything you need to know in a single, coherent place. Just check the laravel docs.

The only issue was the one that's discussed here: https://github.com/laravel/docs/pull/8009

Hope this saves a future team from unexpected behavior resulting in (potential) production data loss.

When using Postgres, Laravel's default method for truncate uses the cascade option, which will ignore foreign key constraints and potentially wipe large amounts of data with no confirmation or warning.

It was originally introduced in 2018: https://github.com/laravel/framework/pull/26389/files

Here are two threads on it if you are curious: https://github.com/laravel/framework/issues/29506

I am just exploring middleware in this post, but as you can see this is quite a different approach than we've seen historically. I sat there scratching my head, "How do I set up my own middleware? How do I change the defaults?" I had to explore the Illuminate\Foundation\Configuration\Middleware class to find out.

For example check out this issue I reported on their side: https://github.com/laravel/framework/issues/49089

It does not mean you should absolutely use it everywhere, but it can make sense for your case. Many frameworks, like Laravel use it to compose new projects.

https://github.com/laravel/framework/blob/00894b89e42a9d707c...

Even Tinker is a few lines of code to extend PsySH and credit is barely given.

Taylor Otwell is a fiend for creating wrappers around solid open source libraries, using PHP magic and encouraging bad practices, all just to breed an ecosystem ultimately to land him a Lambo, fuelled by amazing open source foundations that have barely been contributed back to by him.

This same system has been used in Laravel since version 4.0* albeit in the more PHP plain way, using call_user_func_array (Laravel Model Class).