Tomas Votruba has a new post to his site showing you how to add a global option or argument to your application that makes use of the Symfony Console component. In this case, a "global" option is one that can be given to any command in the application. For his needs, it's a filename.

I'm working on 3 Console Commands. All was good, until I needed to add an argument to all commands at once... and in lazy, extensible, maintainable way.

He starts by talking about some of the "why" behind the need to run multiple commands at once. He shows an example of having multiple CHANGELOG files and the need to define the output file for each rather than just one file. He then goes through four different possible implementations, including the code and pros/cons of the approach:

• Add Argument to Each Command
• Modify Application Definition
• The Symfony Event Subscriber Way
• Extend the Application

He ends the post mentioning the one he prefers (the last one on the list) and briefly mentions anti-patterns and finding the right solution over just the first one you find.

Nwanze Franklin has posted a tutorial to the Dev.to site sharing a deep dive into middlewares in Laravel. Middleware is a powerful tool that can allow you to work with the request and response objects in your application in a more reproducible and contained manner.

What is a Laravel middleware? It is a feature in Laravel which provides a mechanism for filtering HTTP requests entering your application. This allows you to hook into Laravel request processing work flow to perform some kind of logic that decides how your application works.

What would you use middleware for? Protecting your routes, setting headers on HTTP responses, logging requests to your application, sanitizing incoming parameters, enable site-wide maintenance mode [and] manipulating responses generated by your application.

The tutorial then starts in on the code, showing how to create a custom middleware and the code that's generated by the artisan command. It covers the differences between global and route middleware, how to register a middleware and assigning it to a route. It ends with a look at using parameters in middleware and how to access them from the controller.

In a post to his site Benjamin Eberlei looks at global state in PHP using something called "context objects" and how they can be used as an alternative to true global state.

Global State is considered bad for maintainability of software. Side effects on global state can cause a very nasty class of bugs. Context objects are one flavour of global state. For example, I remember that Symfony1 had a particularly nasty context object that was a global singleton containing references to very many services of the framework.

As with every concept in programming, there are no absolute truths though and there are many use-cases where context objects make sense. This blog posts tries to explain my reasons for using context objects.

He starts by getting everyone on the same page by defining a context - the "circumstances in which something can be fully understood". He then moves into the world of context objects, talking about how they encapsulate the information other objects need to execute. They're essentially "container" objects that allow for more control that something like the normal PHP superglobals. From there he helps you define what kind of context objects you might need in your application and provides a real-world example from his own experience at Tideways.

Matt Stauffer has continued his series covering some of the new features in Laravel v5.3 with this look at the cache helper, a new feature introduced to help make working with your cached data easier.

As I was writing my book I noticed a pattern in the global helper functions like session() and, in some ways, cookie(). There are three primary functions that they can perform: get a value, put a value, or return an instance of their backing service.

[...] I mentioned that it seems like there should be a cache() helper, and before I could even think much more about it, Jeffrey (Way) had already written one up. So! Behold! The global cache() helper, new in Laravel 5.3.

He includes code samples showing the helper in action. It's a simplified helper so the main functionality is basically the same as the session and cookie helpers: read, write and return an instance of the CacheManager.

The SitePoint PHP blog has a post about a feature Composer provides to help make tools and libraries easier to use - the ability to install things globally. In this post editor Bruno Skvorc wonders if this feature should be "considered harmful" and a bad practice.

We’ve discussed Composer best practices before, and I’ve always advocated using composer global require when installing packages that can be used across several projects – particularly command line tools. Then, the other day, I ran into this discussion. The short of it is – the majority of people now seem to feel like global require is bad practice, unless the globally installed package has zero dependencies.

The article he references offers an alternative option however: install locally to the project and just update your paths to allow for it to be easily found. This can be difficult and hard to maintain so Bruno offers a counter-suggestion, the "[consolidation/cgr]"(https://github.com/consolidation-org/cgr) tool. This tool handles the "global" install in a way that still isolates it and then automatically updates your .bash_aliases with the command and path to make it easier to use.

On the NetTuts.com site there's a new post (a part of a series) that introduces you to the global variables available in WordPress and provides a practical use for them.

In the first article in this series, we reviewed an introduction to WordPress global variables. Specifically, we said that they are variables that hold a variety information that can be accessed from anywhere in the WordPress page lifecycle. We learned how to access a global variable and display various details about the latest post using the $post global variable. In today’s article, we will dive further into global variables by learning how to access them to display the author information.

In this post they focus on extracting user (author) data from the system via the "authordata" global variable. He shows an example of a print_r output of the data it contains and use this to filter posts, only showing three per-author.

Rob Allen has a quick post today showing how to use Composer to globally install tools and libraries on your system.

The Composer package manager along with the Packagist repository site is quickly becoming the defacto PHP package management system. One feature I found out about recently is that you can install packages globally rather than locally into your project. I think that this is most useful for development tools, such as PHPUnit which are then available everywhere.

He includes the command syntax you'll need to do the global install, showing an example with the popular PHP unit testing tool PHPUnit. There's also a "global update" command you can use to update these packages (or add more) later on too.

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.

Russell Walker has a post on his site sharing some suggestions about effectively dealing with global data in your PHP applications.

Almost every web application needs to handle global data. There are certain things that just have to be available throughout the entire code base, such as database connections, configuration settings, and error handling routines. As a PHP developer, you may have heard the mantra 'globals are evil', but this naturally begs the question 'what should I use instead of global variables?'

He includes four different options (five including the actual use of global variables):

• Static classes
• Singleton
• Registry
• Dependency injection

For each of the options he includes summaries of both the advantages and disadvantages as well as some sample code showing their use. Ultimately, he points out that it's up to the developer of the application which option fits best.

On the DeveloperDrive.com site today there's a new post with five easy steps you can take to help increase the security of your PHP-based applications.

For many years, PHP has been a stable, inexpensive platform on which to operate web-based applications. Like most web-based platforms, PHP is vulnerable to external attacks. Developers, database architects and system administrators should take precautions before deploying PHP applications to a live server. Most of these techniques can be accomplished with a few lines of code or a slight adjustment to the application settings.

The five tips they list range from general "best practice" kinds of things to a bit more specific:

• Manage Setup Scripts
• Include Files (using ".php" not ".inc")
• MD5 vs. SHA
• Automatic Global Variables (no longer an issue in recent releases, 5.4.x)
• Initialize Variables and Values