In a post to his site Tomas Votruba provides a guide "for dummies" to using local packages along side your remote packages via Composer.

I wrote about pros and cons of local packages before. After year of using this in practice and mentorings I polished this approach to even simpler version that is easy to start with.

[...] There is no need to use Github, love open-source, understand package design or understand composer beyond PSR-4. No symlink issues, no forgotten composer update. Anyone can start using this!

The "dummy" packages he creates are essentially a simulation of a Composer package just in a different location (under a "packages" directory). This can then be autoloaded via the same Composer configuration you already use without too much trouble.

The Laravel News site has a quick post sharing a helpful topic for the Laravel users out there. In the tutorial they show how to create custom helpers for use across the entire application in any scope.

Laravel provides many excellent helper functions that are convenient for doing things like working with arrays, file paths, strings, and routes, among other things like the beloved dd() function.

You can also define your own set of helper functions for your Laravel applications and PHP packages, by using Composer to import them automatically.

If you are new to Laravel or PHP, let’s walk through how you might go about creating your own helper functions that automatically get loaded by Laravel.

The tutorial starts off by recommending the placement of the custom helper file and how to ensure it's autoloaded when the application is bootstrapped. It then covers the creation of the helper functions including the use of if checks to ensure there's not a function naming collision. Finally the post includes an example of a helper file, sharing the creation of two methods: show_route and plural_from_model. The post ends with a look at packages and how to include helper files inside of them for use in your application.

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.

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.

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.

Matthew Weier O'Phinney has a new post to his site showing you how to can use Composer to autoload Zend Framework modules right along with the rest of the ZF components.

One aspect of Zend Framework 3, we paid particular focus on was leveraging the Composer ecosystem. We now provide a number of Composer plugins for handling things such as initial project installation, registering installed modules with the application, and more. It's the "more" I particularly want to talk about.

With ZF2, we were able to realize the ability to install third-party modules into existing applications, enabling a module ecosystem. [...] For the v3 release, we wanted to solve this if we could. We were able to do so via a Composer plugin, zend-component-installer.

This allows ZF module authors to add details into the "extra" section of their Composer configuration, making it so the plugin understands how to load the module automatically. They've also created a package to help do the same for Apigility applications and lets you remove any calls to "getAutoloaderConfig" in your modules.

In this post to his site Tyler Longren shows how to use Composer to install WordPress plugins as well as the usual libraries.

I love Composer. It just makes including libraries or scripts in your app incredibly easy. So easy that it’s stupid not to use it (in many, if not most cases).

[...] I'd never used Composer with a proprietary WordPress plugin before. The plugin is for a client so it’ll never be available to the public. Here’s the steps I took to make this WordPress plugin compatible with Composer so that I can easily bring in third-party libraries.

He breaks it down into a five step process, showing the installation of the Mailgun PHP client:

• Install composer on your server
• Add Mailgun as a dependency
• Check your composer.json file
• Tell composer to install Mailgun
• Autoload Our Mailgun Classes in Our Plugin

With the help of Composer, the Mailgun client is ready to go and accessible in his WordPress instance, quickly and easily.

In a tutorial posted to the Cullit.com site Philip Brown shows you how to create a PSR-4 compliant package that can be installed quickly and easily through Composer. The PSR-4 standard is a part of the set of standards defined by the PHP Framework Interoperability Group (PHP-FIG) to help make it easier to work with libraries and tools across frameworks and platforms. The PSR-4 standard replaces the slightly more complex PSR-0 to define a pattern for autoloading files.

A couple of weeks ago I wrote a tutorial on the general principles behind building PHP packages. In that article I mentioned the PSR-4 standard for creating PHP packages. In this tutorial I’m going to walk you through setting up the structure of a PHP package. By having an agreed upon structure for PHP packages we make our code a lot more interchangeable and reusable for the greater Open Source community.

He starts with the basics, creating a simple "nacho" directory in a git repository and introducing Composer (and the composer.json) briefly. He also talks about the "dotfiles" that are included with the use of Composer including a sample Travis-CI configuration. He then gets into the code and shows how to use namespaces, relate them to the directory names for autoloading and even writing a simple test or two. From there he talks about documentation and, finally, pushing the package up to GitHub and adding it to Packagist for others to download.

Alejandro Celaya has a post showing how he recommends working with sub-namespaced modules in a Zend Framework 2 application. It's based on a previous series of articles on the same topic but improves the methods for handling.

The solution provided in those articles was functional, but it introduced some new problems to deal with. It happens that after some time working with sub-namespaced modules I have found the best way to solve those new problems, and I wanted to write this new article explaining it.

He starts with the two main problems with the use of sub-namespaced modules: the autoloading of the module's files and how it resolves the locations of view scripts. Fortunately, the solution to both issues turns out to be "really easy". Composer's autoloading means that just changing the directory structure helps there and and update to the controller_map value helps with locating view files.