Derick Rethans has posted a new part of his series looking at the improvements that came with the latest Xdebug release (v2.3). In this new article he talks about error handling and intercepting them to make debugging simpler.

One of the first features I added to Xdebug was the interception of error messages, so that it was possible for me to include a stack trace. Xdebug 2.3 has a few additional settings to control the behaviour of interception.

He covers the addition of three new settings: xdebug.halt_level, force_display_errors and force_error_reporting. Each of these is designed to provide you with customizable error reporting. Each setting comes with an example of its configuration and how it modifies the output of the resulting errors.

Pádraic Brady has a new post to his site today talking about a security-oriented PSR that's being proposed to the PHP-FIG group (by Lukas Smith). The proposal suggests the creation of a security policy to be used by members of the PHP-FIG and a way to make sharing security issues more standardized.

Lukas Kahwe Smith recently brought forward an idea to PHP-FIG with two broad objectives for a new PSR: To write a security policy that could be adopted by members; and proposal to make sharing security vulnerabilities more common and standardised. He has invited interested people to express their interest in joining a separate mailing list to discuss the details: https://groups.google.com/forum/#!topic/php-fig/45AIj5bPHJ4. Larry Garfield of Drupal and Korvan Szanto of concrete5 CMS have offered to sponsor the proposal.

He talks some about security policies in general - what they are, why they're a good idea and what Lukas is proposing for PHP projects. He also briefly covers the publishing of vulnerability data, the different options for publishing them and how the standardization of it could be integrated with current tools (Composer anyone)?

On the NetTuts.com site they've posted a tutorial showing you how to build advanced features with IMAP and PHP. He bases it on the SimplifyEmail project and incldues examples of three different features to get you started.

Analysis of my own email showed I was receiving email from more than 230 automated senders, far fewer actual people. I was tired of constructing filters in Gmail and filling in a myriad of unsubscribe forms. I wanted to have more control over managing my email and simplifying my life. Finally, this past year, I decided to build the features I needed. The result is Simplify Email (SE), a small web app you can host yourself which offers a variety of cool new email features all of which you can check out on the project website. The coolest thing about SE is that it's a platform for reading, analyzing, routing and managing your email - the possibilities abound. Simplify Email is essentially a programmable playground for "hacking" your own email.

His three examples show you how to:

• Checking your inbox and filter messages
• Implement a Whitelist challenge to unknown senders
• Reporting unanswered email

Each of these comes with plenty of code examples, screenshots and output examples (as well as some places where you might need to change some SE configuration values).

On PHPMaster.com today there's a new tutorial from Sneha Heda looking at error handling in PHP - the types of errors that can come up, how to throw your own and how to catch them appropriately.

Errors are the most common event a developer faces when programming. [...] To help reduce the number of errors in your code, and to mitigate their effects, proper error handling is essential in your web application. This article is a crash course in PHP error handling. You’ll learn about PHP’s built-in error reporting levels, and how to handle errors with custom error handlers and exception handling.

She starts with the different error reporting levels PHP offers, everything from the lightweight E_NOTICE out to E_ALL|E_STRICT. With this as a reference, she shows how to create a custom error handler (using set_error_handler). Also included is a look at exceptions and some of the more detailed information that comes with them - line numbers, messages, file the error was thrown from, etc.

Brian Swan has a new post to his MSDN blog today that looks at working with the SQL Server Reporting Services SDK and PHP to automatically create some reports based on the date in your database.

In this post I’ll dive into the SSRS SDK for PHP that was recently released by the Interoperability team here at Microsoft. [...] The documentation in the SDK is complete with explanations for the classes that make up the SDK, code examples, and a “hello world” example. However, in this post, I’ll build a simple web page (code attached to this post) that renders the Sales report that I created last week.

He starts off with an overview of how all of the technology will fit together and some of the things you'll need to have before you can get started - a user with the right permissions and a connection to the server. The "SSRSReport" class in the SDK gives you quick access to load a report based on a named location. You can then use methods like "RenderAsHTML" to output it as HTML or one of other methods (like CSV, text, PDF, etc).

On the ZendCasts.com site there's a new screencast continuing their look at the Zend_Tool component by combining it with Zend_Log to do some easy reporting.

This video uses a collection of powerful PHP libraries in order to illustrate how easy it really is to build a command-line tool for reporting against XML files. We start off by logging visitor statistics in the controller into a log file with Zend_Log. Once data has been collected, we’re then able to utilize SimpleXML, Zend_Date and the Zend_Tool component to build out a very simple reporting tool.

He suggests one possible use is to create a cron job that will regenerate the reports nightly. You can view the screencast in the post or download a copy of the project to get started right away.

Kevin Waterson has posted a new article to his site today - an introductory look at security in your PHP applications.

One of the great benefits of PHP is its ease of access to new-comers. Its entry level is minimal and so attracts those looking for simple scripts to their sites. It is this same ease of access that becomes a problem as the new-comers begin to deal with input from users. Failure to adequately validate and sanitize data is the leading cause of security problems when dealing with PHP.

He looks at a few different areas that developers need to focus on (and be sure to filter on) like PHP_SELF, protection from email header injections, file inclusion and the use of error reporting to make handling user-generated errors "more correct".

Padraic Brady has made a few updates to the PHPSpec software he's developed in preparation for the first stable release - additions to the reporting functionality to give as much information as possible.

PHPSpec is closing in on its first stable release, so the time had finally come to spruce up its output! No more the simple reporting of failed specs - now you get a few more details in a readable format, exceptions and errors even come with traces. In addition, I've implemented specdoc output as an option (using "-s") so you can get a list of specs in their plain text form.

He's also included an example of the new output in the post as well, showing the results of both successful and errored responses. You can check out the actual spec files on the googlecode repository for the project and get more details on the project itself (including the latest development snapshots) on the project's website.

Padraic Brady has made a few updates to the PHPSpec software he's developed in preparation for the first stable release - additions to the reporting functionality to give as much information as possible.

PHPSpec is closing in on its first stable release, so the time had finally come to spruce up its output! No more the simple reporting of failed specs - now you get a few more details in a readable format, exceptions and errors even come with traces. In addition, I've implemented specdoc output as an option (using "-s") so you can get a list of specs in their plain text form.

He's also included an example of the new output in the post as well, showing the results of both successful and errored responses. You can check out the actual spec files on the googlecode repository for the project and get more details on the project itself (including the latest development snapshots) on the project's website.

The Zend Developer Zone has starting up their own contribution to the security side of the PHP community - a "Security Tip of the Week" starting with the first three new ones posted just recently:

• Tip number one involves a good recommendation - keeping your PHP version up to date. Many security issues and exploits have come around because of older versions and the issues they hold.
• Tip number two focuses on the errors that your site gives to the viewing public and the information they can betray (file locations, etc)
• Tip number three talks about using other applications to help you find issues in your code that you might not even know were there - such as Chorizo and the PHPSecInfo reporting tool.

Stay tuned for even more security goodness from Cal and the Zend Developer Zone over the coming weeks...