New feature in laravel 5.6

There are few feature are listed below: 

1. Logging Improvements
2. Dynamic Rate Limiting
3. Broadcast Channel Classes
4. Collision
5. Single Server Task Scheduling
6. API Controller Generation
7. UUID Methods
8. Bootstrap 4
9. Eloquent Date Casting
10. Blade Component Aliases
11. Argon2 Password Hashing

Logging Improvements

The biggest feature in Laravel 5.6 release is the logging improvements. For starters,

 Version 5.6 logging configuration moves from the config/app.php file to the new config/logging.php file.

You configure “stacks” that can send log messages to multiple handlers. For example, you might send all debug messages to a system log and send error logs to slack.

Dynamic Rate Limiting

Laravel 5.6 introduces dynamic rate limiting that gives you more flexibility and makes it possible to easily rate limit on a per-user basis:

Route::middleware('auth:api', 'throttle:rate_limit,1')
    ->group(function () {
        Route::get('/user', function () {
            //
        });
    });

In the above example, the rate_limit is an attribute of the App\User model to determine the number of requests allowed in the given time limit.

Broadcast Channel Classes

You can now use channel classes in your routes/channels.php file instead of using closures.

To generate a new channel class, Laravel 5.6 provides a new make:channelcommand:

php artisan make:channel OrderChannel

You register your channel in the routes/channels.php file like so:

use App\Broadcasting\OrderChannel; Broadcast::channel('order.{order}', OrderChannel::class);

Collision

We recently wrote about Collision coming to Laravel 5.6 as a dev dependency, providing beautiful error reporting in the console:

Single Server Task Scheduling

If you have a task scheduler running on multiple servers, the task will run on each server. You can indicate that a task should only run on one of those servers with the onOneServer() method:

$schedule->command('report:generate')
    ->fridays()
    ->at('17:00')
    ->onOneServer();

Note: you must use the memcached or redis cache driver as the default application cache driver to take advantage of single server task scheduling in the Laravel 5.6 release.

API Controller Generation

You can now generate a resource controller for APIs that will exclude the unnecessary create and edit actions, which only apply to resource controllers returning HTML. To generate a resource controller, use the --api flag:

php artisan make:controller API/PhotoController --api

UUID Methods

Two new methods are now available in the Illuminate\Support\Str class for generating Universal Unique Identifiers (UUID):

// The methods return a Ramsey\Uuid\Uuid object

return (string) Str::uuid();

return (string) Str::orderedUuid(); 

The orderedUuid() method will generate a timestamp first UUID for easier and more efficient database indexing.

Bootstrap 4

All of the frontend scaffolding and example Vue component now use Bootstrap 4. We have covered Bootstrap 4 while in beta, and even created a Bootstrap 4 Laravel preset. It’s great to see Bootstrap 4 stable shipping with Laravel 5.6!

Eloquent Date Casting

You can individually customize the format of Eloquent date and datetime casting:

protected $casts = [
    'birthday' => 'date:Y-m-d',
    'joined_at' => 'datetime:Y-m-d H:00',
];

This format is used on model serialization to an array or JSON data.

Blade Component Aliases

You can now alias blade components for more convenient access. For example, if you store a component at resources/views/components/alert.blade.php you can use the component() method to alias it to a shorter name:

Blade::component('components.alert', 'alert');

You can then render it with the defined alias:

@component('alert')
    <p>This is an alert component</p>
@endcomponent

Argon2 Password Hashing

Laravel 5.6 supports a new password hashing algorithm for PHP 7.2+. You can control which hashing driver is used by default in the new config/hashing.phpconfiguration file.

You can learn more in our article about Laravel 5.6 support for the Argon2i hashing algorithm.

Laravel 5.5 Request Lifecycle

Introduction:

When using any tool in the "real world", you feel more confident if you understand how that tool works. Application development is no different. When you understand how your development tools function, you feel more comfortable and confident using them.

The goal of this document is to give you a good, high-level overview of how the Laravel framework works. By getting to know the overall framework better, everything feels less "magical" and you will be more confident building your applications. If you don't understand all of the terms right away, don't lose heart! Just try to get a basic grasp of what is going on, and your knowledge will grow as you explore other sections of the documentation.

Lifecycle Overview

First Things

The entry point for all requests to a Laravel application is the public/index.php file. All requests are directed to this file by your web server (Apache / Nginx) configuration. The index.php file doesn't contain much code. Rather, it is simply a starting point for loading the rest of the framework.

The index.php file loads the Composer generated autoloader definition, and then retrieves an instance of the Laravel application from bootstrap/app.php script. The first action taken by Laravel itself is to create an instance of the application / service container.

 HTTP / Console Kernels

Next, the incoming request is sent to either the HTTP kernel or the console kernel, depending on the type of request that is entering the application. These two kernels serve as the central location that all requests flow through. For now, let's just focus on the HTTP kernel, which is located in app/Http/Kernel.php.

The HTTP kernel extends the Illuminate\Foundation\Http\Kernel class, which defines an array of bootstrappers that will be run before the request is executed. These bootstrappers configure error handling, configure logging, detect the application environment, and perform other tasks that need to be done before the request is actually handled.

The HTTP kernel also defines a list of HTTP middleware that all requests must pass through before being handled by the application. These middleware handle reading and writing the HTTP session, determining if the application is in maintenance mode, verifying the CSRF token, and more.

The method signature for the HTTP kernel's handle method is quite simple: receive a Request and return a Response. Think of the Kernel as being a big black box that represents your entire application. Feed it HTTP requests and it will return HTTP responses.

Service Providers

One of the most important Kernel bootstrapping actions is loading the service providers for your application. All of the service providers for the application are configured in the config/app.php configuration file's providers array. First, the register method will be called on all providers, then, once all providers have been registered, the boot method will be called.

Service providers are responsible for bootstrapping all of the framework's various components, such as the database, queue, validation, and routing components. Since they bootstrap and configure every feature offered by the framework, service providers are the most important aspect of the entire Laravel bootstrap process.

Dispatch Request

Once the application has been bootstrapped and all service providers have been registered, the Request will be handed off to the router for dispatching. The router will dispatch the request to a route or controller, as well as run any route specific middleware.

Focus On Service Providers

Service providers are truly the key to bootstrapping a Laravel application. The application instance is created, the service providers are registered, and the request is handed to the bootstrapped application. It's really that simple!

Having a firm grasp of how a Laravel application is built and bootstrapped via service providers is very valuable. Of course, your application's default service providers are stored in the app/Providers directory.

By default, the AppServiceProvider is fairly empty. This provider is a great place to add your application's own bootstrapping and service container bindings. Of course, for large applications, you may wish to create several service providers, each with a more granular type of bootstrapping. 

 

Access token error: timestamp_refused in linked oauth2.0

I have done linkedin oauth api in my local. API response from linkedin is working fine in localhost. When I've moved to server, i got error in linkedin api on the server like as follows.

oauth_problem=timestamp_refused&oauth_acceptable_timestamps=1349951029%2B-300

Solved:

FIRST SEE WHAT IS THE TIME DIFFERENCE BETWEEN THE WEB SERVER AND THE LINKED IN SERVER


In OAuth.php file there is a function [generate_timestamp] which is returning a time(). By changing it to

#to avoid the error of
#oauth_problem=timestamp_refused&oauth_acceptable_timestamps=#return time()+(difference of mints*sec);return time()+(40*60);

Laravel Updates Learning : New feature in laravel 5.4 Route and Model Binding...

Laravel Updates Learning : New feature in laravel 5.4 Route and Model Binding...: In this article i will explain route model binding . Route model binding provides a useful way to automatically method-inject a model&#3...

Laravel Updates Learning : DD and Dump Collections in Laravel 5.5

Laravel Updates Learning : DD and Dump Collections in Laravel 5.5: Laravel 5.5 is two brand new methods on the Collections class that will make debugging easier than ever before. These are dd and dump . ...

DD and Dump Collections in Laravel 5.5

Laravel 5.5 is two brand new methods on the Collections class that will make debugging easier than ever before. These are dd and dump.

Pretend you have a simple collection setup and are piping it through a few filters:

collect([1,2,3])->map(function($i){
    return $i * 2;
})->reject(function($i){
    return $i < 3;
});

Knowing what happens in each step of the chain is can be difficult and now you’ll have the option to either “dump” it out at a certain point, or “dump and die”. For example:

collect([1,2,3])->map(function($i){
    return $i * 2;
})->dump()->reject(function($i){
    return $i < 3;
});

dump() outputs the results at that moment and then continues processing, here is the results when running that code:

Collection {#181 ▼
  #items: array:3 [▼
    0 => 2
    1 => 4
    2 => 6
  ]
}

dd() on the other hand stops the process immediately and dumps out the results:

collect([1,2,3])->map(function($i){
    return $i * 2;
})->dd()->reject(function($i){
    return $i < 3;
});

And the results:

array:3 [▼
  0 => 2
  1 => 4
  2 => 6
]

These will be welcomed features in Laravel 5.5 and if you’d like to start using these today, Spatie released a 3rd party package named Collection Macros that includes both of these methods and a few additional helpers.

Laravel Lifecycle Architecture Concept of laravel 5.5

Request Lifecycle

• Introduction
• Lifecycle Overview
• Focus On Service Providers

Introduction

When using any tool in the "real world", you feel more confident if you understand how that tool works. Application development is no different. When you understand how your development tools function, you feel more comfortable and confident using them.
The goal of this document is to give you a good, high-level overview of how the Laravel framework works. By getting to know the overall framework better, everything feels less "magical" and you will be more confident building your applications. If you don't understand all of the terms right away, don't lose heart! Just try to get a basic grasp of what is going on, and your knowledge will grow as you explore other sections of the documentation.

Lifecycle Overview

First Things

The entry point for all requests to a Laravel application is the public/index.php file. All requests are directed to this file by your web server (Apache / Nginx) configuration. The index.php file doesn't contain much code. Rather, it is simply a starting point for loading the rest of the framework.
The index.php file loads the Composer generated autoloader definition, and then retrieves an instance of the Laravel application from bootstrap/app.php script. The first action taken by Laravel itself is to create an instance of the application / service container.

HTTP / Console Kernels

Next, the incoming request is sent to either the HTTP kernel or the console kernel, depending on the type of request that is entering the application. These two kernels serve as the central location that all requests flow through. For now, let's just focus on the HTTP kernel, which is located in app/Http/Kernel.php.
The HTTP kernel extends the Illuminate\Foundation\Http\Kernel class, which defines an array of bootstrappers that will be run before the request is executed. These bootstrappers configure error handling, configure logging, detect the application environment, and perform other tasks that need to be done before the request is actually handled.
The HTTP kernel also defines a list of HTTP middleware that all requests must pass through before being handled by the application. These middleware handle reading and writing the HTTP session, determining if the application is in maintenance mode, verifying the CSRF token, and more.
The method signature for the HTTP kernel's handle method is quite simple: receive a Request and return a Response. Think of the Kernel as being a big black box that represents your entire application. Feed it HTTP requests and it will return HTTP responses.

Service Providers

One of the most important Kernel bootstrapping actions is loading the service providers for your application. All of the service providers for the application are configured in the config/app.php configuration file's providers array. First, the register method will be called on all providers, then, once all providers have been registered, the boot method will be called.
Service providers are responsible for bootstrapping all of the framework's various components, such as the database, queue, validation, and routing components. Since they bootstrap and configure every feature offered by the framework, service providers are the most important aspect of the entire Laravel bootstrap process.

Dispatch Request

Once the application has been bootstrapped and all service providers have been registered, the Request will be handed off to the router for dispatching. The router will dispatch the request to a route or controller, as well as run any route specific middleware.

Focus On Service Providers

Service providers are truly the key to bootstrapping a Laravel application. The application instance is created, the service providers are registered, and the request is handed to the bootstrapped application. It's really that simple!
Having a firm grasp of how a Laravel application is built and bootstrapped via service providers is very valuable. Of course, your application's default service providers are stored in the app/Providers directory.
By default, the AppServiceProvider is fairly empty. This provider is a great place to add your application's own bootstrapping and service container bindings. Of course, for large applications, you may wish to create several service providers, each with a more granular type of bootstrapping.

Source:https://laravel.com/