Request Errors not accessible in blade (Laravel 5.2)

后端 未结 2 831
没有蜡笔的小新
没有蜡笔的小新 2021-02-20 16:08

It had been many months since I\'m using laravel but never faced such problem.

I have made a simple Request class to validate the the update user request which works fin

相关标签:
2条回答
  • 2021-02-20 16:41

    @VipindasKS is right with his assumption. Since Laravel Version 5.2.28 the web middleware is included in all routes via the RouteServiceProviders's method:

    protected function mapWebRoutes(Router $router)
    {
        $router->group([
            'namespace' => $this->namespace, 'middleware' => 'web',
        ], function ($router) {
            require app_path('Http/routes.php');
        });
    }
    

    Since that version Laravel's default routes.php file only contains:

    Route::get('/', function () {
        return view('welcome');
    });
    

    So if you upgrade from a previous version, that has a routes.php file like this:

    Route::group(['middleware' => ['web']], function () {
       // web routes
    });
    

    Your application will just work fine, because with an composer update you won't touch your RouteServiceProvider (It does not add the mapWebRoutes() method). So the 'web' middleware is only added to the routes within the 'web' group'.

    However if you are pulling a fresh installation of Laravel ( currently 5.2.29 ) and have a routes.php with

    Route::group(['middleware' => ['web']], function () {
       // web routes
    });
    

    The web middleware stack will be added twice to the routes. You can check this via:

    php artisan route:list
    

    Which will show that the 'web' middleware is added twice:

    | POST      | users/{id}/edit          |                  | App\Http\Controllers\UserController@update      | web,web    |
    

    This breaks the Session's flash variables as they are normally only intended to last only during one session lifecycle.

    So the solution is:

    Don't use the 'web' middleware group in the routes.php file if you pulled a fresh instance of laravel.

    0 讨论(0)
  • 2021-02-20 16:51

    You may want to use withErrors redirect, in case validation fails

        if ($validator->fails()) {
            return redirect()
                ->route('route.here')
                ->withErrors($validator)
                ->withInput();
        }
    

    Also, please check

      \Illuminate\View\Middleware\ShareErrorsFromSession::class,
    

    is there in 'web' middleware in app/Http/Kernel.php

    so your kernel.php should look something like:

    /**
     * The application's route middleware groups.
     *
     * @var array
     */
    protected $middlewareGroups = [
        'web' => [
            \App\Http\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \App\Http\Middleware\VerifyCsrfToken::class,
        ],
        'api' => [
            'throttle:60,1',
        ],
    ];
    

    If that too doesn't work, you can move the

      \Illuminate\View\Middleware\ShareErrorsFromSession::class,
    

    to the global middleware. (just to try. I won't suggest)

    ** Make sure sessions work. To have errors returned or to flash messages to the browser, you need to have a session running.

    From 5.2, sessions only start if you specify that the route should use the 'web' middleware (which is already done by you in the routes.php).

    And, From 5.2.28, web middleware is automatically included in all routes, you can see this in the RouteServiceProvider. so, we don't want to specify a 'web' middleware to the routes.php or in controller unless we have a custom middleware. But, not sure this caused the problem.

    0 讨论(0)
提交回复
热议问题