Laravel comes with out-of-the-box authorization mechanism which is incredibly easy to use. But it depends on several pre-defined things, one of the main ones - DB table **users** structure and login with **email** field. What if you want to have **username** to identify a user?
Did you know that Laravel Auth system allows you to block the user after X bad attempts to log in? Even more, you can change that limit! This trick works with out of the box Laravel Auth system and all you have to do is modify one file.
Today I want to offer you an overview of a package made for DataTables.net integration into Laravel: laravel-datatables. This package allows you to easily create server-side processed DataTables with most of its available functionality while only writing a few lines of code.
Laravel has a great mechanism of migrations, but what if you want to visualize your DB schema to see all in one place - to discuss with colleagues, for example. There is a great tool for that - here's a brief overview of Laravel Schema Designer.
Migrations are a great way of building database schema, but sometimes it's harder to deal with more than just columns. One of more interesting things are indexes. In particular, I had a problem of auto-assigning a name to unique index, which appeared to be too long. What to do with it?
Today I want to share a small trick which I've found out only recently. Let's say you need to have a select dropdown field with number range from X to Y - for example, birth year from 1900 to 2015. How would you do it?
When selecting data form the database, sometimes you need to make some extra filtering with results - with some if-else statements and similar. With Laravel - you can achieve that with Accessor fields or just looping through results in PHP. But there is a more effective way - to move the filters to the database query itself.
Let's imagine the situation: you have a big database table (like 10 000 rows or bigger) and you need to run an update to one column. But you cannot run just SQL query - there is some PHP logic behind it. So foreach loop could potentially take forever or bump into a default 30-second script limit. Luckily, Laravel has a neat solution for it.
I've unexpectedly encountered a situation which might be useful to someone deploying projects. When it's time to move projects from local environment to production (or staging) server, a lot of weird things might happen there. One of them is a parse error in public/index.php file.
Quite often the logic of our applications rely on the current time. For example, if it's weekend, or if it's past midday or something. We usually use Carbon::now() to check the time - but what if it's morning now, and we need to test if it's 5 PM already? Do we really need to wait till evening to test the function? No. Carbon has a trick for that.
