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.

Freek Van der Herten has a tutorial posted to his site sharing some customizations you can make to PHP code generation in PhpStorm to fix some issues he's noticed in his own development work in the IDE.

I've been using PhpStorm for quite some time now, but never took the effort to fix a few minor annoyances I had with it.

He shows how to change the generation for:

• Getting rid of the default comment for new PHP files
• Compact docblocks for instance variables
• Fixing the placement of the caret
• Using fully qualified class names in doc blocks
• Changing the default visibility

The final item in the post isn't so much a code generation change as it is a tip for saving these changes and your other configuration options. He shows how to back them up on a git repository out on GitHub.

On the Laravel News site they've posted a quick tutorial showing you how to change the path to views in a Laravel-based application.

In response to our post yesterday about Laravel 5.7 Resources Directory Changes, a reader mentioned that they would prefer to have their application views outside of the resources folder.

I thought I’d write up how you can customize the view path; it’s effortless with Laravel!

The change is made in the views.php configuration file, updating the value for the paths setting. You can point it to a single location (like the application path or resource path) or you can set multiple to tell the framework to search for the view in either. The post ends with a mention one thing to keep in mind about generating views and their location (and moving them around).

Alejandro Celaya has posted a new tutorial on his site showing how you can customized the "not found" and "not allowed" responses in a Zend Expressive v2 application based on the needs of your application.

Sometimes the nature of an application requires you to change the default framework's way to structure error responses (like 404 and 405).

On this article I'm going to explain how to customize those responses when working with Zend Expressive 2. [...] In Expressive 1, error handling was different. [...] In expressive 2, the error handler is gone, replaced by a middleware which catches exceptions and lets you generate error responses.

He notes that this new middleware approach (moving away from the error handler) doesn't deal with 404 and 405 errors anymore, they've been split out into other functionality. As these other middleware options allow for a custom PSR-7 response object to be injected, he sets up two "delegates" that will more correctly handle the response. He includes the examples code for these and shows how to hook them into the current Expressive execution flow.

On the Laravel News site there's a recent post showing a feature coming in version 5.5 of the framework that will help make creating error views easier:

Coming in Laravel 5.5 is a new and improved design for the error pages. The default errors will extend from an errors::layout file and get some small design additions over the current style with flexbox and a vertically centered message.

They compare the older version to the newer, cleaner one and how you can still, even in 5.5, have your own custom error pages named based on the HTTP error code (like 500.blade.php or 403.blade.php). They end the post covering the renderHttpException and how it determines which of the error templates to use.

Matt Stauffer is back with another in his series of posts about the new features coming in the v5.3 release of the popular Laravel framework. In the latest post he looks at pagination improvements allowing you to customize the related templates.

Laravel's pagination library is brilliant, because pagination is a common task that is a surprising amount of work to implement. In the past, if you wanted to customize your pagination templates, it was just as simple to customize your pagination template as it was to work with the rest of the pagination library.

However, for the sake of making the pagination library easier to extract for non-Laravel projects, Laravel 5.0 (or maybe even earlier?) introduced a much more complex—but more portable—system for pagination templates. Thankfully, in Laravel 5.3, we're going to go back to how it always was: simple and easy.

He then gets into the basics of how pagination works in Laravel applications (not the template part, the backend) using the Task::paginate handling. He includes the view to just show the results and the current view handling for the pagination links. Finally he shows how to customize the template in v5.3 by registering a custom view to the partials.paginator and using the links method to inject them into your current template.

Adam Wathan has a new post to his site talking about mapping with collections and customizing the keys when injecting new data into your Laravel collections.

People often ask me, “how do I specify keys when I’m mapping a collection?”

It actually ends up being a pretty interesting topic, so I decided to cover it in a short screencast, as well as in written format below.

He shows how to translate a simple set of data into a much more slimmed down version. He points out that the "map" function could be used but it doesn't allow for setting keys. Instead he talks briefly about how the problem could be solved in Javascript (returning an object instead of an array) and how to use the "reduce" method to filter and reset the data as it goes through the array. He finishes out the post talking about learning from other languages, the "toAssoc" macro on Laravel collections and mapping the data back to an array with a custom macro.

In a new post to his site Matt Stauffer revisits the topic of "strict" mode with MySQL and Laravel with some customizations you can make around how your application uses it.

If you remember my post How To Disable MySQL Strict Mode on Laravel Forge (Ubuntu), you'll remember that MySQL 5.7 introduced something we've been casually calling "strict mode," which is really a combination of new modes that, in sum, make MySQL process your queries a little more strictly than before.

In my previous post I showed how to disable it on Ubuntu, but since then, Adam Wathan has added a feature to Laravel that allows you to define whether you're using "strict" mode and also allows you to customize exactly which modes you'd like enabled--all in code.

He briefly goes back over what the "strict" in "strict mode" means for your database and application, including a list of the set of modes it contains (essentially a grouping of modes). He then shows how to use the new feature to enable/disable it in a Laravel (5.2+) application through the database configuration. You can also get more in-depth and enable/disable individual modes that the "strict" mode contains if you need a bit more custom handling.

In a post to the Sylius blog Mateusz Zalewski shows you how to create configurable emails in your Symfony-based application with help from a custom bundle they've released to help make it a much simpler process.

Every developer, during their adventure with PHP programming has been struggling with sending emails in a web application. However using PHP send() function is often insufficient for common web applications, when you need templates, variables, configurations etc.Fortunately, Sylius provides SyliusMailerBundle and Mailer component, with some awesome features. [...] Of course, this bundle and component are fully decoupled and can be used in any Symfony application.

They walk you through the installation (via Composer) and configuration of the bundle, adding it's dependencies to the kernel of your application. He shows how to configure the container with connection information (like the name and from values) and update your database with the tool's migrations. From there he shows how to customize your emails, making use of the Twig template handling to define the body contents. The bundle also makes it possible to define custom email types with different settings for each. Finally they show how to send the emails, grabbing the sender information and sending the email, either more manually or via a custom defined email type.

If you're a Codeception user, you'll find Matthew Turland's latest post interesting. In it he shares a way to customize database cleanup between the tests. Codeception handles it a bit differently that how PHPUnit's Db module does.

Recently, I was looking into ways to speed up the runtime of the test suite at Blopboard. We use the Codeception framework to write functional tests for our REST API, part of which entails putting the database into a known state using Codeception’s Db module. The behavior of this module is similar to that of the PHPUnit Database extension with one exception: where PHPUnit only truncates tables and leaves their schemas intact, Codeception removes the database structure and expects the SQL dump it uses to recreate it between tests. I must admit to not understanding this design decision of Codeception, nor attempts to clarify it.

He admits that his solution is "a bit hacky" but it does work to truncate the table rather than drop the entire schema and wait for a rebuild. His "DbHelper" class is used in place of the Db module. He traced through the execution path of the Db module and found a "hook" where he could override the "cleanup" method to prevent the schema drop and replace it with a truncate. He also includes code for a suggested addition to Codception that would handle the same thing in a more integrated way.