On the CodeWall.co.uk site there's a new tutorial showing you how to use Eloquent outside of Laravel applications thanks to its "capsule" functionality. Eloquent is an ORM layer that's a part of the Laravel framework and makes it easier to work with records and sets of data from your database.

OWASP (Open Web Application Security Project) is a project that notes down the current threats to a web application. And I have been researching on their site and I have found this similarity in their 2010, 2013 and 2017 report that, SQL Injection or any other type of Injection is number 1 on this list, every time.

And that’s a part to worry.

This can cause you to get out of business, so this is pretty serious and your organisation should take care of the this issues and prevent yourself from it.

The tutorial starts with a brief introduction of what SQL injection is including some example SQL to show how the injection happens. It then covers how to prevent this issue with base PHP code (no framework or package) using prepared statements and bound parameters. Eloquent takes care of this for you and provides a lot of other handy features. The article goes on to show:

• how to install the Eloquent packages with Composer
• the code to create the "capsule" that's used as a bridge into the Eloquent code
• the creation of migrations for two tables: users and posts
• how to make models for these two tables

The post wraps up with a look at using these models to create a new user and post record using the ORM interface rather than manual SQL statements.

The Pineco.de blog has a tutorial posted showing Laravel users how to append API and web routes to Eloquent models directly without the need for setting up additional route handling.

As a level zero, we can agree on using the RESTful URI scheme. That means every model has an associated route. We can perform different actions on the model, depending on the request type.

It can be a bit painful to concatenate the strings and IDs all the time, so we could append this URL as an attribute of the model. That means we could calculate the URL behind the scenes, and use it on the PHP or the JS side as well. [...] Then only difference (in this simple example) between the API and the web routes is that the API routes have a /api prefix in the URL.

The tutorial then introduces their custom Routable trait that can be included in any model to handle requests on both the API and web side (differentiated by the "api" prefix). The last step is to append the routes to the model itself using the appends Eloquent property.

Ben Sampson has a tutorial posted to his site for the Laravel users out there sharing some tips about speeding up your database queries when using relationships between models.

Adding indexes to your database tables is a great way to get some extra performance out of your application, especially if you have a large amount of data in your tables. They should be used sparingly and only on identified slow queries, as they have implications of their own such as increased table size and increased RAM usage. But those potential drawbacks are well worth it when you can get a query down from a 3 seconds 15 milliseconds with 5 minutes of work. The effects are particularly noticeable on polymorphic / many to many polymorphic relationships.

He then includes the code required to create the indexes on your tables (either a single column or a compound index involving more than one column) in your migrations. He also provides code examples showing how to use foreign keys to improve one-to-one/one-to-many relationships. More examples include optimizations for many-to-many relationships and polymorphic relationships.

On the Laravel News site, there's an article posted covering the use of factory callbacks and closures in guards in Laravel. This feature was snuck into a recent release and allows you to provide a bit more dynamic functionality to your models and guards.

Two undocumented (before today anyhow) features were recently added to the Laravel 5.6 documentation, and they are both fantastic!

The post details each of the two new additions starting with the factory callbacks allowing you to perform additional tasks when a model is made or created (code examples included). The guard changes allowing closures and the Auth::viaRequest method to define new guard drivers.

In a post to his site Ben Sampson shows how to mask IDs in URLs using hashids in a Laravel-based application. Hashids converts values into strings that can then be decoded back to their original values.

By default a URL generated by a Laravel app will contain the ID of a model like this https://app.name/users/1 where 1 is the ID of the item. Often this is absolutely fine, but sometimes you might want to hide it (or obfuscate it). The two main use cases for this I've come across so far are: Security [and it looks] More professional.

He shows how to use this package to encode and decode ID values in your URLs. He also includes updates to the models, controllers and routing to use route model binding to handle the encode/decode process. He shows how to set up different salts for different data types, setting it on each model and how to correctly bind the functionality in the main route service provider.

Junior Grossi has posted a tutorial that covers the idea of data filtering with Eloquent models. In this case, the filtering is based on user input from a URL with parameters matching the properties on the model.

Filtering models was, for a very long time, a hard task for me. I admit that I could not think in some easy way to do that. I tried, refactored some code, created custom classes for that, but I never thought how this could be easily implemented.

Watching a Laracast’s video from 2016 about the Laravel’s Eloquent ORM I faced of with a bunch of classes and a trait that removed a lot of trash from my controller actions. That was called by Jeffrey Way the QueryFilter.

He then gets into some of the goals behind the filtering and the expected input method (URL parameters). He then creates a simple Laravel application making use of Corcel to integrate with his current WordPress backend database. He includes code examples showing the creation of a Post model and controller and returning only the desired fields using a JSON response and a toArray method. He then moves on to the filtering, starting with a more hard-coded version of the search: adding a where statement to the query manually before the get.

To replace this with something more flexible, he implements the QueryFilter class that can be extended to match the requirements for the model type. He then implements the PostFilter class, adding methods for "status" and "title" fields. Finally he adds in a scopeFilter method that makes it simpler to call the filtering directly from the model instance.

The Laravel News site has posted a tutorial that takes you deeper with factories when using the framework looking at the factory states.

I suspect that if you are familiar with Laravel that you might use factories and possibly even factory states in your application development. The documentation shows you the mechanics of using factories to seed and create test data, but there are a couple of guiding thoughts to using factories with your models effectively that I’d like to consider.

He starts with two options he sees for using factory states: making them with static values or using them to make simple models instead. He goes through these two options, introducing some of the basic concepts of each, how it would work and the code to make it happen. He also covers a few other approaches including the use of a trait to include the factory functionality directly in a class. He finishes the post with a few links to more information in the Laravel manual and other outside resources/tools.

Matthias Noback has a new post on his site with his thoughts about the design of value objects. He makes use of an example he recently saw in the code he was working with: the idea of "quantities" of items.

I recently came across two interesting methods that were part of a bigger class that I had to redesign. [...] What happens [in the methods] is: we have an order line, which keeps track how much of a certain product has been "ordered", and then how much of it has been "delivered" so far. It also keeps track of how much is currently still "open". Changes to these "delivered" and "open" quantities happens when we "process" a delivery, or "undo" a delivery.

I was reminded of a recent blog post by Nicolò Pignatelli where he quoted a question from another programming website. Adopted to the situation at hand: "Which variable type would you use for representing a quantity? Integer, Float or String" It's a trick question, because all the answers are wrong. Nicolò advises not to use a primitive type value, but to design a value object that can represent a quantity.

He then walks through the process for refactoring this quantity handling out into a value object replacing the current float handling. He recommends applying more thought to how the object will be used and how the different types (open, ordered and delivered) relate to each other. He also includes examples of how to replace the add/subtract operations in the original code while still using value objects as immutable constructs.

The Laravel News podcast, hosted by Jacob Bennett and Michael Dyrynda, has posted their latest episode - Episode #59: Scaling Laravel, testing Vue components, and model events

Join Jake and Michael as they discuss the latest Laravel releases, Scaling Laravel, testing Vue components, and more.

Other topics mentioned include the announcement about Let's Encrypt wildcard certificates and how to use Font Awesome 5 SVGs with Laravel Blade. You can listen to this latest show either using the in-page audio player or by downloading the mp3 directly. If you enjoy the show and want to hear more, check out their archives at the bottom of the page and subscribe to their feed for updates on new shows as they're released.

The Laravel News site has a tutorial posted that introduces you to model events in Eloquent models and how to use them effectively in your code.

Laravel Model events allow you to tap into various points in a model’s lifecycle, and can even prevent a save or delete from happening. The Laravel model events documentation outlines how you can hook into these events with event classes, but this article aims to build upon and fill in a few additional details on setting up events and listeners.

The article starts with an overview of the different types of events available on the models and a brief summary of when each are fired. It then walks you through the process of registering events and where to configure the event-to-handler relationship. The artisan make:event command can then generate the skeleton code for you. In this class you can then add the handler method and then configure it in the providers. Finally it shows an example of how to test the event, stopping the save event and using observers to group the event handling.