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).

On the Laravel News blog they've posted a tutorial with some helpful tips for improving your routing in your Laravel-based application.

The Laravel router has a great, well-polished API when you first dive into Laravel as a beginner or newcomer to the framework. What follows is not anything hidden or new, but a few tips that should help you when you’re learning Laravel 5.

The documentation is excellent, and the tips that follow supplement and piece together a few parts that will help you get a quick jumpstart on learning how to use routing in your Laravel applications.

The tips include:

• Custom Namespaces
• Route Macros
• Debugging Routes
• Named Group Routes

Each of the tips include the code needed to implement them and a brief summary of why they're useful.

In a post on his Medium site Joey Masip Romeu shares some suggestions about how you can organize your business logic in a Symfony application with some simple namespacing and service definitions.

I want to talk about namespacing services in Symfony, specifically Symfony3.

These are exciting times, Symfony 4 is just round the corner?— -coming out on November 30th? - ?so this blog post might be irrelevant soon! Nevertheless, concepts are still the same so let´s get into it!

He offers three "rules" that he and his team at SlowCode have defined to help with their own organization:

• using a folder for logic services
• using a folder for the domain name
• using . for folder separation and _ for word separation

Code and configuration examples are provided for each suggestion helping to illustrate the point. He ends the post mentioning public and private services and how they're changing in upcoming Symfony releases.

Sebastian De Deyne has a new post to his site showing the Laravel users out there a method for theme-based views in their applications using vendor namespacing in a multi-tenant environment.

I'm building a multi-tenant Laravel application. One of the requirements of the project is that every client can have their own theme based on their corporate guidelines. By default a few css adjustments will suffice, but some clients request a completely different template.

Conditionally loading a different stylesheet per client is pretty trivial, but in order to use a completely different view per theme you quickly end up typing the same thing over and over across various parts of your application.

[...] There aren't any huge issues here, but all together it feels like we should be able to do better. There are a few strategies to clean this up, but I just want to talk about vendor namespaces today.

He gives an example of a view setup that makes use of the current client/customer's namespace to define the path to the template. He found this leading to a lot of redundancy and figured out a better way: using namespaces. Namespacing is mainly made for package development but can be use here to create a "theme" namespace. This namespace can then be defined once and reused across the application without the need to manually build the template location string every time.

On the QaFoo blog there's a new post sharing a method for testing the untestable - file upload handling in your application.

A long time ago I wrote a blog post about Testing file uploads with PHP where I have used a CGI PHP binary and the PHP Testing Framework (short PHPT), which is still used to test PHP itself and PHP extensions.

Since the whole topic appears to be still up-to-date, I would like to show a different approach how to test a fileupload in PHP in this post. This time we will use PHP's namespaces instead of a special PHP version to test code that utilizes internal functions like is_uploaded_file() or move_uploaded_file().

They update the previous method to use the namespacing built in to PHP to "trick" the test into using a method from a local namespace first. The provide the code they'll be testing and a unit test to try and evaluate its result. The tutorial then shows how to use the namespaces to define is_uploaded_file and move_uploaded_file functions that override the defaults. These are used instead of the base level PHP ones making it easier to test the results of the mocked functions rather than the originals.

The TutsPlus.com site has posted the fourth part of their series covering the use of namespacing and autoloading in WordPress plugins. In this latest tutorial they take everything they've shared (and made) previously and put it all together into a cohesive whole plugin.

At this point, we've laid the foundation for our plugin, written the plugin, and defined and explored namespaces and autoloaders. All that's left is to apply what we've learned.

So in this tutorial, we're going to put all of the pieces together. Specifically, we're going to revisit the source code of our plugin, namespace all relevant classes, and write an autoloader so that we can remove all of our include statements.

He starts off talking about namespacing and how it relates to directory structure and the code you'll need for each of the plugin files for put them in the correct namespace. With just these in place, however, errors are thrown. This requires the setup of a custom autoloader and PHP's own spl_autoload_register handling. He includes the code for the autoloader, taking in the class name and splitting it up to locate the correct directory, making it easier to replace the loading of all plugin scripts.

On the TutsPlus.com site they've continued their WordPress series showing you how to integrate class autoloading into your plugin development.

In this tutorial, we're going to take a break from writing code and look at what PHP namespaces and autoloaders are, how they work, and why they are beneficial. Then we'll prepare to wrap up this series by implementing them in code.

In the previous part of the series they built up the environment and some of the basic structure of the plugin (you'll need this to follow along with this new tutorial) and continue on, starting with the basics of namespacing and autoloading. They then move over and start applying this functionality to the plugin classes and what happens in the autoloader when they're referenced.

The TutsPlus.com site has continued their series looking at namespace-based autoloading in WordPress applications with part two. In this latest article they build on the simple plugin from part one and enhancing it with more functionality and autoloaded classes.

In the previous tutorial, we began talking about namespaces and autoloading with PHP in the context of WordPress development. And although we never actually introduced either of those two topics, we did define them and begin laying the foundation for how we'll introduce them in an upcoming tutorial.

Before we do that, though, there's some functionality that we need to complete to round out our plugin. The goal is to finish the plugin and its functionality so that we have a basic, object-oriented plugin that's documented and works well with one caveat; it doesn't use namespaces or autoloading.

This, in turn, will give us the chance to see what a plugin looks like before and after introducing these topics.

They start off with a quick review of the setup and previous development work done on the plugin making it easier to load in Javascript templates in a dynamic way. The plugin is then ready to start helping with the plugin use. They add in a basic CSS file to the site's "assets" folder and enqueue it. They start updating the plugin code, adding in an assets interface, a CSS loader and some styling for the box shown on the edit post interface.

In this recent post to his site Simon Holywell continues his look at namespacing in PHP with a look at importing and aliasing specific functions, not the entire class.

As a follow on to my short post about namespaces and functions from a year ago I thought it would be worth covering importing a specific function and aliasing functions via namespace operators too. This has been possible since PHP 5.6, but there is a nice addition in PHP 7 I’ll cover towards the end.

He starts with a refresher example of pulling in a namespace and using a method with the "use" statement. Following this he shares an update that just imports the one method via a "use function" call rather than the entire class/namespace. He again refactors this into something more usable (the original method name is quite long) with an alias. He then ends the post with the PHP 7 only trick using the braces to define grouped namespace handling (however, this doesn't allow for function level aliasing).

The TutsPlus.com site has posted a new tutorial for the WordPress developers out there showing you how to get started with namespacing and autoloading in your WordPress installation.

Namespaces and autoloading are not topics that are usually discussed when it comes to working with WordPress plugins. Some of this has to do with the community that's around it, some of this has to do with the versions of PHP that WordPress supports, and some of it simply has to do with the fact that not many people are talking about it. And that's okay, to an extent.

Neither namespaces nor autoloading are topics that you absolutely need to use to create plugins. They can, however, provide a better way to organize and structure your code as well as cut down on the number of require, require_once, include, or include_once statements that your plugins use.

The article then starts in by listing the things you'll need to have installed and working to follow along. It then talks about what they're going to help you build - a simple plugin that adds an "Inspirational quotes" widget to your post editor page. They walk you through the basic setup of the plugin, adding the box to the page and setting up the "questions.txt" file to pull the quotes from. Code is provided for each step including the creation of the "quote reader" class and the class to display the meta box.