On the Pineco.de blog they've posted a new tutorial showing how to extend the Collection functionality of Laravel with the help of macros.

Collections are fantastic features of the framework. With the functionality that the collection offers, we can easily handle any need that a dataset requires. But still, in some cases, we may extend with custom functionality.

The post starts with a more general look at what collection macros are and a few code snippets of them in action. To illustrate how to extend them, they create a "some" macro that takes in an anonymous function containing some kind of logic to check the key/value passed to it and return a boolean. The post finishes up by linking to the macro documentation and another package that implements a wide range of additional macros (like "extract", "paginate", "tail" and "transpose").

Mark Baker has an interesting post to his site where he shares a suggestion for making it easier to create unit tests for some of the more difficult parts of your unit tests. In the article he shows how to extend final classes and methods by manipulating the AST (abstract syntax tree structure) of the current code under test.

We know that we should always write unit tests for our code, and mock dependencies; but that isn’t always easy when we need to mock classes define as final, or that contain final methods. This isn’t normally a problem when we’re only working with classes within our own libraries and applications, because we control whether they are final or not, and we can type-hint these dependencies to interfaces. However, when the dependencies that we use are from external libraries, we lose that control; and it can become harder to test our own classes if we do need to mock final classes and they haven’t been built to interfaces.

He talks about how one tool, Mockery, allows some of this with its functionality but can still cause issues when mocks are passed instead of actual class instances. He then starts on a solution he has been trying to implement - a mocking library that makes use of the PHP_Parser package to make it possible to modify the structure of the code itself, not just put a wrapper (mock) around it. He includes a bit of code showing how to use that and the BetterReflection library to do some class introspection, locate files for testing and how to the tool to "de-finalize" a class (make it no longer "final").

On the Tighten.co blog there's a new tutorial posted by Caleb Porzio showing you how to correctly extend Eloquent models in a Laravel application.

When starting out with Eloquent, it’s natural to reach for familiar operations like where and join. For more advanced users, features like scopes, accessors, and mutators offer more expressive alternatives to the query-building patterns of old.

Let’s explore another alternative that can be used as a stand-in for repetitive where statements and local scopes. This technique involves creating new Eloquent models that extend other models. By extending another model, you inherit the full functionality of the parent model, while retaining the ability to add custom methods, scopes, event listeners, etc. This is commonly referred to as “Single Table Inheritance,” but I prefer to just call it “Model Inheritance”.

He starts with an example using the User model and creating a "local scope" method to answer the "is admin?" question. He then abstracts this out even more with an Admin model that extends the User that can be used instead to refer to admin users only. He includes examples of this in use for notifications, guard classes and model factories. He ends the post with one "gotcha" to this method - the fact that relationships no longer work on the Admin model - and how to work around it.

In a new post to his site Cees-Jan Kiewiet walks you through the process to extend the ReactPHP project's child process handling (the first part of a series of posts).

react/child-process is very flexible and can work a lot of ways but sometimes you don't want to be bothered with the details of how it works and just want a simpler API to do that.

He then covers two packages where he used this "simpler is better" mentality and wrapped the current ReactPHP handling in a simpler API: one for defining "promises" on the child process and the other handles the messaging between the child and parent processes. He includes code examples for each of these, showing them in use to create simple operations.

On the Tighten.co blog there's a recent post showing off some of the magic of Laravel macros and how they can make extending the basic framework functionality simpler.

Ever wanted a piece of functionality in a part of Laravel that doesn’t exist? Let me introduce you to Laravel macros. Macros allow you to add on custom functionality to internal Laravel components.

He gives an example of adding a simple "introduce" macro on the Request facade and how to put it to use. He refactors this into something more useful: returning a true/false result when checking the TLD on the current domain. He includes the code to set up the macro in the AppServiceProvider and the addition of an enhancement that adds a "where" clause to a model query when the TLD matches. He wraps up the post giving some guidance on where they should be defined and what components in the Laravel framework are "macroable".

The SitePoint PHP blog has a new post today helping the users of the OctoberCMS content management system build a "soft delete" plugin by extending the functionality already included in the code.

Developers usually stick with a new CMS for its simplicity and extensibility. OctoberCMS presents itself as a back to basics CMS, and provides an enjoyable experience for both developers and users. In this article, I’m going to demonstrate some aspects of the CMS that make it extensible, and we’ll also try a simple plugin to extend another plugin functionality.

The tutorial starts by talking about extensibility and how plugins play into it in most normal CMS software (in their example, its listening to an event fired when a new post is made). They start by creating a new plugin skeleton via the "create:plugin" artisan command and creating a migration to extend the database with the "soft delete" column. After running the migration, they add in a new listener for an "extendColumns" event and extending the filter to extend the scopes pulling out posts data. They further extend the functionality with a helpful trait filtering the data by the "deleted_at" value and adding that into the scope as well. Finally they add a listener onto the Eloquent events for the "deleting" event to capture it and set the "deleted_at" value on the post record and save it.

Kristopher Wilson has a quick post talking about how he thinks you can use interfaces effectively in PHP applications.

Yesterday, a question appeared on Reddit about the purpose of interfaces in PHP. While I was too late to the party to provide an answer to that thread (at least that would get noticed by anybody), I thought it was a great topic of conversation. So let's take a look at interfaces in PHP.

He introduces some of the basics around interfaces and provides some sample code showing how they're created and used (and extended). He talks about some good practices for implementing them in your classes and how this fits into the world of dependency injection. He also includes a bit about type hinting based on the interface implemented and how they can be seen as "contracts" in your code.

Matt Stauffer has a new post to his site today showing you how to extend Laravel's Application class to enhance its handling with other handy features.

It's seldom that we need to extend Laravel's core, and even when we do, it's most likely we're going to extend specific components, which is detailed in the docs. However, all of these instructions presume you're using the core Laravel Application (IOC Container) to extend the other classes. What if you want to extend the Application itself?

The example he provides is from his own real-world experience, based around changes they wanted to make in the default folder paths for things like the "storage" or "public" directories. He shares the three simple steps to making this custom handling work:

• Extend the class
• Register it in your application's bootstrap
• Override/extend the current methods to add in your own functionality

In this case, changing the default paths is something that's under discussion already, but it gives a good simple example of changing that default functionality.

NetTuts.com has a a recent tutorial showing you how to show the metadata from a posting in WordPress right along with the other post data.

During the course of the series, one of the things that we did in order to help demonstrate the object-oriented principles as well as some of the features of the WordPress API was build a plugin. Specifically, we built a plugin that allowed us to view all of the post meta data associated with a given post within the WordPress dashboard. [...] Since that particular post was written, I've received a number of different questions one of which has been how do we take the data displayed in the dashboard - that is, the post meta data - and display it on the front end of the web site. In this article, we're going to take a look at extending the plugin such that we can display the data on a single post page.

To display the data, they actually extend the plugin they've already made. They start with some of the issues of this method (and the data itself) that you might run into during the development. They create a "public" directory to store the cached metadata in and a manager class to handle the functionality. The class loads the data and uses output buffering to capture the data. A public hook is defined to call the "display" action on each page load and the results are passed out to the view.

In this recent post to their site, Easybib shares a presentation and the answers to some questions about extending Composer, the popular package management tool for PHP.

Composer is one of the core tooling we use at EasyBib when we work on the various products for the company. [This] deck of slides is from a talk I gave at the Berlin PHP Usergroup meetup in November. [...] In addition, there were a few questions how dependencies are handle in a project when installed through composer’s global command.

They answer questions about loading global vendors (and what should/shouldn't be installed this way) as well as which one wins - the globally installed version or local.