Sebastian Bergmann has a new post today about a feature of the PHPUnit unit testing tool that has the possibility of breaking when objects are introduced - backing up the globals.

It is hard to test code that uses singletons. The same is true for code that uses global variables. Typically, the code you want to test is coupled strongly with a global variable and you cannot control its creation. An additional problem is the fact that one test's change to a global variable might break another test.

You can disable the backup option if you'd like by setting the $backupGlobals option in your test to false. This lets PHPUnit know that you want to leave the globals (and superglobals) alone during the run.

On DevShed today there's a new tutorial showing how to build file upload functionality into your scripts.

If you're a PHP developer who has built a certain number of web applications, then it's quite probable that you've already worked with HTTP file uploads. [...] First I'm going to teach you how to handle file uploads using a procedural approach, and then, with the topic well underway, by way of the object-oriented paradigm.

The introduce the beginners out there to the $_FILES array (a superglobal) that contains the details about the file(s) that have been submitted. Next comes the construction of a simple form and how to handle the submission on the PHP side.

In a new post to his blog today, Stoyan Stefanov has a proposal to being something PHP users are very used to - superglobals - over to Javascript.

Javascript has implied globals. When you skip the var in var a = 1; and go a = 1;, then a becomes a global variable. Some consider this an error in the language. [...] In PHP on the other hand, variables are local. [...] So how about this: adopt the $GLOBALS convention in your JavaScripts?

His example proposes the creation of a GLOBALS object you can assign properties to that can be used anywhere. This helps to keep the variables you truely want to be global contained, though it doesn't do much except provide a convention.

As Ed Finkler points out there's a new article posted (written by him) on the C7Y site (from php|architect) talking about his Inspekt library - an introduction to the filtering library showing how to help make your applications safer.

Inspekt is a library for PHP4 and PHP5 that aims to make safe input handing easier, and unsafe actions more difficult. Inspekt establishes a new development approach by wrapping input within "cage" objects, and requiring the developer to use validation and filtering methods to test and manipulate the input data. This article provides a brief introduction to Inspekt and its capabilities.

The article covers all of the basics - what the library can do for you, how it integrates into your application and how it helps to protect you from potential problems with the data in your superglobals ($_GET, $_POST, $_REQUEST, etc).

In one of his recent blog entries, Brian Moon takes a look at what he considers the "proper use" of the PHP superglobal $_REQUEST (as brought on by a thread on the PHP internals mailing list.

I have seen more than one person make the following logic mistake: I may get data via GET, I may get data via POST - Ah, I should use $_REQUEST as it will catch both.

Brian points out the error - cookies aren't in $_REQUEST so improper handling of those values could lead to cookie data overwriting GET/POST data from $_REQUEST. Several of the comments on the post also warn against improper handling of the values, noting that doing so could lead to holes open for attacks (like session fixation).

Gareth Heyes has a new post today talking about one of the vulnerable values in the $_SERVER superglobal - PHP_SELF.

I thought it might be a good idea to gather a few test cases demonstrating the problem. Why PHP allows these URL's is beyond me and it wouldn't take much work to filter out these malicious URL's in the PHP code.

He provides four test cases to show how simple it is to abuse - one using a HTTP header, another pushing XSS through, the third mentions search pages and the fourth a direct code injection.

You can download the code here.

On the SitePoint PHP blog, there's a quick tutorial from Troels Knak-Nielsen about the creation and use of dynamic global functions in your PHP application:

Like many others, I prefer to use procedural PHP as a template language. While PHP's syntax makes it a practical choice for this, there is a problem with embedding dynamic content. [...] A single letter, regular function is undoubtedly the simplest way to extend PHP's syntax. Thinking about it, it's fairly obvious, but it just never occurred to me. [...] There is a problem though; Since this is such a good name for a function, chances are that someone else would use it for something different, or perhaps even for the same.

As a more viable solution, he recommends going dynamic and creating fumctions (via the call_user_func_* functions) and an addition to the $GLOBALS superglobal to make calling the custom function simpler.

PHPBuilder.com has a new article published today that works through some of the basics behind using the superglobal variables in PHP.

This month's article is aimed at PHP developers who're not yet familiar with the PHP superglobals. Usage of superglobals is fundamental to PHP web development, but, with all the recent changes in PHP, there are still many outdated tutorials, books, and sadly, still much confusion.

They look at how to use them in a PHP script (in an HTML page) and what's contained in each of them (_GET, _POST, _ENV, _SERVER, etc).

Guilherme Blanco is proposing an interesting idea in his new blog entry - adding built in functionality to the PHP core that would allow a developer to register their own custom suprtglobals.

Currently, we deal with a lot of interesting situations of web applications, and some really interesting are the superglobals variables. Seems there will be a change in superglobals soon and that's why I decided to post about it here.

His example of the need for something like this is as an alternative to using the Singleton pattern to work with multiple database connections in an application. His proposal is that, by including this register_superglobal functionality, it would make it easier to share these kinds of connections. He even includes a simple code example of how it might look.

From the JSLabs blog today there's an extremely basic debugging helper class to get you started finding that error in your code.

Debugging PHP scripts can be a difficult task, so I have written this simple php debugger class. It will display all GET and POST variables and all the properties on a currently defined object.

The code is about 20 lines long and does the most basic method of debugging - spitting out the current values of the $_GET and $_POST superglobals. It wraps it all up in a function so you can call it with one line.