I wouldn't mind seeing 5.1 last for at least a decade. And no this is not unrealistic, java ee 1.4 was around a very long time, a version should last at least several years. Not just two or three months.

@Ruffles earlier in this post I said

How about less junk, make more simple. People isn't the main idea to query a database and display results, and other crud operations. Keep adding in un-neccessary junk, Laravel will be a 20 gig folder gees.

Then you said

What's considered to be unnecessary junk? Everything that Laravel offers out of the box is useful, unless you are building a static site which does not use many of the features of the framework. It really depends on the application you are building.

And then turned around and said

I'd love to see Laravel as a component based framework, similar to how JavaScript frameworks work. That might require an extra configuration at the start but the user will have a choice what he wants to use and what he needs at the moment.

For example: I don't need queues, jobs and logs for some reason in the application, so I want to turn them off (or they should be off by default). If I need them in the future, I'll turn them on. I believe Lumen works like this with Eloquent and some other components being turned off by default.

Which is exactly what I meant by junk, only using junk as slang for un-necessary stuff. Let someone choose what additional components to add via composer. I'd love to see a windows installer also like bitnami stacks have where you can pick what is to be included.

Yeah but I forgot to mention that it might increase the speed if you have less components turned on. I don't care what's the size of the folders.

@jlrdw the framework is just the default collection of Illuminate components. You could always glue the components you need together as you need them and tie them together with your own bootstrap.

It'd be a bit of work the first time around, but it wouldn't be much different to using them independently of the framework.

How about some tests for the environment, or a specific environment testing script

There are too many new people on the forum with 'help, its just a white screen'

It could check;

• app key set
• encryption available
• correct php version
• case sensitivity
• exposed .env file
• no database connection

etc

@Snapey that's a good idea - some kind of check_environment script that initially is independent of php/artisan etc. If I'm bored tonight I might have a go at that actually... ;-)

A Navigation system like zend framework to create menus or breadcrumbs that also work with the ACL

I'd like to see some kind of built in "transformers" for data, instead of visible/hidden attributes, which are useless in the vast majority of cases because the visible/hidden attributes of a model can change depending on the context.

It can be a laravel integration of fractal, like flysystem is integrated to laravel, but it could also be something with a wider scope like rendering in many formats (I can think as json and csv).

How about no .env file.

How about no .env file.

Where would you store the env var then ?

Well, where did 4.2 have configuration? Was this really a real question, seeing as how .env isn't required in 5.1.

Well, where did 4.2 have configuration?

In the config dir and it was way more cumbersome to use.

Was this really a real question, seeing as how .env isn't required in 5.1.

If you have no env variable you dont need to.

Yeaaaah array validation https://twitter.com/taylorotwell/status/659818935659827200

hey @andy what is the reference to "CI and Jeff"s package"?

I don't know if Taylor works alone or has a team but I would love Spark before Laravel 5.2. 5.1 is great already. Add Spark on top and it is great x 2. Then I could get excited for 5.2.

For the multi-tenant guys, here are my thoughts.

First of all, lets talk about how to identify the target tenant. How do we know the tenant that the use want to access. This can be identified one of three ways "perhaps there are more". Let's assume that my tenant is "XYZ" First approach: pass the tenant unique identifier as a subdomain. Any use belong to the XYZ tenant would be advised to login to https://XYZ.example.com Second approach: pass the tenant unique identifier in the URI. Any use belong to the XYZ tenant would be advised to login to https://www.example.com/XYZ Third approach: pass the tenant unique identifier as a field in the user's login form. When the user logs into https://www.example.com, he/she will be prompted to type their username, password and tenant Unique Identifier to login.

Now let get into the design. Each table in the database MUST have a column to compare the tenant ID value to. In this design, each table must have a column called "tenant_id".

Now, with each database query (SELECT, INSERT, UPDATE, DELETE) the "tenant_id" column must be added to ensure each connection is restricted to the correct tenant.

As you may have already guessed, what I am trying to say here is that multi-tenancy is an application design not a framework design.

Core Features added to a framework should be used in most application life-cycle. With that in mind, lets ask our self "will most application need multi-tenancy?" And the answer is probably not. Therefore, Laravel core should NOT include it. However, Laravel 5.2 should have all the features needed to allow developers to design multi-tenancy application easily.

Let's take a look at how can we develop a multi-tenancy application using Laravel 5.1.

We can use existing routes features to pass the the tenant ID in the domain with no issue. Or, you can pass the users model/session variable to every request if the tenant ID is passed in a form during the login. We already have $tenanctID in every entry point to our application aka controller.

Now we need to be able to tell Laravel to automatically add the tenant_id = $tenanctID to every database query. We can accomplish this by hooking into eloquent events fairly easy http://laravel.com/docs/5.1/eloquent#events. The only thing that I would need here would be an event on "selecting" and on "selected" which will allow us to hook into each select query and automatically add a where clause i.e. (WHERE tenant_id = $tenanctID)

One advanced feature a multi-tenancy application may want to have in its design is the ability to host one tenant over multiple database servers. The way to accomplish this is by having a meta table on the main database server, which will tell you to which database instance to connect to in order to access the requested data. Then, we would select the host, username, password and table name from the meta table and use that info to connect to the database where the data resides. Of course, you want to to store the password encrypted and decrypt them on the fly here.

I believe that Laravel is missing the following 2 features and should be part of Laravel 5.2

1. "selecting" and "selected" events added to eloquent.
2. The ability to connect to a specific database instance dynamically. Something around the lines of the logic below

$db1 = connect to main instance;
$db1::myModelName->where.....

$db2 = connect to an instance using the following info(host, username, password, database)
$db2->table('accounts')->where.....

I hope that Taylor would read this and add these 2 important features in Laravel 5.2

Seen some great stuff in this thread, however i agree with the majority re multi tenancy, it shouldnt be backed in as there are multiple ways to achieve it.

Ive written a package which im pretty happy with: https://github.com/leemason/tenantable which works off different connections (allowing different databases, or just different prefixes), but i know that wont suit everyone, it really is almost a per app kinda deal.

Also noticed a comment on extra server packageless broadcasting system, ive built something similar to this too, here: https://github.com/leemason/polycast. It saves events in the db and uses js timeouts to fetch them.

Hope they help the people asking.

Artisan::queue to support extra configurations like delay.

Built-in support for RethinkDB.

Given the shift towards real-time apps, this would be a logical addition.

I would just like specific uses of traits to be reviewed. In some instances I find they do not provide value but make the code less readable ("followable"). Mainly the default Auth (register/login) class/trait tree which I basically recreate in a trait-less form for sanity checks.

Custom name for resource routes

Crud generation like symfony does.

CRUD boilerplate is definetly way forward... Its just would save so many time. Basically implementing

php artisan make:migration create_named_table 
php artisan make:model Named --create=Named
php artisan make:controller NamedController --resource
php artisan make:request NamedRequest

then we need go to routes write

Route::resource('named', 'namedcontroller')

and basically all in the end is the same.

So idea here would be something like:

The idea for me for speed it up:

php artisan make:model WhateverModelWeWant

php artisan make:crud WhateverWeWant

Based on the variables that we put in the model and their relationships we can generate full crud of it. The request would just put something like for string max: 255 and then we tweak it for our needs. Or just basically copy the Yii 2 generator idea. Its also not bad.

The view boilerplate could be just raw data, without any kind of menus, just simple forms and tables. Then we just add extend master view and all ready to go. In a project like feng office, it would speed up production in around 25%-40%.

Multi-tenancy I would say awesome!

@nayzawoo - It already exists: https://laravel.com/docs/5.1/controllers#restful-naming-resource-routes

we need role and permission for user..

after php artisan make:auth

we need
php artisan make:role

php artisan make:permission

is possible?

@acitjazz -> https://laracasts.com/series/whats-new-in-laravel-5-1/episodes/16