Conditionally Loading Service Providers in Laravel 5

Hello Everybody,

Today we will discuss about conditionally Loading Service Providers in Laravel 5.1

Since Laravel 5 flattened a lot of the environment-specific structures, much of the configuration that was once stored in different config directories for each environment has now moved into .env files.

But one that can't just live in .env is the environment-dependent loading of service providers.

On a project we're working on, we want to register our error handlers in service providers, and we want to register a different error handler depending on the environment. We have two: ProductionErrorHandler and VerboseErrorHandler, the second of which is for development environments.

Loading service providers normally
In case you're not familiar, defining normal (non-environment-specific) Service Providers happens in /config/app.php. There's a providers array there that looks a bit like this:

    'providers' => [

        /*
         * Laravel Framework Service Providers...
         */
        'Illuminate\Foundation\Providers\ArtisanServiceProvider',
        'Illuminate\Auth\AuthServiceProvider',
        'Illuminate\Bus\BusServiceProvider',
        ...
    ]

So, if your service provider should be loaded in every environment, just toss it into that array and you're good to go.

Loading service providers conditionally
However, if you want to make it conditional, you'll need to head over to /app/Providers/AppServiceProvider.php. This file is the general place you're going to want to be booting and registering anything that's not handled in another service provider, so this is a place you can go to conditionally register your service providers.

Here's what it looks like right now:

<?php namespace app\Providers;

use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        //
    }

    /**
     * Register any application services.
     *
     * This service provider is a great spot to register your various container
     * bindings with the application. As you can see, we are registering our
     * "Registrar" implementation here. You can add your own bindings too!
     *
     * @return void
     */
    public function register()
    {
        $this->app->bind(
            'Illuminate\Contracts\Auth\Registrar',
            'App\Services\Registrar'
        );
    }
}

So, let's do our switch.

    // AppServiceProvider.php

    public function register()
    {
        $this->app->bind(
            'Illuminate\Contracts\Auth\Registrar',
            'App\Services\Registrar'
        );

        if ($this->app->environment('production')) {
            $this->app->register('App\Providers\ProductionErrorHandlerServiceProvider');
        } else {
            $this->app->register('App\Providers\VerboseErrorHandlerServiceProvider');
        }
    }
$this->app->register() will set up the service provider just like adding it to config/app.php will, so its register() and boot() methods will get called at the appropriate times.

We could also use switch instead of if, or we could do your work based on other environment variables, or whatever else--but this is our current best bet to conditionally load service providers. 

How to create and apply a patch with Git

Hi, Today we will learn how to create and apply a patch with Git.

To make creating patches easier, there are some common git practices we should follow. It’s not necessary, but it will make our life easier.

If you fix a bug or create a new feature – we should do it in a separate branch!

Let’s say we want to create a patch for my branch branch1. We clone repository and create a new branch for the fix we have in mind. In this sample we’ll do an imaginary fix for branch2.

git clone git://github.com/username/branch1.git
cd branch1
git checkout -b branch2

Now, in the new branch2 branch we can hack whatever we need to fix. Write tests, update code etc. etc.

When we’re satisfied with all our changes, it’s time to create our patch.

Creating the patch
Okay, We’ve made some commits, in branch2 branch:

Okay, now it’s time to go and make a patch! All we really want are the two latest commits, stuff them in a file and apply them. But, since we created a separate branch, we don’t have to worry about commits at all!

git format-patch master --stdout > branch2_patch.patch

This will create a new file branch2_patch.patch with all changes from the current (branch2) against master. Normally, git would create a separate patch file for each commit, but that’s not what we want. All we need is a single patch file.

Now, you have a patch for the fix we wrote.

Applying the patch

First, take a look at what changes are in the patch. We can do this easily with git apply

git apply --stat branch2_patch.patch

Note that this command does not apply the patch, but only shows us the stats about what it’ll do. After peeking into the patch file with our favorite editor, we can see what the actual changes are.

Next, we’re interested in how troublesome the patch is going to be. Git allows us to test the patch before we actually apply it.

git apply --check branch2_patch.patch

If we don’t get any errors, the patch can be applied cleanly. Otherwise we may see what trouble we’ll run into. To apply the patch, We’ll use git am instead of git apply. The reason for this is that git am allows us to sign off an applied patch. This may be useful for later reference.

git am --signoff < branch2_patch.patch

Okay, patches were applied cleanly and our master branch has been updated.

In our git log, we’ll find that the commit messages contain a “Signed-off-by” tag. This tag will be read by Github and others to provide useful info about how the commit ended up in the code.

Thanks.

Passing parameters to Middleware in Laravel 5.1

Middleware is like a decorator that goes around our entire application request. It takes in a request, does some work, and spits out a response. And usually, it does that work consistently across every section of our application.

But what if we want to be able to customize exactly how the middleware is being processed for a given route, without creating a new middleware for every place it's customized?

Let's consider the most common example: Scoping authentication middleware based on roles. You want to, in the route definition, choose how the authentication middleware runs, by passing it a "role" parameter that defines which user role is required in order to access this route.

Using parameterized middleware in the route defintion #
When we are adding middleware to a route definition, we would normally set it like this:

Route::get('company', ['middleware' => 'auth', function () {
    return view('company.admin');
}]);

So, let's add in our parameter to show that the user must have the owner role:

Route::get('company', ['middleware' => 'auth:owner', function () {
    return view('company.admin');
}]);

Note that we can also pass multiple parameters as a comma-separated list:

Route::get('company', ['middleware' => 'auth:owner,view', function () {
    return view('company.admin');
}]);
Creating parameterized middleware #
So, how do we update our middleware to teach it to take parameters?

<?php

namespace App\Http\Middleware;

use Closure;

class Authentication
{
    public function handle($request, Closure $next, $role)
    {
        if (auth()->check() && auth()->user()->hasRole($role)) {
            return $next($request);
        }

        return redirect('login');
    }
}

Note that the handle() method, which usually only takes a $request and a $next closure, has a third parameter, which is our middleware parameter. If we passed in multiple parameters to our middleware call in the route definition, we can add more parameters to our handle() method:

public function handle($request, Closure $next, $role, $action)

We need to ensure that this middleware is registered in the HTTP Kernel as a routeMiddleware—there's no way we could pass parameters to a universal middleware.