In this post on his Medium blogINANI El Houssain shows you how to create a custom directive for use with Laravel's Blade templating language. In this example he shows how to make a custom switch statement, something commonly used on the PHP side to select an action based on a value.

One of the good points of Laravel’s framework is that it allows you to make your own components, macros and directives. so today we will make use of Laravel’s Custom Blade directives and make something good.

He starts with a simple "hello world" example to show where the pieces all live, outputting a simple "Hello $name" string. He then moves into the creation of the "@switch" directive having it write out the PHP code required for the switch to start and end. He adds in two more tags to start and end the different cases: @case and @endcase. The post wraps up with an example of all of these tags in use and how to catch when the value under evaluation might be empty.

On the Tighten.co blog they have a recent post sharing a better dd() for your TDD - basically a better method for debugging the current state of object with a "dump and die" function.

An important part of every Laravel developer's debugging arsenal is the humble dd() helper function—"dump and die"—to output the contents of a variable and terminate execution of your code. In the browser, dd() results in a structured, easy-to-read tree, complete with little arrow buttons that can be clicked to expand or hide children of nested structures. In the terminal, however, it's a different story.

[...] Fortunately, it's simple to build your very own customized version of dd() to help tame your unwieldy terminal output—helping you find the details you're interested in quickly, without wearing out your trackpad (and your patience).

He provides two options you can use to help clean up the output of a "dump or die" method from the extensive results the current "dd" function provides:

The Master Zend Framework site has posted a new tutorial for those out there looking for a bit more from their error handler than just some basic text. In this tutorialMatthew Setter introduces you to the Whoops error handler and how to use it in your Zend Expression application.

Ever experienced HTTP 500’s, but found that your error logs are empty. Ever had no clue why or how this could be happening? Perhaps you forgot to enable the Whoops error handler.

That’s right, perhaps, when you were setting up a Zend Expressive application, you made the mistake which I made recently when you used the Zend Expressive Skeleton Installer. [...] If you chose n, and used a templating engine, then TemplatedErrorHandler, would have been used as PHP's default exception handler.

As a result, no exceptions will be written in your logs. Sure, you’ll see that a 500 error has occurred somewhere in your application. But, the only information you’ll have is [a simple 500 error message].

He notes that the next step for most developers is the log files, trying to find a hint there of what might have broken. If you chose the default logger, nothing will be there as it captures those issues and pushes them to the basic error template (but doesn't output them). He points to where in the configuration you can check to see if you enabled the Whoops error handler and how to test it after you've made the switch. The reason the default is the basic message is that, in production, you don't want information exposed and log messages/code shown to just anyone - that's a big security risk.

In a post to his site Alejandro Celaya shares a method he worked up for creating a content-based error handler in Zend Expressive - a method of changing the error output based on the content it was passed and the Accept header provided.

In one of my tests of the REST API I saw that when an error occurs (404, 405 or 500), I was getting an HTML response, which is not easy to handle when the client is expecting JSON.

I started to dig on how to fix this problem and thought that using ErrorMiddleware (which is invoked in case of an error) should be the solution, but after some tests I saw that it is only invoked if a regular middleware invokes the next one by passing an error as the third argument or an uncaught exception is thrown. When a route is not matched (404) or it is matched with an incorrect HTTP method (405), the error middleware is not invoked.

After confirming (on Twitter) that this was the intended result he went about looking for another option. He looked into using "Final Handlers" that are called when nothing else matches in the middleware execution chain. They didn't provide one for JSON handling, however, so he had to create his own (code is included in the post) and explains a bit of how it's handling the data and HTTP response code. Unfortunately using this handler made the error output always return JSON so another piece was needed, the content-based detection handler that switches between types based on the Accept header.

In a tutorial posted to the SitePoint PHP blog Claudio Ribeiro tries to answer the question of "who watches the watchmen" (your application's tests) to ensure they're functioning as expected and are correct. In this new tutorial he introduces the Humbug mutation testing tool and how it can be used to verify your own tests.

Regardless of whether you’re working for a big corporation, a startup, or just for yourself, unit testing is not only helpful, but often indispensable. We use unit tests to test our code, but what happens if our tests are wrong or incomplete? What can we use to test our tests? Who watches the watchmen?

[...] Mutation Testing ( or Mutant Analysis ) is a technique used to create and evaluate the quality of software tests. It consists of modifying the tests in very small ways. Each modified version is called a mutant and tests detect and reject mutants by causing the behavior of the original version to differ from the mutant. Mutations are bugs in our original code and analysis checks if our tests detect those bugs. In a nutshell, if a test still works after it’s mutated, it’s not a good test.

He starts by helping you get it installed (a quick composer require) and creating a simple "calculator" test to show it in use. He then creates the test for the class with some simple testing methods for the basic calculator functionality. He then configures the Humbug installation (via a JSON config file) and executes it on the current tests, sharing the resulting output. He goes through the results showing how to interpret them and points out places where the tests could be improved.

On the TNT Studio site they've posted a tutorial showing you how to automate scheduled tasks and output to Slack, the popular online communication tool (think IRC for the web). They show how to use a simple webhook setup to relay the results of a task back to a given channel.

What many of us grow accustomed to is having cron job output emailed to us in order to see if everything went ok. Laravel's task scheduler also supports emailing output of the commands but if you are like millions of developers out there then you are probably using Slack and it's possible that it crossed your mind that it would be great if we could get output of the cron command sent to Slack. So let's do that.

They then walk you through the setup of the Slack notifier class to send the data to Slack via a Guzzle POSTed request. The next portion puts this code to work and creates the code to execute the command and return the results. The "after" event is then used to make the Slack request and output the results to the waiting channel.

On the TNT Studio site they've posted a tutorial showing you how to automate scheduled tasks and output to Slack, the popular online communication tool (think IRC for the web). They show how to use a simple webhook setup to relay the results of a task back to a given channel.

What many of us grow accustomed to is having cron job output emailed to us in order to see if everything went ok. Laravel's task scheduler also supports emailing output of the commands but if you are like millions of developers out there then you are probably using Slack and it's possible that it crossed your mind that it would be great if we could get output of the cron command sent to Slack. So let's do that.

They then walk you through the setup of the Slack notifier class to send the data to Slack via a Guzzle POSTed request. The next portion puts this code to work and creates the code to execute the command and return the results. The "after" event is then used to make the Slack request and output the results to the waiting channel.

Andrew Carter has written up a new post about PSR-7 objects (the PHP-FIG defined standard for handling requests and responses in PHP applications) and how the objects themselves are immutable.

What’s happening [in the provided example] is that the Zend Expressive framework is rendering the error page to the same object that you wrote your message to. Whilst the actual message object itself is immutable, the body stream that it references is not. Even when this object is cloned or “modified” (to become a new object) it will still use the same stream.

He explains a bit about what this means in a more practical sense and why the PSR-7 standard and why this happens (as defined after much discussion). Then he gets into a more recent debate happening in the PHP-FIG about PSR-7 middleware and the proposal for a standard structure in its creation. He points to some of the thoughts from Anthony Ferrara on the topic and an example from Woody Gilk showing an exception handler and how having the stream always appending content is a bad thing in that particular case.

In a recent post to his siteJeff Geerling shows you how to disable the output buffering that PHP includes and create "streaming PHP" code similar to Drupal's recently introduced BigPipe handling.

For the past few days, I've been diving deep into testing Drupal 8's experimental new BigPipe feature, which allows Drupal page requests for authenticated users to be streamed and loaded in stages—cached elements (usually the majority of a page) are loaded almost immediately, meaning the end user can interact with the main elements on the page very quickly, then other uncacheable elements are loaded in as Drupal is able to render them.

[...] BigPipe takes advantage of streaming PHP responses (using flush() to flush the output buffer at various times during a page load), but to ensure the stream is delivered all the way from PHP through to the client, you need to make sure your entire webserver and proxying stack streams the request directly, with no buffering.

He decided to try out different configurations to see if he could reproduce the same thing outside of Drupal and - good news, everyone - he found a reliable way. He starts with a basic procedural script that emulates BigPipe and calls a flush inside a loop to push the latest output to the waiting client. While this cooperates on the command line the browser doesn't cooperate the same way. A small tweak helps it work, so he shows how to reproduce this reliably across the full stack - Nginx, Apache and Varnish.

He ends with a quick warning for those using VMWare/VirtualBox about some oddness he experienced in buffering the responses and includes a way to test if it's your script or the VM causing the trouble.

Virtually every website displays some sort of menu. Generating html menus might seem simple, but it can become complex very quickly. Not only do you have to render some basic html, but you also have to manage which item is active. If a menu has a submenu you’ll also want the parents of an active item to be active. Sometimes you want to insert some html between menu items.

There are some packages out there that can help generating menus, but most of them have a messy API or have become victims of feature creep. Thanks why we decided to create our own modern menu package that has a beautiful API to work with.

He spends the rest of the post introducing the package, starting with the generation of a basic menu (and something a bit more complex). He also shows the use of the isActive method call to mark something as "active" but the package will handle that automatically for you if you'd like to keep it simple. He ends the post with a listing of the components that make this menu handling work (three of them) and some of the "modern PHP" functionality that they use.