[6.0] Laravel 6 Wishlist

[tomschlick]

We are probably within a 18 months or so of Laravel 6 based on previous iteration cycles.

Taking that into account. If L6 was released in November/December of 2017, what would you like to see as the big name features / refactors?

[manyopensource]

Volt instead of Blade (because Blade is absolutely bullshit)

[manyopensource]

Please add DI such as Phalcon\DI (because now is ...)

[manyopensource]

You need to update your micro-framework (now it is unuseful)

[imliam]

@manyopensource What're the problems you're having with Blade, Laravel's DI and Lumen? They all do their job well and you've not given any reason for them to be changed.

[mxrxdxn]

@manyopensource what's wrong with Blade? Calling it "bullshit" without reason isn't exactly helpful 😂

[autaut03]

@michaeldyrynda, to me Laravel should at least create it's own package for handling modular structure, preferably Porto. There are a couple of laravel-modules like packages and a framework (not really) built on top of Laravel, Apiato, which utilitizes Porto, but all of them aren't quite suitable for a real production project. Forcing to use modular structure isn't probably the best thing to do, but giving an option to and showing the advantages is a good path to use it as default one in Laravel 7 ;)

[donnysim]

I wish fillable and guarded to be gone in Laravel 6 and instead introduce columns field. Eloquent is mostly usable with them turned off, otherwise it becomes more of a headache then help and leads to bad practices like Model::create($request->all()) etc.. Instead of them, maybe introduce a columns field, which would be optional. It could contain all writable columns from database which would allow to filter which model fields should actually be persisted (updated, created) to database in case you have properties added to your model, that has nothing to do with database, before saving.

[donnysim]

Maybe extract eloquent Model as an App\Model? maybe in this way we would be able to finally make our own, lighter eloquent model version without all the stuff we hate? Because as it is now, Laravels most inflexible peace is the Model and query builder coupling, you can't replace the Model because everything expects a Laravels Eloquent Model, you can't use custom Builder because you have to modify the Model to return the custom Builder, then replace all extended models to use the new model.

[RoccoHoward]

Have a look at my package - https://github.com/hnhdigital-os/laravel-model-schema where I moved all these things to a model schema using a static associate array which brings everything Laravel does with attributes into the one array.

It also provides custom casts to be implemented.

It's fully compatible with existing Laravel models - accessing the fillable and guarded returns exactly these attributes that would be expected.

On Mon, 13 Aug 2018 at 16:22, Donatas Šimkevičius notifications@github.com wrote:

I wish fillable and guarded to be gone in Laravel 6 and instead introduce columns field. Eloquent is mostly usable with them turned off, otherwise it becomes more of a headache then help and leads to bad practices like Model::create($request->all()) etc.. Instead of them, maybe introduce a columns field, which would be optional. It could contain all writable columns from database which would allow to filter which model fields should actually be persisted (updated, created) to database in case you have properties added to your model, that has nothing to do with database, before saving.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/laravel/ideas/issues/226#issuecomment-412419020, or mute the thread https://github.com/notifications/unsubscribe-auth/AAN6OILUQ7g62GSupigFs33ysvpReghdks5uQRs2gaJpZM4KG_jF .

[donnysim]

Adjusting a single line in save method still requires you to create a new model class and change everything to extend it. Having a base "Model" in the app by default would make things easier at any point in time. A huge bonus (at least for me) would be if it was the eloquent model itself, where I can remove fillable and guarded features without overwriting and changing a bunch of other methods. I know we can just create it if we need it, and this is very unlikely to happen because all those packages depend on getting a eloquent model instance instead of customized model, but worth a try :|

[dracon55]

Make function: registerMetaTag(['name' => 'keywords', 'content' => 'yii, framework, php']);

some think like Yii2

[manyopensource]

@dracon55 You mean someone like you, who thinks like Yii2? And I know you from Russia, isn't it?

[autaut03]

@dracon55 To me, this isn't framework's task.

[tomschlick]

I think this thread has run it's course. At this point we should be opening separate threads and PRs for any new items.