On the Laravel News site they've introduced a package from Adam Wathan that cam help simplify the use of the popular Guzzle package for making HTTP requests. Zhttp is a wrapper around Guzzle and tries to make the code to make the requests simpler and easier to follow.

Zttp is a new PHP package by Adam Wathan that is a Guzzle wrapper designed to bring an expressive syntax and simplify common use cases. [...] Zttp simplifies the code to make the request and automatically returns the JSON response.

A few other examples of requests using the tool are provided: POSTing with parameters, sending a PATCH/PUT request, adding an Accept header and how to prevent the request from following redirects. You can find out more on the project's GitHub repository and grab the latest release to try out in your own code.

Richard Melo has a post to his site sharing some helpful advice about running legacy PHP applications from the command line making use of the Symfony Console component to handle some of the heavy CLI duties.

Imagine that you already have a trustfully application that you have been running for a while, but there is a couple of common patterns that make you consider that you need a command line interface (CLI) for your application. [...] So, how do we do this? especially without reinventing the well?

He starts off with an example of the problem, having a bit of a legacy application that needs to take in data (in this case JSON) and handle it would requiring a form submission. He makes use of the Console component to wrap this functionality inside a command and take a JSON file as input. He includes the example code needed to make this simple setup including the Command class itself and a small "bootstrap" command line script to do the actual command execution. The post ends with an example of the command you'd use to run the script and push in the JSON contents.

Barry vd. Heuvel has a new post sharing a method he's found for using StackPHP middleware with Laravel 5 and provides a library of his own to make moving between the middleware types easier.

In version 4.1, Laravel introduced compatibility with StackPHP middleware. [...] In Laravel 5, a lot of things changed. And with those changes, Laravel also removed the support for StackPHP middleware and introduced its own middleware contract.

As the two types of middleware have interfaces that slightly conflict, he shows how to convert from one to the other (a relatively simple change). He then shows how to use the middleware in a Laravel 5 application, but brings up a "chicken and the egg" situation where a wrapper for the HttpKernelInterface is needed for correct injection. To that end he created two simple wrappers, the ClosureMiddleware and ClosureHttpKernel handlers that can be used to simplify this middleware translation.

Pádraic Brady has a new post today sharing a tool he's created to enhance the current PHP file_get_contents function with a safer, more secure alternative, the humbug_get_contents library.

With the release of PHP 5.6, there was a significant security improvement in how PHP handled SSL/TLS protections, namely that it enabled a secure set of default options. Previously, SSL/TLS was disabled by default. No peer verification, no certificate checking, and a lack of configuration options had combined to create a serious problem. You can find this problem easily by searching for file_get_contents() on github and locating a call to this function used to retrieve any HTTP resource while also having zero configuration.

An excellent example of this is Composer which uses file_get_contents() instead of curl to ensure maximum compatibility with using systems. Of course, this beggars a question. If all the SSL/TLS protections are off by default in PHP 5.3-5.5…what’s stopping some irksome hacker from injecting bad code into our Composer downloads? Answer: Nothing.

The package provides a drop-in solution to the possible man-in-the-middle issues that could be caused by the native functionality. It enhances the current function with additional TLS/SSL checking for HTTPS requests on current PHP versions.

In the latest post in their series looking at common programming design patterns, NetTuts.com talks about the Adapter pattern. This pattern makes it easier to swap out different connection types via an abstracted interface.

In this article, we will continue our discussion on design patterns by taking a look at the adapter design pattern. This particular pattern can be used when your code is dependent on some external API, or any other class that is prone to change frequently. This pattern falls under the category of "structural patterns" because it teaches us how our code and our classes should be structured in order to manage and/or extend them easily.

He starts off with the problem he's aiming to solve: a change in a "Twitter" class from one method name to another. An "adapter" lets an existing class be used from another interface, requiring no to minimal changes to the original class. He refactors the example to use an example of an adapter, creating a class that defines an object that passes in the original "Twitter" class instance and wraps the "send" call in its own method. With this in place, he also shows how to create a brand new adapter for Facebook, mimicking the "send" method, just with different functionality.

Paul Jones has a new post with more information about his proposed "Action-Domain-Responder" design pattern (a replacement for the typical MVC) and suggests a new piece, the Domain Payload pattern. This pattern would use a domain payload object to wrap the data and provide the responder with additional handling and context.

In Action-Domain-Responder the Action passes input to the Domain layer, which then returns some data for the Action to pass to the Responder. In simple scenarios, it might be enough for the Responder to inspect the data to determine how it should present that data. In more complex scenarios, though, it would make more sense for the Domain to pass back the data in a way that indicates the status of the data. Instead of the Responder inspecting the Domain results, the Domain should tell us what kind of results they are.

He shows a code example of this Domain Payload object in action, starting with some typical MVC code and refactoring it along the way into an ADR structure. He shifts from a typical model into a more domain-driven approach and describes the wrapping of the data in the payload, context for the contents (even just a class name helps) and how those relate to the actual output. You can find the resulting code in this example over on Paul's GitHub account.

Matt Frost has shared some of his work he's done with the SoapClient in PHP and how he mocked it out for his unit tests (since it's an external resource).

The concept of mocking web services for testability took a little while to sink in for me. A big part of it was that my job doesn't see me consuming web services all that often, but I had an opportunity to give it a shot with SOAP. I found that I learned a lot more about testing in general having worked through this. I used SoapClient and wrapped it, so here's a little bit about some of things I learned. Hopefully you don't have to work with SOAP, but if you do you can test it pretty easily.

He walks through the mocking of the client itself and how he handled it's ability to translate function calls into SOAP method calls (using "__call") and how he mocked that. He also makes the suggestion that you actually wrap the SoapClient inside of another class rather than trying to mock the actual SoapClient. He also touches on the testing of exceptions that might be thrown by the service and how he tested those using his wrapper class.

On PHPMaster.com today there's a new post (by Remi Woler) that looks at abstraction and keeping functionality out of the framework and more decoupled in case the need for switching environments/frameworks comes up.

Of course you develop using the latest technologies and frameworks. You’ve written 2.5 frameworks yourself, your code is PSR-2 compliant, fully unit-tested, has an accompanying PHPMD and PHPCS config, and may even ship with proper documentation (really, that exists!). When a new version of your favorite framework is released, you’ve already used it in your own toy project and submitted a couple of bug reports, maybe even accompanied with a unit test to prove the bug and a patch that fixes it. If that describes you, or at least the developer you want to be: reconsider the relationship your code has with the framework.

He talks some about the dependencies most code written today has on the frameworks it lives in and how a good project design can make it easier to decouple this relationship. He suggests using things like wrapper classes (think "services") to abstract out the functionality to custom components. It's these components that handle the work, just reporting back the results to the controller/model that called them.

In some of his work with Backbone.js recently, Gonzalo Ayuso has been frustrated by something that's a wall for many developers wanting to work with outside datasources - the browser restriction that prevents cross-domain requests. His solution? Create a REST proxy to live on his server and pass the requests through.

Nowadays there is a header to allow it: Access-Control-Allow-Origin. The problem is that the remote server must set up this header. For example I was playing with github’s API and github doesn’t have this header. If the server is my server, is pretty straightforward to put this header but obviously I’m not the sysadmin of github, so I cannot do it. What the solution? One possible solution is, for example, create a proxy server at localhost with PHP.

He shares the full code for his project - basically a handler that takes the incoming request and mirrors to out to the public, remote API - request method and all. It uses some of the packages from Symfony (like the http-foundation) and wraps around cURL to handle the requests. The project is available for Composer users as well.

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.