In a new post to his site Woody Gilk showing how to use custom Composer hooks to run PHP style checks (using PHP_CodeSniffer) on your codebase and setting up the same configuration for all developers.

One of thing that has always bothered me about phpcs is that the lack of a local configuration file.

The official way to set the default standard for a project is [to set the standard on the command line]. This will write to a configuration file inside the vendor/ directory, which means that the configuration cannot be committed to version control. When a new team member is added they must also run this command or different style checks will be used.

Luckily, this can be solved with composer command events, namely the post-install-cmd and post-update-cmd events, which can be pointed to a PHP class that processes the event.

He includes the configuration changes showing how to set up the command in the Composer configuration to run post-install/update and the code required to set the phpcs standard to use. While this method works, he has also updated the post with an example of a single (XML) configuration file that accomplishes the same thing.

The TutsPlus.com site has a tutorial posted that introduces you to CodeIgniter's hook system and details how it all works. The tutorial goes through each hook already included and shows how to create a custom one to fit your needs.

As a CodeIgniter developer, sometimes you end up in a situation that requires you to alter the core of the framework or the execution flow to fulfill your custom requirements. Of course, it's never recommended to modify the core files as it makes the upgrade process cumbersome. Luckily, the CodeIgniter framework comes with the hooks system, which allows you deal with this scenario.

In this article, we'll start with an introduction to the hooks system in the CodeIgniter framework. Then, we'll discuss the different types of hooks available. And finally, we'll grab this opportunity to explore the creation of custom hooks.

They start with an overview of the hooks system and what kind of functionality it offers to the developer. The article then goes through each of the default ones built in to the framework including system hooks, controller hooks and "overrides" hooks. It then finishes off with a look at creating a custom hook and how to add it into the system for use across the application.

Dave Marshall has written up a post showing how you can use closures with PHPUnit to provide "after" hook functionality.

Not sure why I didn't start doing this sooner. We have a basic Feature toggle system that is maintained in the global scope to make it easily accessible to any part of the code. [...] I needed to force a particular feature on in a PHPUnit integration test, but in order to tidy up after myself, I would need to ensure that the test reset the Feature system after it had finished. There are a few ways of doing this.

The first of the three, using PHPUnit's own global state handling comes with its own set of problems. The second was to use a try/catch block in the test to ensure the state is reset and a third was to use the "tearDown" to reset everything accordingly. He ended up finding what he needed in the form of "runAfterHooks" handling in a trait, passing in the closure to be executed.

On the SitePoint PHP blog Matthew Setter introduces the use of git hooks to help with automatic static analysis of your application's code, integrating it directly into your current workflow. He shows how to use this library to make creating and installing them as easy as a single command (and they're written in PHP).

If you’ve been using Git for more than a short length of time, you’ll hopefully have heard of Git hooks. [...] There are hooks for pre- and post-commit, pre- and post-update, pre-push, pre-rebase, and so on. The sample hooks are written in Bash, one of the Linux shell languages. But they can be written in almost any language you’re comfortable or proficient with. [...] Thanks to Static Review, by Samuel Parkinson, you can now write Git hooks with native PHP, optionally building on the existing core classes. In today’s post, I’m going to give you a tour of what’s on offer, finishing up by writing a custom class to check for any lingering calls to var_dump().

He walks you through the installation of the library and helps you create a simple working example that ensures you've correctly set up your (Composer) dependencies. He explains a bit about what's involved in the StaticReview package and the three "introspection" objects initialized for each run. He ends the post by walking you through the creation of a custom, more real-world check that evaluates your code (via a simple grep) to ensure no var_dump statements were left in.

The Zumba Engineering blog has a new post looking at a way you can control code quality and standards with the help of Composer, git hooks and the PHP Code Sniffer (phpcs) tools.

Maintaining code quality on projects where there are many developers contributing is a tough assignment. How many times have you tried to contribute to an open-source project only to find the maintainer rejecting your pull request on the grounds of some invisible coding standard? [...] Luckily there are tools that can assist maintainers. In this post, I’ll be going over how to use composer, git hooks, and phpcs to enforce code quality rules.

These three technologies are combined together to make a more seamless experience for the developer while keeping the code quality high. Their method makes use of the "scripts" (post-install-cmd) feature of Composer to, after the installation of all packages, set up a git hook script that will run the phpcs checks on pre-commit. It's a pretty simple shell script that kicks back any errors it might find before the user can commit their changes.

Kevin van Zonneveld has a new post that, while not PHP specific, does have a handy script that will help you stop committing broken code.

Whatever the reason, it's almost 2014 and we are still committing broken code. This needs to stop because best case: Travis or Jenkins prevent those errors from hitting production and it's frustrating to go back and revert/redo that stuff. A waste of your time and state of mind, you were already working on other things. Worst case: your error goes unnoticed and hits production.

To help resolve the problem, he suggests using the "hook" system common to most version control software. In his specific example, he shows the use of a pre-commit hook that fires off a bash script on the files being committed. He includes the full code for this bash script that includes a check for PHP scripts using the built in PHP linter (the "-l" option on the command line). He also includes the commands and updates you'll need to make to get it installed on git.

James Morris has a new post to his blog showing you how you can deploy a Silex-based application via git and a post-receive hook on the server side.

Up until a few days ago I used to use a small bash deployment script to deploy a few simple sites to my live box. The process was a git archive and extract, then an rsync to the live site. Only inspecting it recently I realised that rsync no longer sent just the changes but all of the files, I’d never noticed before as the sites were so small the deploy was over very quickly. The rsync used to work fine before as I would deploy my current working code where the timestamps on files would match the server. Since I started using git at home for dev, the git archive method timestamps the files with the latest commit’s timestamp. This messes up rsync.

His process involves a checked in version of Silex, a development branch, a push of the code to the live machine and an install script to set up Silex. He includes the "technical breakdown" and the information needed to replicate it - the .gitignore, setting up password-less SSHing, setting up the server and creating the git post-receive hook (a bash script).

Gonzalo Ayuso has followed up his previous post about creating a simple SQL wrapper with PDO in PHP with this new post, a "part two" looking at improving it a bit with a new class to represent the tables.

In one of our last post we built a simple SQL wrapper with PHP. Now we are going to improve it a little bit. We area going to use a class Table instead of the table name. Why? Simple. We want to create triggers. OK we can create triggers directly in the database but sometimes our triggers need to perform operations outside the database, such as call a REST webservice, filesystem’s logs or things like that.

He includes the updated code with the new "Table" class with methods that let you set up pre- and post-action hooks on each of the types (insert, delete, update) along with the rest of the library, there ready for the copy & pasting.

Sean Coates has a new post today sharing an example push process for the times when you either just need to push code (without the build process) or you're just deploying something simple - a "deploy on push" hook built into your github repository.

Sometimes, you just need to deploy code when it’s ready. You don’t need a build; you don’t need to run tests - you just need to push code to a server. If you use git and GitHub (and I think you should be using GitHub), you can easily deploy on push. [...] There are really only three things that you need, in most cases, to make this work: a listener script, a deploy key and associated SSH configuration, and a post-receive hook.

He explains what each part of the process does and includes the simple PHP script that github calls to make the deployment (it's specific to his example, but you get the idea). He walks you through setting up the deploy key (a SSH key generated on your server) and how to get SSH to use this key when github comes knocking.

Paul Reinheimer has a recent post to his blog talking about the danger of "hooks" in your development - the functionality several frameworks and other tools come with to allow you to add functionality to the core without having to change the main source.

I ran into hooks rather simultaneously with two very different frameworks: Code Igniter and Lithium. In both cases I was using a rather nifty hook to handle ensuring that users were properly authenticated and authorized before accessing a page. [...] One day, while messing around, I accidentally turned off the hook configuration within Code Igniter (actually I clobbered a file, and restored the wrong one). Then, things came crashing down in a horrible cacophony of... actually they didn't. Everything kept working: that was the problem.

He shows two solutions he came up with to be sure that his hooks were executed - one for Lithium and the other for CodeIgniter. The Lithium one uses a "_remap" method and the CodeIgniter example uses the magic "__invoke" method to check for an "AUTH_CHECKED" constant that's only defined as a part of his hooks.

I'm no longer entirely dependent on one configuration option or file for my security to function. Should it fail, I've got a secondary check in place; this example of defence in depth allows me to be comfortable with the hooks security system once more.