I'm now going under the bonnet of our components, and looking at the different file roles that the PEAR installer expects to find when we distribute our component as a PEAR-compatible package. One of the most important file roles allows you to ship your tests with your package - and it's vital that this is something that you get in the habit of doing routinely.

He recommends "testing your code and shipping your tests" along with the component(s) you're releasing. Not only does it help you create a better quality end result but also makes it simpler for other developers to make changes and know they're not breaking things. He describes unit tests for those not familiar and includes a specific example of the CommandLineLibrary and its related tests.

First post of the series discussing various methods of including remote PHP code in your application - from security standpoint. In this post we discuss the history of remote code execution vulnerabilities in PHP apps and ways to prevent them. We finish off by presenting an unsecure method of including a remote code and describe what is the problem with that method.

He looks at the insecurity of a standard include/require, the allow_url_include php.ini setting and the issues with using hardcoded locations (like incorrect DNS records pointing to the wrong host).

This is a topic I describe at length in my Organizing [Your PHP Projects] talk, but I would like to give the idea a home on my blog for easy reference.

He talks about the typical structure of a PHP application - at least where most start out - being the "include" method. He talks about the progression it usually makes into functions and classes and then, eventually, a jump in concept to the "class" method similar to what several popular frameworks have gone with.

The difference is that no program logic is executed at loading time with a class file. Loading the class file makes it available for use, but the programmer has to instantiate it and then call methods on it for anything else to happen.

The conventional wisdom always said that PHP's include()/require() was quicker than include_once()/require_once(), but recently I came across an interesting post by Arin Sarkissian which suggests otherwise. [...] So in keeping with the spirit of quick and dirty experimentation I hacked up some code and ran some tests on include()/require() against include_once()/require_once() and on the relative/absolute path issue. The results are pretty surprising and I love to hear some views.

He includes the testing methodology consisted of creating 10,000 files with a simple variable assignment in them and a loop to run through all of them to record the time (as reported by microtime) switching out the different times of inclusion each time - include, include_once, require, require_once. You'll have to visit the post yourself to see the results of the tests. There's charts and tables showing the differences in results based on things like using APC and PHP4 versus PHP5.

This series uses a variety of code samples to teach you how to create modular programs. These programs are capable of recursively including files required by a given application, without having to explicitly call any "include()/include_once()" or "require()/require_once()" PHP function.

In their example they show how to use their loader class (built up from previous parts of the series) and modify it slightly to allow the script to set the file path, set the files to include and pull them in.

Loading sources on the fly is one of the most common tasks that PHP programmers have to tackle during the development of web applications. This typical situation must be faced independently of the scale of the programs being created. This means a loader mechanism must be developed.

Their basic loader class uses a call to a load() method to do two things - check to ensure that a file exists and, if it does, include it (technically a require_once). They also put a bit of exception handling around it to help catch any errors thrown on the include.

In our company, code reviews play an integral part in the development process for making quality software. We opt for a mentor style approach with Wufoo, where a developer works on a segment for a period of time and then passes it up to a more experienced developer for review.

[...] To reduce this repetition of checking the same requirements over and over], we invested some time creating something we've called the PHP Quick Profiler-we call it PQP for short. It's a small tool (think Firebug for PHP) to provide profiling and debugging related information to developers without needing them to add a lot of programmatic overhead to their code.

The post gives several screenshots of the tool in action and code to get you up and running quickly. The Profiler can keep track of memory usage, "runaway" includes, execution time and database activity. There's also an online demo so you can try it out yourself.

Here's the link to the latest version's download.

I find today that the default "file" stream wrapper in PHP is overwritable. You only need to call stream_wrapper_unregister and then stream_wrapper_register with your wrapper.

He gives an example of a situation where you might need to "catch" certain files as they're requested and replace them with another before they make it back to the source. His example code shows how to create the stream (using stream_open) and set methods to read, write, seek and work directly with the stream resource. It takes the file requested and replaces the "5" in the name - "test.php" is included instead of "test.php5".

I have finally gotten some time to do some long awaited work on PHPUnit. The first on my agenda was a small improvement to filtering. This was related to ticket #526. Essentially I added the ability to do both white list and black list filtering.

Besides the Include methods you can add to the data set's filtering, you can also add in Exclude filters to remove the data you don't want in the set. They can also be combined to customize your data set to your heart's content.

t's one of the basics of PHP and if you read any kind of tutorial or book on the subject it's one of the first things they cover, yet I still see people no using a global 'configuration' or 'include' file. It's one of the easiest things to do and will make your life so much easier! This 'configuration' file will include anything that needs to be run on every page of the website.

They suggest that using this configuration file everywhere (including it over the entire site) can make things easier in the long run. The idea is not without problems, though. It only works until you need something custom for a certain area or page - then you have to hack it to evaluate conditions. For most simple uses, though, its a good way to share information (like database connection details) through out the application.