Query Scopes - convenient way to isolate often-used conditions
One of less-known but useful Eloquent functions are scopes - basically, you can define conditions to be re-used in various other places in code. Here's an overview.
In-depth Laravel tutorials covering advanced topics, real-world examples, and best practices.
One of less-known but useful Eloquent functions are scopes - basically, you can define conditions to be re-used in various other places in code. Here's an overview.
Today I want to tell about another "trick" - or how to create a Laravel project without Command line or Terminal, directly from PhpStorm.
Eloquent and Query Builder have a lot of "hidden gems" which are not in the official docs. For example, if you want to perform GROUP BY and HAVING, there's a little trick for unnamed columns.
One of the most popular way of debugging in PHP still remains the same - showing variables in the browser, with hope to find what the error is. Laravel has a specific short helper function for showing variables - dd() - stands for "Dump and Die", but it's not always convenient. What are other options?
Laravel has quite a convenient mechanism of dealing with database changes. It consists of Migration files for database structure and Seed files for sample data. But why separate them if sometimes it make sense to add it all to one file?
Another interesting feature in Laravel Eloquent mechanism. When updating existing entry, we just use update() or save() and then updated_at field is changed automatically. But what if we want to stick our own updated_at instead of automatic one?
I'm pretty sure that majority of you haven't read ALL official Laravel documentation - you work only with functions you actually need and know, right? So I like to dig up some less known or "hidden" features which are new to many people. So today one of those "Did you know?" cases.
This short lesson will be both about Laravel and about general software development. One of the most often and common mistakes made by developers is not checking input data. And then not only you get random errors of something "not found", but sometimes much worse - expose your system to vulnerabilities and attacks. So let's discuss that with examples from Eloquent world.
This time - a really short tip. In default Laravel Auth functionality there are some predefined values, settings and similar stuff - one of them is redirecting to /home URL after successful login, or if a user is already logged in. What if we don't have that /home - what if in our case it's different?
Laravel default authentication is awesome. But by default it works by checking two fields - email and password. What if we have some additional fields to check? For example, if user is approved?