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.

Adam Peterson has posted an interesting idea for those out there running an internal staging server they want to constantly keep up to date with the main line of code (without manual intervention) - a git pull web frontend combined with git post-receive hooks.

This [move from svn to git] left a bit of a gap in my process where I could no longer test on a remote server without updating it manually by S/FTP or opening terminal and manually calling a git pull. Open terminal and manually git pull it did break up the work flow a bit so using the Dingo framework I created a very simple Git helper and gave it its own URL something like git/pull.

He added a post-receive hook to his git server that calls this "git/pull" URL on the staging server and updates the code on the server. This provides an easy asynchronous way to update things on another server. Note, though, that this should never be done on a publicly accessible server - it's a pretty large security hole (or at the very least made secure somehow). He used Dingo to create his interface, but something like the Slim micro-framework could have worked just as well. You can view his code on github.

Kevin Schroeder has a new post today sharing some of his experience with the Zend Framework 2 Event Manager in a simple example of pre- and post-validation hooks in a model.

I got to play with the Event Manager. I did like the plugin functionality in ZF1, but it required some pretty static coding. In some cases, like the front controller plugins, it makes more sense (though this way seems more desirable). [...] It's a ZF1 application, but since (it seems) the event manager is self-contained (and the autoloader works with both ZF1 and ZF2) you can simply paste it into your include_path and BOOM, you have an event manager.

In his case he has a set of models extending a base class and wanted to introduce pre- and post-validation hooks to make it simpler to check the data he was working with. He includes the code for his base model class showing how he implemented the ZF2 EventManager in his ZF1 application. He attaches an event to the password class property and, on update, it automatically updates a temporary password value too.

You can get more information on using the EventManager in this other post from Matthew Weier O'Phinney.