Colin O'Dell has shared an interesting setup he's created to make it easier to switch between PHP versions when testing your code. In his latest post he shows how to switch the version "on cd" (directory change) with the help of some command line shell tooling.

After using phpbrew to manage my local PHP versions for a while, I got tired of re-compiling PHP after every release and decided to install multiple PHP versions side-by-side with Ond?ej Surý's PPA. One of the features I missed from phpbrew was the ability to run a command like phpbrew use php-7.2.8 to automatically change the php command to that version, so I ended up implementing this feature myself using symlinks and shell aliases.

He then walks through his end result, showing the modification of the default php symlink and aliases that can be used to dynamically switch its target. He then includes some examples of how to automate this using your application's PHP version requirements in the composer.json and a simple ZSH script that's triggered on directory change.

Tomas Votruba has a new post to his site sharing five "gotchas" in CLI applications as it relates to the "bin" file.

This post from Master PHP CLI Apps with Symfony cluster will focus on bin files. It's the smallest part of PHP CLI Application, so I usually start with it.

Yet, there are still a few blind paths you can struggle with. I'll drop a few extra tricks to make your bin file clean and easy to maintain.

He starts with a brief definition of what a "bin" file is before getting into his list of "gotchas":

• recommendations about naming and location of the file
• setting it up to be autoloaded by Composer
• including the right "shebang" to have it executed by the correct program
• changing access rights
• symlinking in Composer

The post ends with the complete code required to build a simple Symfony CLI application that will autoload libraries correctly and be executable by the system's php binary.

The Delicious Brains site has posted the second part of their "deploying WordPress using the command line" series today. In part one they talked about automated deployments and why they're important (and useful). In this latest tutorial they start in on the setup of the environment and the tools you'll need to complete the deployment.

In my last article, we looked briefly at why automated deployments are important and how to prepare a WordPress site for automated deployments.

Now that our WordPress site is ready to be deployed, in this article we’re going to look at how we can use command line (CLI) tools to deploy WordPress from our local computer to a remote server. While we’re not quite at the stage of being ready to set up automated deployments just yet, understanding how we can use CLI tools to deploy WordPress will serve as a good foundation for all of the automated deployment methods we will look at later in this series.

The article then walks through the different pieces you'll need to set up including a DigitalOcean droplet as a destination and a choice of several data transfer tools:

• SCP (secure copy)
• rsync
• Deployer

The post also mentions the WP-CLI tool but points out that it doesn't include functionality to actually move files, only work with local ones.

On his site Tomas Votruba continues his look at the Symfony/Console component of the Symfony framework. In this latest article he walks through the loading of configuration options from a file provided by a --config option on the command line.

PHP CLI apps usually accept config, to setup their behavior. For PHPUnit it's phpunit.xml, for PHP CS Fixer it's .php_cs, for EasyCodingStandard it's easy-coding-standard.yml, for PHPStan it's phpstan.neon and so on.

In the first post about PHP CLI Apps I wrote about poor DI support in PHP CLI projects.

Today we look on the first barrier that leads most people to prefer static over DI - how to load config with services.

He starts off talking about the "chicken and egg" issue when it comes to loading configuration: needing a configuration to create an Application instance which then needs the config (and so on...). He then walks through three possible solutions:

1. Not using a container to manage dependencies for the application
2. Setting up a container in a command
3. Using the ArgvInput input helper to pull directly from the arguments

He gets into more detail on this last method, providing code examples and input/output examples of it in use. Unfortunately this method also introduces some undesired dependencies between commands. He finishes the post with an alternative: setting up option definitions in the getDefaultInputDefinition method of the main application and having them available to all commands.

Robert Basic has shared a quick tip for the Composer users out there (you do use Composer, right?) showing how to exclude certain packages from updates without having to whitelist packages all the time.

Given that Composer has no --exclude flag or similar, the only other option is to create a list of packages we allow to be updated, excluding the ones we don’t want to be updated. We need to create a whitelist.

Creating it manually would be a PITA though, especially if there’s a lot of packages to include or exclude. CLI to the rescue!

He includes a command that grabs the packages from the current composer info listing (using grep, sed, cut and paste). He walks through the command showing how it works to pull the package information out. With the help of the -v option for grep it's easy to remove certain items from the list (blacklist) and to provide a string back to composer that can then be used to update only the remaining packages.

On the Laravel News site there's a new post sharing five command line tools that could be helpful for developers and make their workflow a bit simpler.

Over the last several years, I’ve improved my command line searches through a few tools geared towards programmers. These tools help developers find phrases and patterns in text files in an unfamiliar codebase without the complexity of grep.

The following is a list of five command line search tools that will help you as a developer if you are interested in using the command line more for finding code, text, and files quickly without relying on an editor or an IDE. Some of the tools are ‘nix only, but I’ve listed a few that are cross-platform and ridiculously fast!

His list describes the usage and benefits of:

• grep
• Ack
• the Silver Searcher
• Sift
• RipGrep

Each includes command examples and, where required, the commands to install the library (as it's not standard for Linux builds).

The DeveloperDrive site has posted a tutorial for the WordPress users out there showing them how to enhance their workflow with WP-CLI, the command line tool that can be used to administer your WordPress instance without needing to log into the web UI.

As a WordPress developer, you’ve probably installed the WordPress CMS, updated it, and activated themes and plugins hundreds of times. And although these routine development and maintenance tasks are fairly easy to do with WordPress’ graphical user interface, doing them over and over again isn’t very efficient.

The good news is that you can easily and effectively speed up WordPress development and maintenance with the WordPress Command Line Interface (WP-CLI). With this in mind, in this post, we’ll explore the different ways you can use WP-CLI and offer some helpful WP-CLI commands to help you get started with a step in the right direction.

The post starts with a brief introduction to the WP-CLI tool and shows how to get it installed on your system in a Unix-based environment (basically grabbing a phar). It then walks you through some of the features of the tool including:

• installing a new WordPress instance from scratch
• keeping it updated
• managing themes and plugins
• creating custom post types

Examples of each command line call are included as well as some details about options and what's happening behind the scenes.

As this post to Laravel News mentions the upcoming v5.6 release of the framework will remove the artisan optimize functionality from the project's artisan command line tool.

The Artisan optimize command is deprecated as of 5.5, and a commit in master has already removed it from 5.6. Waiting until 5.6 gives you time to update your build scripts and composer.json files ahead of the release.

As of Laravel 5.5, the composer.json no longer references optimize in the post-install-cmd and post-update-cmd scripts. The Optimize command is still defined, but does nothing in 5.5.

The project has provided some reasoning behind the change, mostly having to do with the overall performance improvements in the PHP language itself. Additionally, there was some discussion around the removal before it was finalized.

Rob Allen continues his series looking at the "serverless PHP" environment that is a part of the IBM Bluemix offering. In his previous post he introduced some of the basic concepts of using the service and helped you create a sample "Hello World" function. In this new tutorial he shows how to update that environment and create a user and allow them access to the PHP functions already created.

I'm at the stage where I need to give another developer access to my IBM Cloud Functions actions. I'm not really an infrastructure person and I found the user management pages on the Bluemix console incomprehensible, so used the command line. This is how I did it so that I don't have to work it all out again.

There's only two steps to the process: adding the user to your organization and adding the user to the space. He goes through both steps, explaining how it works and the command line calls to make it happen. This also provides the added user with access to related resources (like databases).

On the Master Zend Framework site Matthew Setter has written up a new tutorial showing you how to migrate from Zend Expressive v1 to v2 with the help of some command line tooling support provided as a part of recent updates to the project.

In part one of this series, we started learning about the tooling support available for Zend Expressive, provided by Zend Expressive Tooling There, we learned how we can use the package to create, register, and deregister middleware, and scaffold new modules. But that's only half of what the package can do.

Here, in part two, let's learn about the other half, which removes some of the heavy lifting required when migrating Zend Expressive applications from version one to two.

He first defines some of the main differences between the two versions, a checklist of things the tooling will help you more automagically update. He talks more specifically about migration support, moving to "programatic pipelines" in Expressive v2 and scanning for deprecated error middleware. There's also information about locating the legacy request and response handling and how they're refactored to the newer format.