Stephan Hochdörfer has shared a handy tip for the Composers users out there that may have to deal with username/password protected repositories as a part of your package install process. In his post he shows how to use a simple "expect" script to automatic the HTTP Basic Auth login.

A couple of months ago when we set-up our own internal Satis repository to host our custom Composer packages. We ran into an "unpleasant" issue with Composer that had this PR as an result. To sum things up: We are using HTTP Basic Auth to password-project our Satis repository. There was no way we could switch to an SSL client certificate to allow Composer to authenticate itself automatically without asking for a password. Asking for the password on a developer`s machine is no big thing, but it since we need an automated Composer run in our Jenkins environment, there was no way to set things up.

As Composer doesn't currently support this functionality, they had to find a way around it. They went with an expect script that is used to work with the prompts and send the username/password information when expected. He also points out that this could be useful for other situations and tools - like a Bower build.

Tibo Beijen has a new post to his blog today looking at exception handling starting with some of the basics and moving out to custom exception handing methods.

Before PHP5 one had to resort to specific return values or drastic measures like trigger_error(). Planning exceptions, I found out, is just as important as class design. At any point where a developer needs to handle the possibility of an exception being thrown he needs to know: what Exceptions can I expect and what Exceptions do I plan to catch? In this post I'll show some important aspects to consider when planning exceptions.

He starts off with a basic example of an exception, throwing it and catching it, as a part of a SOAP client sample and looks at things to catch, how to catch them and doing fun things like rethrowing and extending basic exception types.

The Bakery has a new CakePHP tip posted today showing how to improve the unbindModel handling on the model side of things (versus in the controller as mentioned previously).

The problem with that solution is that it requires you to change the way you define your model relations. [...] Rather try to change your code to suit your needs, and let CakePHP do what it does best: act as a framework.

The technique approaches the associations differently - loaded and called when you make the call to expects() versus just automatically. They include the code to make it all work for an extension to the Model (AppModel), and extension to the AppModel (Title), and finally the TitlesController that shows the deliberate calls to expects to pull in the models.

The Bakery has a new CakePHP tip posted today showing how to improve the unbindModel handling on the model side of things (versus in the controller as mentioned previously).

The problem with that solution is that it requires you to change the way you define your model relations. [...] Rather try to change your code to suit your needs, and let CakePHP do what it does best: act as a framework.

The technique approaches the associations differently - loaded and called when you make the call to expects() versus just automatically. They include the code to make it all work for an extension to the Model (AppModel), and extension to the AppModel (Title), and finally the TitlesController that shows the deliberate calls to expects to pull in the models.