No matter how hard you try to test your PHP applications before putting them in production, you will always ship code to your server that has bugs. Some of those bugs will be very serious and need to be fixed before they cause greater damages to your application data that may be too hard to recover. Read this article to learn about a several good practices that you can apply to track bugs in production code, so you can fix them before it is too late.

Suggestions included in his list are things like:

• Test as Much as Possible Before in your Development Environment
• Separate your Code from Environment Configuration files
• Track PHP Errors with Assertion Condition Tests
• Send PHP Errors to an Error Log File
• Monitor the PHP Error Log File to Quickly Fix Serious Bugs
• Fix Your Bugs but Never Edit Code on the Production Server

He also includes a brief look at some things to think about when considering "defensive coding practices" and links to other articles with more information.

I had the occasion to try out and adopt Behat for a particular need in our projects at Onebip. Here is my recount of the experience from a PHPUnit contributor and invested person.

He starts off with a list of situations where he doesn't think that Behat is a good fit for testing including testing of a single object and acceptance tests where comparing the response from more than one test is needed. He suggests that it's more useful for verifying high level business rules than anything. He talks some about the shift they made to using Behat and some of the benefits they found in its use. He finishes up the post by looking at the technical side and includes a warning about letting the size of the FeatureContext file get too large.

• Todd Lombardo on user context
• Stefan Priebsch on data and persistence
• Patrick Allaert about data structures
• June Henriksen on the human side of programming

You can find out more about this issue (and go download your free copy) on the Web & PHP site. There's also seven previous issues, all free for download (PDF format)!

As someone who frequents the PHP tag on StackOverflow I pretty often see questions about how to parse some particular aspect of HTML using regular expressions. A common reply to such a question is: "You cannot parse HTML with regular expressions, because HTML isn't regular. Use an XML parser instead." This statement - in the context of the question - is somewhere between very misleading and outright wrong. What I'll try to demonstrate in this article is how powerful modern regular expressions really are.

He starts with the basics, defining the "regular" part of "regular expression" (hint: it has to do with predictability) and the grammar of the expressions. He talks about the Chomsky hierarchy and how it relates to the "regular" as well as a more complex mapping of expression to language rules. He talks about matching context-free and context-sensitive languages and unrestricted grammars as well.

In the first part of this blog post we've talked about the theory behind REST services. In this post we put the theory into practice with the help of some code snippets you can implement in your own application.

He starts by helping you create a simple REST controller (well, cut-and-pasteable code, really) that can handle multiple output formats/contexts - XML, JSON and HTML. Next up is the helper (Service_Controller_Action_Helper_RestContextSwitch) that's not much different than the normal context switching helper. With that in place he moves on to the plugins - an accept-hander that sets the correct format based on the Accept HTTP header information and a media-format plugin to check "permissions" on the context to see if that type is allowed in that environment.

I had already build my apps using static HTML output generated by Zend Framework, so how could I add this richness to my apps without refactoring most of my code ? Simple, by using Zend_Controller_Action_Helper_ContextSwitch, ZendX_JQuery and some minor adjustments to my view scripts.

He includes some code (that's confirmed to work with ZF 1.10.3) using the contextSwitch method on a helper object that adds in the "json" type for the contexts that can be used for the responses. Then a new template is added for the type (like index.json.phtml for the json output). Make a change or two to your bootstrap file to add in the right jQuery helpers and your view is as simple as calling "$this->jQuery".

The problem is that BIRT needs to be started once, and only once, in any given process. Once it has been started up, then it is plain sailing to load reports and render them to HTML. The BIRT runtime should be kept around until the process shuts down.

Two problems came up with this approach - if each PHP process makes its own BIRT process any settings/current data will be wiped out and the BIRT instance would go away whenever the PHP script finishes. He found something that solves both of these problems - the Zero Global Context. Its a "storage area" that can contain just about anything. He used it to store the BIRT runtime until its told to finish and die off.

The great thing about WordPress is that it doesn't limit how content is displayed, but provides a 'framework' of ways to do so. Even better, it's possible to change the display according to the content. When writing this tutorial it was hard to explain what's going on... But the best way is this: the post will be displayed within the loop according to its content - or contextual differences. Either way, it's including specific files that match up to the category of the post.

There's plenty of code to go around introducing you to the parts of the typical WodPress install you'll be working with and some CSS to help you style the resulting changes. You can download the source and check out a live demo of the end result.

Every time I search for the code snippet that allows you to do an HTTP POST request, I don't find it in the manual and resort to reading the source. So, here's an example of how to send a POST request with straight up PHP, no cURL.

The example uses stream_context_create, fopen, stream_get_contents and an Exception to send off the message from an inputted array to the remote server. Smaller things, like the Content-length header on the request, are automatically handled by the wrapper functionality. You can check out this page for more information on the wrapper functionality.