In a new post to his site Joe Ferguson shows you how to move a dependency over to Composer but still require the older version, possibly one that's already included in the codebase as a checked-in source.

A common problem I run into with older applications are dependencies that have been added and loaded from the application’s repository. You would often see a “libraries” folder with a “className.php” type file. If you’re lucky you’ll have the entire folder of the dependency including the release notes to be able to find out exactly what version you’re using.

[...] What if the author hasn’t tagged our older version? Maybe they converted the repository to git from subversion or some other system? You have to go digging into the commit history to find the commit you want to match your current version.

He includes the Composer configuration required for both examples (loading the older version and loading by commit ID) as well as the addition of the "minimum-stability" option. This option allows you to pull directly from the "master" branch if you need to - just be sure to define exact versions of other dependencies otherwise you'll get dev versions of them too.

Cees-Jan Kiewiet has a post on his site showing you how to run GrumPHP hooks in Vagrant, a tool that allows for code quality evaluation.

A couple of weeks back while attending AmsterdamPHP Mike Chernev gave a talk about GrumPHP. Very cool looking tool, but during implementation I found out it the default setup assumes running grumphp on the same machine (whether that is a VM or iron) as committing. That is a problem in my set up where all PHP related code runs in vagrant and comitting on the host using PHPStorm. Lets fix that.

The post includes the scripts you'll need to include in your Vagrant setup to execute the quality checks on commit, pre-commit and the Vagrant hook setup to run everything inside of the VM instead of locally.

Rob Allen has a post to his site talking about using Composer with shared hosting, showing how to use this popular tool even if you're on a shared hosting environment and don't have direct SSH or shell access.

I've seen this sentiment a few times now, so this seems like a good time to point out that you do not need SSH access to your server in order to use Composer. In fact, I don't run Composer on a live server (regardless of whether it's using shared hosting) and it's not on my list of things to do in the near future.

What you do need is a process where you handle your Composer dependencies on your own computer where you have PHP running.

He gives two possible solutions to the problem: either commit your dependencies or create some kind of build script that can execute the Composer install for you on deploy. He gives details on both of these solutions including the process for installing the dependencies with an automated FTP script (run at deploy rather than committed).

On the NetTuts.com site there's a new post talking about protecting your keys when using a public site like GitHub. This relates to an easy thing to forget - removing hard-coded credentials from code before pushing it public.

In December 2014, Slashdot ran an alarming story Bots Scanning GitHub To Steal Amazon EC2 Keys, based on developer and blogger Andrew Hoffman's experience trying out Ruby on Rails on Amazon with AWS S3. He inadvertently committed an application.yml file with his AWS keys. [...] It's an easy mistake and most of us have probably done a similar thing at one point or another. And it's not just AWS keys that are at risk. As our use of cloud-based services increases, the expanding use of a broad variety of service API keys can be leveraged by hackers and spammers alike.

He goes through a solution he's found to help protect those credentials, in this case working with the configuration of a Yii framework-based application. He starts with a mention of .gitignore but points out that it could have unexpected results from "quirks" in its handling. He suggests a different option - using a configuration file that lives someplace outside of the main git directory and can be referenced directly from inside the application. He provides two kinds of examples: one using a PHP-based configuration and another based on an INI file. He finishes the post with a mention about WordPress plugins and the fact that they're (usually) stored in a database and open to exposure if a SQL injection vulnerability is found.

In his latest post Phil Sturgeon talks about a point that's been argued on both sides of the Composer users out there - whether or not to commit the "composer.lock" file. Phil talks some about it in his article and suggests that you should commit it for applications but not for components.

If you and your employees are a little vague with your composer.json specifications and you don't have a composer.lock then you can end up on different versions between you. Theoretically, if component developers are using SemVer and you're being careful then you should be fine, but keeping your lock in version control will make sure that the same version is on your dev teams computers. This will happen every time you run $ composer install. If you are on Heroku or EngineYard then this will be used for the deployment of your production components as a built in hook, which is awesome.

He mentions an article from Davey Shafik, this being his reaction to it. He suggests, though, that an absolute of "always commit for components" may be too much and could potentially cause other problems. He points out that since the "composer.lock" handling is local to the directory, you can hit up against version requirement issues between them in your application as a whole. He wonders "how strict is too strict" when defining dependencies and some things to think about (like your users) when making the choice to upgrade the libraries you use.

On the Facebook HHVM blog they talk about an improvement they've made to the project allowing for faster GitHub commits on the project. They've reworked things to move away from a manual process on the popular project and automate as much as possible.

Initially, the entire process was manual. We would curl the pull request and pipe it to git am, then manually prepare the diff for review internally. After it was accepted, we would manually prepare the internal commit to be usable externally by GitHub, then manually build and test the new code, and finally git push. Great scripts by ptarjan and sgolemon to help get and prepare pull requests for review and then prepare the commits for GitHub have alleviated some of this manual process. However, in the end, someone still had to manually build, test and then push the code to the world.

Another feature of this effort is a new cron job (facebook-github-bot) that pushes any internal (approved) HHVM code automatically without having to wait for the manual intervention. It syncs all code since the last push, runs all tests and, assuming all went well, pushes it out to GitHub.

we believe that getting your code into the master branch quickly will hopefully help show how much we appreciate your contributions. Now, if there was only a way we could get your pull requests reviewed faster and more openly…. Hmmm…

If you're relatively new to using version control, there may be one technique you've yet to get a grip on. In this new post on SitePoint.com's Web blog they introduce you to using the "diff" functionality to discover differences between versions of code.

Every project is made up of countless little changes. With a little luck, they will finally form a website, an app, or some other product. Your version control system keeps track of these changes. But only once you understand how to read them will you be able to track your project’s progress. Using the example of Git, the popular version control system, this article will help you understand these changes.

They include several screenshots and line-by-line descriptions of what each part of the output of the "git diff" command is. There's also a brief description of what each of the sections contains and how to inspect both committed and non-committed changes. There's even a link to a list of other applications that may help provide a clearer picture of the changes rather than just the command line output.

In this new post from Freek Lijten he looks at a set of git commit hooks written in PHP for making things happen before, during and post commit.

Git hooks are usually found inside the .git/hooks folder of your git repository. Git tends to provide sample hook files there which are postfixed with a .sample extension. These examples are written as shell scripts. Take a look at them if you want, but today we're talking PHP!

He briefly touches on the types of hooks you can set up and includes two example scripts showing a pre-commit lint test for the changed files and a check during the commit on the message given for a certain standard (in their case, it must start with a three letter code).

Christian Weiske has a problem he hopes you can help with - he's trying to get the PHP_Codesniffer tool integrated into his git workflow (well, the workflow of his team) as an automatic process that runs on commit. Unfortunately he's having some issues.

At work, we used a SVN server and enforced our project coding standard with a pre-commit hook on the server that ran PHP_CodeSniffer. Whenever a developer tried to commit some code that does not match the standard, he got it rejected. [...] The only way to enforce the standard is a pre-receive hook on our central Git repository server that all devs push to. Just installing the SVN hook on it isn't the solution, though.

Because of how git handles commits (possibly multiple in one push) the usual methods won't work. Other tricky things like file renaming and allowing for legacy code check-ins are also needed. He's posted the question on StackOverflow too, but no one's come up with a good answer yet (at the time of this post).

Johannes Schluter has a new post to his blog today about a recent addition to the latest trunk branch for PHP - a more interactive shell that will be installed right along with the language.

A few years ago I used another blog to write about "More PHP power on the command line" almost 5 years later the PHP interactive shell got a major update which went in PHP's trunk.

You can check out the commit message for more details on this new addition including paging ability and the ability to run PHP directly in the shell.