The Laravel News site has published the latest part in a series covering the creation of a translation package for use in a Laravel-based application. In this new post they focus on how the package will handle missing translation keys.

In the last installment of this series, we talked about building the frontend translation management tool. In this article, we are going to move away from the frontend and follow the process of building another backend feature.

One of the most frustrating things about translation management in a Laravel application is forgetting to add translations to the corresponding language file. This has the undesirable result of either the translation key or the default language being rendered on the page rather than the translation for the current language.

To remediate this issue, they design the package so that it will search the whole project and return the keys that don't have translations currently defined. They walk you through the creation of this functionality complete with the configuration and code required to locate the missing translations and update the configuration to add them.

Rob Allen has a new post to his site sharing a method you can use in your testing to replace a built-in PHP function with something customized for your needs.

Recently I needed to test part of Slim that uses the built-in PHP functions header() and headers_sent(). To do this, I took advantage of PHP’s namespace resolution rules where it will find a function within the same namespace first before finding one with the same name in the global namespace. The idea of how to do this came courtesy of Matthew Weier O’Phinney where this approach is used for similar testing in Zend-Diactoros.

He starts off with the code he wants to test - a response method - and a simplified version of the test. This method makes use of the headers_sent and header functions in PHP but those needed to be overridden in order to make the test actually work. He includes the changes to make to the test to override these methods because of how namespaces resolve (using the global PHP namespace last).

In a new post to his site Freek Van der Herten covers how some of the changes that happened in Laravel's v5.5 release would impact the packages Spatie shares, some of the more popular PHP packages with a wide range of functionality.

At Spatie we’ve released a auto-discovery facades functionality, LTS releases and how some new functionality replaces (retires) packages Spatie had already released.

Laravel 5.5 is probably the best release yet. But, in all honesty, I think that of every Laravel release. My recommendation is to get your apps upgraded to this version as soon as possible. The reward is that you can make use of all L5.5’s new features and the latest major versions of our packages.

Mathias Verraes has shared some thoughts about legacy applications and how development should be handled as new features are added and bugs are fixed. He proposes a "heuristic" to keep in mind as you work in your legacy code: the Repair/Replace Heuristic.

Technical Debt is a great metaphor. It shares many analogous properties with financial debt: loans, accrued interest, token payments, bankruptcy… There is a key difference however. We take financial debt with another party. [...] Technical Debt has no measure like money, and no ruleset like Property law, and, more importantly, with Technical Debt there is no other party. The organisation is both the creditor and debtor. [...] In “Managed Technical Debt”, I propose a cheap, imprecise, but surprisingly effective method for mapping and measuring debt. In short, it involves posting stickies whenever progress is impeded by debt, and keep marking the stickies for every incident.

By following this method, you gather together a better overall picture that makes determining the worst debt in your application easier. He proposes using this to follow the Repair/Replace methods: repairing something if it's well architected or replacing it if it's not.

Even when you’re not trying to decide on Repair/Replace — perhaps the decision was already made by others — the process of mapping its history will teach you more about the system and and its design. And one deep insight you learn from temporal modelling.

In a post to his site today Shameer C shows you how to replace Pimple in Slim 3 as an application's dependency injection container. He replaces it with the Aura.Di container, a relatively easy replacement thanks to the container interoperability efforts.

Slim framework is my go-to micro framework for all small projects because of it's simplicity and easiness to use. The new version of this cool framework is just around the corner and they have released RC-1 a few days back. [...] Slim 3 has a default DI Container that extends Pimple. [...] Though Slim uses Pimple by default, we can replace it with any DI container that implements Container Interoperability interface, which is a really great feature. The only caveat is Slim sets some of it's required services from the default container. So we should do it by ourself when we use a different library.

He starts by talking a bit about the Aura.Di container and how it's different than what Pimple has to offer. He then links to a small library that makes the bridge between Slim 3 and Aura.Di and sets up the services Slim needs to operate correctly. He then steps through the code needed to integrate this into a simple Slim application based on this skeleton. Most of the work is done in the dependencies.php file where Slim's needs are set up, configured and injected into the container.

Rob Allen has a quick post to his site showing you how to replace the default Slim dependency injection container (Pimple) with another option.

One feature of Slim 3 is that the DI container is loosely coupled to the core framework. This is done in two ways: The App composes the container instance rather than extending from it and internally, App depends on the container implementing the container-interop interface. [...] Slim 3 ships with Pimple by default, but my preference is for ZendServiceManager, so I decided to integrate ServiceManager into Slim 3.

While he's packaged it up into an installable library, he also walks through the process. He shows how it was implemented via a callback resolver in the ServiceManager. He had a little issue with the "set" functionality but solved it with a few simple "if" checks on the content type before setting it to the container.

In the latest episode (#46) of the "Lately in PHP" podcast series Manuel Lemos and Arturs Sosins wonder if Hack will ever replace PHP.

The release of the Facebook Hack language has shaken the PHP community since it implements several frequently requested features that were never implemented, many users are considering to drop PHP in favor of Hack. This was one of the main topics discussed by Manuel Lemos and Arturs Sosins on the episode 46 of the Lately in PHP podcast. They also talked about the OpenSSL Heartbleed security bug may affect PHP sites or not, ideas for the PHP 6 engine, the need for an official PHP specification, and an advanced email validation that can provide suggestions for address typos like Google did you mean feature.

You can catch this latest episode either through the in-page audio player, by downloading the mp3 or by watching the video of the live Google Hangout recording.

Nils Adermann has a new post looking at a problem with Composer where it will install a fork of a project rather than the actual project repository. He points out that it is not a security vulnerability in Composer itself, and is usually cause by using the configuration incorrectly.

Recently there has been an increase of cases in which Composer installs a fork of a package instead of the package the user expects. Most frequently these are forks of packages using a “replace” statement in their composer.json. These forks are usually meant for private use only but are still published on Packagist.

The issue stems from the use of "replace" and the publishing of those forked repositories in the Packagist service. "Replace" is meant to define a fork that is still compatible with the original project. The way that Composer handles finding the correct package to install can cause a conflict and the wrong package could end up "winning".

In this quick post to his blog, Mike Purcell mentions the deprecation of the "assertType" assertion and includes some code you can add to correct the issue in your tests.

We recently upgraded phpunit from a very old version to the current 3.6.x version (at time of writing). During the upgrade I noticed that assertType is no longer supported in many of our tests which were testing if something was a string, an array, or an object. So I had to write a quick script to update assertType to assertInternalType and figured I would post it for others if they needed to do the same.

The code goes into each of your tests (recursively) and finds the places where the "assertType" assertion is used and replaces it with its newer cousin "assertIntrnalType".

On PHPMaster.com today there's a new tutorial that shares a few regular expression tips about doing some search and replace in your content.

So how can you practice using regex if you are limited to just using them in your code? The answer is to use a utility, of which there are many, that uses regex for performing search and replace. I’m sure everyone is familiar with the standard “find x and replace it with y” type of search and replace. Most IDEs and text editors have built in regex engines to handle search and replace. In this article I’d like to walk through a series of exercises to help you practice using regex.

His examples are based on Netbeans but can be used in just about any IDE that supports regex (or even just your code). He shows how to match word boundaries, do some grouping, work with back references and doing some search/replace based on multiple groupings.