In a recent post to his blog Dhiraj Patra looks at the caching functionality that PEAR has to offer via the PEAR Cache package.

Caching is currently a hot topic in the PHP world. Because PHP produces dynamic web pages, scripts must be run and results must be calculated each time a web page is requested, regardless if the results are the same each time. In addition, PHP compiles the script every time it is requested. [...] PEAR's Cache package offers a framework for the caching of dynamic content, database queries, and PHP function calls.

He talks a bit about what kind of methods are included with the package and shows examples of how it works for function call caching, caching the output from the script execution and how to implement your own custom caching extension of the main code to make it even more flexible.

On the NETTUTS.com website, there's a great article with some "essential security considerations" that you can use to see just how hackable your site could be.

This article walks through the brainstorming stage of planning for what is in this instance, a hypothetical user-centric web application. Although you won't be left with a complete project '" nor a market ready framework, my hope is that each of you, when faced with future workloads, may muse on the better practices described. So, without further ado...Are you sitting comfortably?

The tutorial is broken up into a few sections based around an example with a few points of failure (about book information). They work through the thought process behind the code, using the $_REQUEST variables correctly, preventing SQL injections, filtering the HTML output and a sample code download for you to see how it's all tied together.

Jonathan Snook hands off a handy tip for the CakePHP developers out there concerning the debugging information that can be displayed at the bottom of your application's pages.

I just wanted to document this somewhere but whenever I work on a CakePHP project, there's always the debug info that sits at the bottom of the page. It's big and bulky and once I'm off the default CakePHP styles, it's usually pretty ugly. I've done various stylings but I finally took a moment to implement a really simple idea: Fixed position the table and then use hover styles to toggle the visibility.

He includes the simple four style entries that can be used to tame this debugging information down into something a bit more useful (and less intrusive).

Mike Bernat is a big fan of XDebug and has posted about why he thinks installing it is the best decision you'll ever make.

I finally got around to installing Xdebug on my development environment and have decided it is the best thing since sliced bread. Installation was a breeze and the information it provides when something has gone wrong is incredibly helpful during debugging.

He explains what the software does, how it can help you and your development - even how to get it up and running on your PHP install (seriously, it's drop dead easy...why haven't you installed it yet?). He also points to the tutorial on the Zend Developer Zone introducing the powerful tool.

Joakim has let us know about the recent updates that have been made to the WebGrind web-based frontend for XDebug.

Webgrind, the web frontend to Xdebug has been updated to version 0.7 with a few new features like: Support for directly loading a report through hash in url, Visual breakdowns of internal, class and procedural functions and calls to include/require and Version checking.

This new version (0.7) can be downloaded directly from its Google Code page.

Stefan Mischook so eloquently expresses his opinion on a method for looping in the CodeIgniter framework in this new post to the KillerPHP blog today, "Note to CodeIgniter nerds: please, no looping code in your views."

I was researching things 'nerd' on the Web today, and I found myself at the CodeIgniter website. [...] I'm wondering about CodeIgniter's decision to place PHP looping code in their views.

He notes that the whole point of the View in the Model/View/Controller framework is to keep as much PHP out of it as possible. In their example they show just the opposite. Some of the comments agree with his post, noting that this is in fact the point of the View. Others, however, point out that code in the View, especially looping code is something necessary to output multiple items being passed out.

Matthew Turland has written up a new tutorial explaining something that isn't "currently very well documented" in the Zend Framework - output filters.

They're mentioned in passing in the Zend_View documentation, but not reviewed in detail anywhere in the Reference Guide as of version 1.5.2. I was curious enough about how to implement markup minification that I decided to trace through the Zend_View source code in attempt to discern how output filters actually worked. As it turns out, it's actually pretty simple.

He explains a simple example of how they work, using a Zend_View object to build the filters on (addFilterPath/setFilterPath), and how he created his own output filter - the Minify filter. A minifier removes the comments and whitespace in the output to help reduce its size.

Padraic Brady has posted a new entry in his series on developing blogging software with the Zend Framework today. It's no new content, but it is a contained version of a previous part (part 9) marked up in Docbook and pushed out into a PDF.

After my playtime with Docbook and PDF generation, I decided to make a sample PDF of the current Part 9 of the tutorial series. Your comments as to layout, style, portability and other facets that make a PDF worth downloading are very welcome. Eventually the whole series will be available in this format as well as HTML.

He's using Docbook 5, Docbook XSL and Apache FOP to generate the files. Syntax highlighting is done through Phing.

Inspired by the nice web interface that the Alternative PHP Cache provides (apc), Harun Yayli decided to hack together his own version for the memcache caching software.

For a long time I was looking for a nice web interface like the apc.php (comes with the apc's source) that displays whole nine yards of stats. [...] Anyways, I decided to rip write my own. Totally based on the original apc.php (I even recycled some functions) and apart from completeness, here is a memcache.php that you can get stats and dump from multiple memcache servers.

Here's the output of his script and he's made the source for it available for download as well.

DevShed has posted the second article in their series looking at benchmarking your PHP scripts. This time they look at the use of "timers" to check on script execution length.

Since you already know how to create timer functions and classes, in this tutorial, I'll create some concrete examples that show where these timing mechanisms can be applied in order to evaluate the performance of certain PHP applications.

They create a few classes that connect to a database and pull out rows (handing it off to a Result class). They use these classes in two examples - one with compression (output buffering) and one without using their Timer class to evaluate the differences.