Matthew Turland has a post to his site sharing his experience with the PHPUnit and XHProf combination...and the unfortunate result that made every test fail.

I ran into an issue recently while trying to run PHPUnit tests in an environment using XHProf. Google didn’t prove to be much help, so I thought I’d document the problem and solution here for posterity.

When I ran my tests, each failed with the same cryptic error and no backtrace: "Attempted to serialize unserializable builtin class PDO" The cause was the culmination of two rather unfortunate circumstances.

He shares the two problems that causes this issue - one being XHProf's use of globals (where its PDO connection is stored) and the other is the @backupGlobals setting in PHPUnit that's enabled by default. This makes PHPUnit to try to backup that PDO connection by serializing it but can't, hence the failure. He points out a pull request that aims to fix the issue but recommends disabling the globals backup for the time being if you don't have a need for it.

Matthew Weir O'Phinney has two new posts that talk about something object-oriented developers seem to shy away from - globals in their classes and how they can make things more difficult to make "embeddable applications" a reality.

In my previous entry, I ranted about the use of globals in popular PHP applications, and how they make embedding said applications difficult. I develop using object-oriented practices, and can honestly say I can't recall ever having slung a global variable around in my own code. Globals seem hackish to me, and as a result, trying to get applications that use them to behave correctly has been a challenge.

In the first part, he notes an interesting find about the $GLOBALS value and illustrates with a code example how he was able to get around it in his instance (wrapping a Serendipity instance in a Zend Framework app).

In part two, though, and uses another code example to show what kind of issues he was seeing with the $GLOBALS - a script that sets some globals in different instances and echoes the results back out.

Matthew Weir O'Phinney has two new posts that talk about something object-oriented developers seem to shy away from - globals in their classes and how they can make things more difficult to make "embeddable applications" a reality.

In my previous entry, I ranted about the use of globals in popular PHP applications, and how they make embedding said applications difficult. I develop using object-oriented practices, and can honestly say I can't recall ever having slung a global variable around in my own code. Globals seem hackish to me, and as a result, trying to get applications that use them to behave correctly has been a challenge.

In the first part, he notes an interesting find about the $GLOBALS value and illustrates with a code example how he was able to get around it in his instance (wrapping a Serendipity instance in a Zend Framework app).

In part two, though, and uses another code example to show what kind of issues he was seeing with the $GLOBALS - a script that sets some globals in different instances and echoes the results back out.

The International PHP Magazine is back once again with the results from this week's poll that asked "Do you believe the following about PHP?" Options included:

• PHP administrators like to compile PHP in Summer
• Register global is not dead
• memory_limit is not used
• PHP applications handle 100 Mb files

And coming out on top with 17.7% of the votes was the "Register globals" option, and coming in right behind was "handle 100Mb files" with 12.7% of the votes.

They've also posted a new poll for this week that asks "Why should a developer use CakePHP?" Check it out and vote for your choice of the six options.

The International PHP Magazine is back once again with the results from this week's poll that asked "Do you believe the following about PHP?" Options included:

• PHP administrators like to compile PHP in Summer
• Register global is not dead
• memory_limit is not used
• PHP applications handle 100 Mb files

And coming out on top with 17.7% of the votes was the "Register globals" option, and coming in right behind was "handle 100Mb files" with 12.7% of the votes.

They've also posted a new poll for this week that asks "Why should a developer use CakePHP?" Check it out and vote for your choice of the six options.

In this new tutorial from PHPit.net today, Dennis Pallett talks about using globals in PHP, desscribing what they are and how to use them.

Whenever you're developing a new large-scale PHP script, you're bound to use global variables, since some data needs to be used by multiple parts of your script. Good examples of global data are script settings, database connections, user credentials and more. There are many ways of making this data global, but the most commonly used way is to use the global keyword, which we will explore later on in this article.

It's good that he mentions right from the start that most global data is a bad idea, and can really start to clutter up an application. He does help the reader prevent this, though, through the use of a few handy techniques (and design patterns).

He looks first at the "global" keyword and its use, followed by three reasons that it's not all that favorable to use. He gives other options for the "just make it global" thinking, including passing the values in function calls, passing by reference, and using the Singleton and Registry patterns to contain things a bit more. He even includes a wrapper for the registry to handle the only other globals left - the superglobals - with the same registry functionality.

In this new tutorial from PHPit.net today, Dennis Pallett talks about using globals in PHP, desscribing what they are and how to use them.

Whenever you're developing a new large-scale PHP script, you're bound to use global variables, since some data needs to be used by multiple parts of your script. Good examples of global data are script settings, database connections, user credentials and more. There are many ways of making this data global, but the most commonly used way is to use the global keyword, which we will explore later on in this article.

It's good that he mentions right from the start that most global data is a bad idea, and can really start to clutter up an application. He does help the reader prevent this, though, through the use of a few handy techniques (and design patterns).

He looks first at the "global" keyword and its use, followed by three reasons that it's not all that favorable to use. He gives other options for the "just make it global" thinking, including passing the values in function calls, passing by reference, and using the Singleton and Registry patterns to contain things a bit more. He even includes a wrapper for the registry to handle the only other globals left - the superglobals - with the same registry functionality.