On the Pineco.de blog they've posted a tutorial for the Laravel users out there showing how to notify locked out users making use of functionality already included with the framework.

Laravel offers a nice feature, that locks out the users that attempted to login too much. It’s a nice way to prevent brute force logins. But how can we notify the user, when the lockout happens? Maybe it wasn’t the user who attempted to log in.

The tutorial starts with the details on setting up the listener to capture the Lockout event and pass it off to a UserLockedOut class. Once this is created, they show how to use this class and, via the included "notification" system in Laravel, send an email to the user in question with more information about their account being locked.

Michael Dyrynda has a post to his site sharing a method he's worked up for customizing the URL signing key that the Laravel framework uses to sign URLs to ensure the integrity of the URL's contents.

Since 5.6, Laravel has shipped with functionality to sign URLs. These URLs append a "signature" to the query string, so that Laravel can verify that the link has not been tampered with since it was created. This also allows you to generate temporary signed routes that expire after a configured period of time.

This is useful for things like verifying account emails, or enabling passwordless logins.

Passwordless logins is something that is quite useful for an application, but what if you wanted to be able to generate a signed URL in one application that would allow you to log in to a second application?

He starts by defining the use case, requiring multiple signing keys to be used, one for customer URLs and another for admin URLs accessing the same content. He makes this work through the use of a custom key resolver, pulling the key for the signing dynamically. He also shows how to update the passthrough authentication handling, allowing the administrators (staff) of the system to bypass normal authentication handling and more directly view the user's information.

The Laravel News site has posted the latest part of their "Building a Laravel Translation Package" series focusing on a pre-launch checklist of items to get in place before it's finally released.

In the last part of the series, we finished up building the Laravel Translation package. With this completed, we are ready to start thinking about releasing the it to the world. However, before we do, there are few important steps we need to take.

The post covers some of the final non-code items to take care of:

• Good documentation
• Defining contribution guidelines
• Providing issue templates for easier reporting of bugs/issues by others
• Selecting a license
• Setting up continuous integration for running tests, checking code style, etc.

Each item in the list includes a brief summary of what's involved and, for some, links to other resources and tools that can help get it accomplished.

On the "Oh Dear!" blog they've written up a post sharing the Gitlab continuous integration pipeline they use for the deployment of the application. While, in their case, it's a Laravel-based application, the basics of it could be used for just about any PHP application with slight modifications.

We've been fairly public about the amount of testing we have for Oh Dear!. Freek has been showing bits and pieces on his Twitter to show the extent of that effort.

Having a huge test suite is nice, but integrating it into your development workflow is even better.

That's why we're releasing our Gitlab CI pipeline that is optimized for Laravel applications. It contains all the elements you'd expect: building (composer, yarn & webpack), database seeding, PHPUnit & copy/paste (mess) detectors & some basic security auditing of our 3rd party dependencies.

The post starts with an overview of their pipeline flow (including a graphic) showing the different stages and the steps involved in each. It then moves on to the setup of Gitlab's CI functionality using a local Gitlab runner to run the pipeline. It covers some of the issues around CPU load using Docker. Next it shares the configurations for the different stages in the flow and decisions they had to make around building assets, dependencies and caching.

In a recent post to his site Jonathan Reinink has written up a guide to using dynamic (Eloquent) relationships in Laravel applications by making use of subquery functionality. In it, he shows how to make use of the selectSub method to select additional information in a single query versus having the overhead of custom, hard-coded relationships.

When building web apps that interact with a database, I always have two goals in mind: keep database queries to a minimum [and] keep memory usage to a minimum. These goals can have a drastic impact on the performance of your app.

Developers are typically pretty good at the first goal. We're aware of N+1 style problems, and use techniques like eager-loading to limit database queries. However, we're not always the best at the second goalkeeping memory usage down. In fact, we sometimes do more harm than good trying to reduce database queries at the expense of memory usage.

He starts off with the challenge he's trying to solve: gathering login information for users in a performant way. He includes the schema for the users and logins table and shows the code of how a normal relationship select might look to get login information for each user (creating an N+1 issue).

To help solve the issue, they try caching the last login information but realize they can do better - this is where subqueries come in. They provide an example of using the selectSub method to get the login information, mapping it to a macro for easier use and defining scopes. Finally, the tutorial shows how to use this method to select information via dynamic relationships. It also talks about lazy-loading issues and if the same thing could be accomplished with a "has one" relationship.

On the Laravel News site, they've posted the announcement of the release of the results from their 2018 edition of the Laravel Survey.

We partner with LaraJobs to run an annual Laravel survey to see what types of projects people are taking on with Laravel as well as get some feedback on what the Laravel community could be doing better. The results ended up with over 1,500 submissions, and some interesting insights.

You can see the complete results on this 2018 Laravel Survey Results page and thanks for everyone who took the time to fill it out.

Questions asked in this year's survey included topics such as why they selected Laravel, size of projects, if they're able to find the developers they need and what they'd like to see more of in the Larvel community (tutorials, articles, regional conferences, etc).

Liam Hammett has written up a post to his site covering the use and creation of helpers for Laravel's Blade templating. He shows the use of a package he's created to help make using them with custom callbacks simpler.

Laravel’s Blade templating engine offers a ton of convenient directives you can use to make your view files beautiful and abstract anything that may be too complex or verbose to live inside HTML. It even gives a really handy way to add your own custom directives using the Blade::directive(…) method.

However, the callback in custom directives only receives a single parameter?—?the raw string expression from the view file. [...] As this seems to be the most common use case, I put together a package that attempts to help make these helper functions that little bit easier to define without the boilerplate of returning the string or having to consider what an expression may be when creating a directive.

In his package he introduces a new method that defines the name of the method and the name of the function to call. This second option can also be a custom callback function, making it even more flexible.

On the Laravel News site they have a new post that "unwraps" the array_wrap helper that makes it easier to normalize values into arrays and removes the need for manually checking if a variable is an array or set before using it like one.

Laravel has a wrap method and array_wrap() helper to normalize values into an array. Raul @rcubitto shared this nice tip about it on Twitter and before seeing his Tweet I wasn’t aware of this method.

They include an example of the helper function in use and share some of the responses to his tweet including questions of how it's different than casting to an array. They answer this by talking about more complex values and how the helper is useful for null values and creating consistency in your application.

Freek Van der Herten has a tutorial posted on his site sharing the 2018 edition of how to build a dashboard powered by Laravel, Vue, Pusher and Tailwind CSS. It's based on a project they use internally to keep up to date on current work, events and even music people are listening to.

At Spatie we have a tv screen against the wall that displays a dashboard. This dashboard displays the tasks our team should be working on, important events in the near future, which tasks each of our team members should be working on, what music they are listening to, and so on.

[...] This dashboard is not entirely new. The initial version was published a couple of years ago. At our company, we like to tinker with new stuff. That's why we perform a big cleanup of the source code every year. We also update all the dependencies and technologies used. This year we focused on updating the design. The dashboard now uses Tailwind CSS. In this blog post, which is an update to the previous one, I like to explain how this dashboard is built.

He starts with a bit of history of the project and a look at the UI before diving into the code. The remainder of the (lengthy) tutorial is then broken down into functional pieces, each with code and explanation:

• the creation of the markup for the grid
• a closer look at the "internet connection" component
• a closer look at the "statistics" component
• the use of "dark mode" depending on the sun being up
• displaying sites that are down

There's also a mention of the security requirements involved in the creation and use of the dashboard, the hardware used to show it on the TV and how data is saved to prevent the need for the initial "reboot" of the data.

The Laravel News site has posted the latest in their "Building a Laravel Translation Package" series of tutorials with a new post focusing on the frontend and getting it connected to the backend functionality.

In the last installment of this series, we talked through the process of manipulating the translations in our application’s language files into a format where we are now in a position to start interacting with them. In this article, we’ll be wiring up the frontend ready to start building out the user interface which will aid users with the process of translation management.

The UI will be developed using the community favorites, Tailwind CSS and Vue.js.

The tutorial starts with the approach for the functionality, taking a more hybrid approach and using a balance of backend and frontend for the majority of the functionality. It then starts in on the technical parts to connect the two halves:

• adding the required routes
• creating the controllers
• building out the views to render the interface

The majority of the post is then dedicated to the creation of the assets - the Javascript and CSS - to create the "framework" the functionality will use to work with the translations.