Continuing on from his previous post introducing you to the ZFTool for Zend Framework 2 applications, Matthew Setter has posted part two of the series focusing on the creation of custom diagnostic classes for the tool.

In this week’s tutorial, we’re going to see how to step beyond the in-built classes and write our own custom checks. Specifically, we’re going to write a check which runs php lint on the module’s config file, module.config.php. The reason for doing this is because this file is so important in the configuration of a ZF2 module, that we should have a helpful sanity check for it.

He starts by helping you get all the needed dependencies in place, the ZFTool and ZendDiagnostics modules, installed via Composer. He includes code to help get started on the new diagnostic class and accompanying files. He implements some required methods from an interface, and shows how to enable its checking and define the configuration file. He includes a screenshot of the output so you can ensure things are working as they should be.

The Master Zend Framework site has a new tutorial today showing you how to use the ZFTool diagnostics to make sure your modules are working correctly. The ZFTool is a stand-alone tool that can help with common tasks like working with application configuration and creating module and project skeletons.

Do you want to be sure that when you create Zend Framework 2 modules, that they’ll work in whatever environment they’re used in? At the very least, do you want a simple way for users to check, as well as something that’s self-documenting? If so, you’re in the right place. Last year, I gave a basic introduction to ZFTool, which is a command line tool to manage applications written in Zend Framework 2. [...] In addition to [the included diagnostic checks] we can write our own diagnostic checks, using the Success, Failure and Warning classes. So in today’s tutorial, I’m going to show how to add diagnostics support to a module.

He's broken the rest of the tutorial up into four other parts, each with the code or commands you'll need:

Add Diagnostics Support

The Diagnostics Function

Running Module Diagnostics

When Checks Fail

You can find out more about the ZFTool and its usage in with diagnostics in the official manual

Matthew Setter has posted a new tutorial about using the ZFTool functionality of Zend Framework v2 for managing your project's settings and configuration.

Welcome to another tutorial. Today, I will be giving you a walk through of zftool, which provides basic tooling support in Zend Framework 2. If you’re new to Zend Framework, or have been reading the introductory series here, it can come in quite handy. But unlike other frameworks, such as Yii (through yiic) and Symfony (via the Command Line tool), the tooling support in Zend Framework 2 is rather light on. These respective tools provide rather robust support for automatically generating models from database connections, checking logs and a host of other much required functionality.

He shows you how to do a few things with the ZFTool - create a new project, make some modules inside it, build an autoloader classmap and check the installation with some basic diagnostics. Command examples and configuration samples are included in the post to help you along.

Application profiling can help us determine bottlenecks and possible problems during development. But sometimes we also need to diagnose problems in production environment. Frequent performance problems are connected with functions and methods using too much memory.

The tool allows you to set up thresholds for memory consumption and, if the scripts exceeds it, add warnings to your log files. He includes the simple instructions to install it (via PECL) and enable it in your php.ini. Some sample code to create a memory overvload is included to test it out. Configuration options let you set the limits and define functions to ignore if you know for sure there's trouble spots.

In a new tutorial posted to his blog today, Pierre-Alain Joye shows how to generate backtraces on a Windows machine without the need for a compiler installed.

How to get a back trace on windows without having to compile PHP has been an impossible task for many of us. The difficulty was to first succeed to compile php (given that you have a visual C++ installed). If you are in the middle of a bug hunting session, no need to say that setting up a windows build system is the last thing you like, especially if it is your first time. Thanks to Edin's window binary and MS Diagnostic Debug , it is now possible to have a backtrace in a couple of clicks.

To use the method you will need a few pieces of software to help out but all are available for free. Next up are the steps to get things set up (simple) and the creation of the backtrace to catch the error, complete with screenshots for the whole way. The end result is a nice, pretty error message output to the browser (Internet Explorer) that also dumps the backtrace for you to use.

In a new tutorial posted to his blog today, Pierre-Alain Joye shows how to generate backtraces on a Windows machine without the need for a compiler installed.

How to get a back trace on windows without having to compile PHP has been an impossible task for many of us. The difficulty was to first succeed to compile php (given that you have a visual C++ installed). If you are in the middle of a bug hunting session, no need to say that setting up a windows build system is the last thing you like, especially if it is your first time. Thanks to Edin's window binary and MS Diagnostic Debug , it is now possible to have a backtrace in a couple of clicks.

To use the method you will need a few pieces of software to help out but all are available for free. Next up are the steps to get things set up (simple) and the creation of the backtrace to catch the error, complete with screenshots for the whole way. The end result is a nice, pretty error message output to the browser (Internet Explorer) that also dumps the backtrace for you to use.

The Zend Developer Zone has posted security tip #15 today, focusing on an easily forgotten aspect of web development (not just in PHP) - forgetting to remove temporary files.

As developers, most of us are very messy. I've worked on countless projects and at each either run across or left a trail of diagnostic files laying around. (info.php, test.php, doMe.php, etc.) These tiles, if found by someone with nefarious intent, can leak valuable information about your system.

Always remember to remove these types of files...as Cal puts it:

It would be a shame to spend all that time securing your application only to leave info.php or worse yet, a "quick piece of code" in test.php that could potentially leak dangerous information about your system. Don't help the ad guys any more than you have to.

The Zend Developer Zone has posted security tip #15 today, focusing on an easily forgotten aspect of web development (not just in PHP) - forgetting to remove temporary files.

As developers, most of us are very messy. I've worked on countless projects and at each either run across or left a trail of diagnostic files laying around. (info.php, test.php, doMe.php, etc.) These tiles, if found by someone with nefarious intent, can leak valuable information about your system.

Always remember to remove these types of files...as Cal puts it:

It would be a shame to spend all that time securing your application only to leave info.php or worse yet, a "quick piece of code" in test.php that could potentially leak dangerous information about your system. Don't help the ad guys any more than you have to.