On the Laravel News site there's a new post looking at the use of user-defined schedules and some of the "hidden" features the Laravel framework provides to allow for even more customization.

Recently Adam Wathan and Taylor Otwell have used Basecamp to track what they are doing every day–a tech diary. Notably, they are using the check-in feature which allows you to schedule questions to be sent to members about almost anything. Taylor and Adam are using it for “What did you work on today?”

It’s not that it’s the same time of day or even that it’s only weekdays which peaked my curiosity but the fact every check-in has a custom schedule defined by a user. In Laravel, we can quickly schedule a job to run every weekday at 4 pm, and we can use a custom timezone. But out of the box, we cannot set a different schedule for every individual check-in. We would have to store a cron expression and manually check every minute if it’s due.

After some "source code diving" the author figured out that the Schedulable trait allows you to define a more customized version of a schedule to fit your needs, making it simple to implement in any class or model. Code examples of these changes are included in the post as well as some next steps to have it implemented more widely either in the Laravel core or a package.

On the Pineco.de blog there's a new post for the Laravel users out there showing you a simple way to integrate translations handling into your models. This functionality allows you to more easily build multilingual applications without having some of the overhead of a separate translation framework.

Making you models translatable could be an issue, especially if you are running an application that is multilingual. For static texts, we can use the built-in translation engine, but for models, we need to solve a more complex issue. Let’s take a look at a simple yet flexible solution.

While the post starts with a recommendation to use a full package if you need a more robust system, it quickly moves into the simpler structure they'll be defining. The tutorial describes the "translation mechanism" from a high level and includes the code to create the database table for holding the translated content. With that in place, next up is the model to connect the application with the table and a trait to house the translation logic. This is then used directly in the template (as a translation property) to fetch the translated version of the content.

Freek Van der Herten has posted about a new package that's essentially a stand-alone version of Laravel's own "macros" functionality available via a package: macroable.

We recently released our newest package called macroable. It contains a trait that, when applied to class, can dynamically add methods to that class. This trait is basically a stand alone version of the macroable trait in Laravel. In this post I’d like to show you how you can use it, how it works behind the scenes and explain why we created it.

He then gives examples of how it can be used to add a new simple method (essentially a "named closure") and using the "mixin" functionality to add multiple at once. He wraps up the post with a look at how it works behind the scenes, adding the items to a "macros" list and then looking them up if they're not defined on the class.

In this post to his site Nicola Malizia briefly helps you understand the Laravel "macroable" trait - what it is and how to can be used in your own code.

If you check the Laravel codebase I’m sure that you can observe that Laravel makes use of traits.

There is one trait in the source code that pulls my attention. I’m talking about the Macroable trait. In case you don’t know, you can define custom responses using macros.

He includes an example of extending the default Response class with a "caps" macro and how it would then be used in the resulting object. He talks about how traits work in PHP OOP code and how they can be used to "inherit" functionality into a class. The "macroable" trait then uses the __call magic method to do its thing, looking for macros that match the function being called.

Dave Marshall has written up a post showing how you can use closures with PHPUnit to provide "after" hook functionality.

Not sure why I didn't start doing this sooner. We have a basic Feature toggle system that is maintained in the global scope to make it easily accessible to any part of the code. [...] I needed to force a particular feature on in a PHPUnit integration test, but in order to tidy up after myself, I would need to ensure that the test reset the Feature system after it had finished. There are a few ways of doing this.

The first of the three, using PHPUnit's own global state handling comes with its own set of problems. The second was to use a try/catch block in the test to ensure the state is reset and a third was to use the "tearDown" to reset everything accordingly. He ended up finding what he needed in the form of "runAfterHooks" handling in a trait, passing in the closure to be executed.

On the Laravel News site there's a quick post looking at Laravel's login validation and how you can make updates to its handling (and where the changes should be made).

Laravel’s included auth system is a great way of scaffolding out a basic flow for authenticating users through a complete registration, login, logout, and forgot password system.

When it’s all setup the login and password reset validation is stored in an AuthenticatesUsers and ResetsPasswords trait. Even though it’s a little hidden away it’s still easy to adjust this to your needs. Let’s take a look at how to adjust this.

The post then breaks each of these down, showing where in the framework source the code lives and how you can update or override the current handling. The login validation lives in the default "AuthenticatesUsers" trait and the password reset verification is in "ResetsPasswords". These can each be overridden in your own controllers as they're just methods included via traits.

Freek Van der Herten has a post to his site showing how PHP functions can (sort of) be overloaded with the help of a trait from Adam Wathan.

PHP does not support method overloading. In case you’ve never heard of method overloading, it means that the language can pick a method based on which parameters you’re using to call it. This is possible in many other programming languages like Java, C++.

However, with some clever coding, Adam Wathan made a trait, aptly called Overloadable, that makes method overloading possible. It works by just accepting any parameters using the splat operator and then determining which of the given functions must be called according to the given parameters.

He shows how to use the trait in a simple example, defining a single "bar" function and using the "Overloadable" trait to handle the switching between the methods based on the input variables. You can find more information about the trait and the source for it in this gist over on GitHub.

The QaFoo blog has a new post today showing you how to use Mink with PHPUnit. Mink is a testing tool that allows you to write tests as if they were happening through a browser.

Another day for a short PHPUnit trick. If you want to use PHPunit to control a browser for functional or acceptence tests, then you can easily do this using the Mink library. Mink is well known from the Behat community to facilitate Behaviour-Driven Development (BDD), but it is a standalone library that can be used with PHPUnit just as easily.

This is more flexible than using dedicated browser abstractions such as Selenium directly from PHPunit, because you can switch between different implementations or even run tests with multiple implementations using the same code base.

They start with the command you'll need to get Mink installed via Composer (a simple require) and come example code for a test on the Wikipedia site (the page about PHP). They then refactor this a bit to remove the boostrapping of the Mink client into a reusable trait, making it simpler to use in other tests. They also refactor the test to use the trait and include the phpunit.xml configuration needed to run it.

Hannes Van De Vreken has some advice for the PHP developers out there working on projects that make use of some form of abstraction - don't over-abstract. In his case, he's talking more about the use of abstract classes and where they fit into a good overall project structure.

Some time ago I started working on an existing project, so I read the documentation before diving in. At the top of the contributing.md file there was this sentence: “Abstract when possible”. Quickly I learned the project contained more abstract classes than a normal project. This leads to too highly coupled, and often unchangeable code.

This post is dedicated on explaining why “abstract when possible” isn’t good advice. Not only in PHP, but in all programming languages.

He starts with some of the common issues he sees with abstract classes including the over-complication of abstract methods and defining all dependencies the children need even though the abstract class doesn't. To help resolve these issues he recommends the use of traits. These traits include the dependencies needed by the child classes (for example only things needed for a CSV export, not other types). He includes all the code for this particular example. Finally he looks at situations where abstract classes are okay to use. He uses the LeagueEvent package as an example, showing how it creates a listener interface and an abstract class that contains an equality check function. He shows how to refactor this as a trait too.

On the HHVM blog there's a recent post looking at some of the requirements around traits and interfaces in the Hack language. More specifically, they talk about type checking with traits and how interfaces can be used to help provide extra structure.

In PHP, traits are a mechanism of code reuse that, while very powerful, are also difficult to type check both efficiently and exhaustively. In this post we’ll dive more deeply into the reasons for that and see how Hack solves those problems, allowing you to use traits in a safe way without limiting their expressiveness.

They start by talking about the main problem with PHP's handling of traits (essentially copy and paste into the current class) and how they felt Hack should "just work" in allowing type checking on these "pasted" methods too. Performance limitations prevented them from handling it how they do with other variable types, so they changed things up, using a "require extends" syntax to tell the Hack engine how to allow the checking based on an interface. There's a lot more to it than this, so be sure to read the rest of the post on how they came to that conclusion.