Today I came across (something like) this little snippet:

if( ! $obj = new myObject( $id ) )
{
  throw new Exception( 'Not a valid object' );
}

At first glance we might assume that the constructor attempts to populate the new object with some data loaded from (say) a database, but if no data matching the supplied ID is available, then the constructor returns false to indicate this. All very reasonable, right?

Except that it’s not possible to return false, or indeed any value, from a constructor because the ‘return value’ of the constructor is the object itself. Which means that the above snippet is redundant, because the expression will always evaluate to true.

It would’ve made more sense to throw an exception within the method that loads the data — and in fact this is exactly what happens, which makes the quoted code doubly redundant and even more inexplicable.

I don’t think I’m the one who’s responsible for this particular brain fart but it’s OK because the only other likely candidate left the company last year so I happily can blame it on him…

Let’s say you have a function (we’ll call it getSomeData())that returns an array, or false if there is a problem (yes you should probably be using exceptions, but let’s just say for argument’s sake that this is a third-party library over which you have no control). So you use a conditional to test whether the function had a problem or not:

// Try to get data
$data = getSomeData();
if( $data ){
  //...do something
} else {
  // There was a problem
  error_log( "There was a problem getting data!" );
  exit;
}

For the uninitiated the if() here calls the function and assigns its return value to $data. If the return value is any non-false value, the condition evaluates to true.

The quirk, if you want to call it that, is PHP’s understanding of what constitutes a ‘non-false’ value. You probably already know that null, 0 (zero) and ” (empty string) all evaluate to false. But the one that still catches me out now and then is that an empty array will evaluate to false, too. So in our above example, we’ll get an error if the getSomeData() function returns successfully, but with no data.

You could fix this with strict evaluation:

// Try to get data
$data = getSomeData()
if( $data === false ){
   //...do something
} else {
   // There was a problem
   error_log( "There was a problem getting data!" );
   exit;
}

…or alternatively (and better, in my opinion) check the return value’s type:

// Try to get data
$data = getSomeData();
if( is_array( $data ) ){
   //...do something
} else {
   // There was a problem
   error_log( "There was a problem getting data!" );
   exit;
}

If you want to know more, check out this blog post that goes into more detail — and points out a couple more unexpected ‘false’ values (the string ‘0′ and an object with no properties) that I wasn’t aware of.

Yes it’s very basic, but that was the point. No, you can’t add captions, or change the order, or have a whizzy rotating slideshow with cute sound effects.

However you can alter the output size of the thumbnails (using the $max_width and $max_height values) and the number of thumbnails in each row of the list table (using the $images_per_row value). The markup is very simple too so you should be able to alter the layout quite easily if you feel the need.

What’s it good for? Well if you just want to dump images into a folder and see them in a list, then it’s ideal.

I’ve had to do this several times in the past, but each time I forget how I did it and end up searching through the PHP string functions list. So this is a note to myself: use wordwrap().

As you’ll probably have guessed, this function breaks text into chunks of a specific length without splitting individual words. The standard length for lines in an email appears to be 75 characters (the default for this function). For safety, I replace the default line ending of \n with \r\n — I haven’t researched this but I wouldn’t be surprised if some windows clients get confused otherwise.

So I posted a question to the PHP Internals mailing list, asking “where are the promised hooks for PHP upload progress monitoring?” and within a few hours I had a nice clear reply from none other than Rasmus Lerdorf himself:

They are C-level hooks.  The various storage mechanisms need to add support for them in order to expose them to userspace PHP.  I added support in pecl/apc, for example.

See:

 http://progphp.com/progress.php
 (pick some random file in the 200k size range)

Source at:  http://progphp.com/progress.phps

Eventually we will see more extensions that manage server-side storage with support for the hooks.

…meaning that while in theory the functionality is there, it’s not exposed to ‘normal’ people — yet. There’s a proprietary but promising extension here, which might eventually make it into the PHP core (maybe). Until then (or until another similar patch gains acceptance) we’ll have to wait.

Oh and as a side-note, someone also posted a link to this extension that uses the upload hooks to allow you to scan files for viruses, during upload. Nice.

Those considering upgrading should definitely read the upgrading guide before going ahead.

It seems that this time around, there are a few issues generating controversy on the php.internals mailing list (please note: this is still under discussion so might change before release)…

First up, some tightening of the rules for object-oriented code means that methods declared as both static and abstract will now cause an E_STRICT error. It seems like a minor point to me — what would a static abstract method do anyway? — but some seem to feel it could cause widespread backwards-compatibility problems.

Second there’s a change in the behaviour of the mktime() function: calling it with no parameters will throw an E_STRICT error. It’s has been noted that calling mktime() with no parameters (or all zeroes) is equivalent (if slower) to calling time(), so one wonders why anyone would bother.

Finally, and more seriously from my point of view, is a reference to the filtering (against malicious code injection) of the entries in the $_SERVER array. The dispute itself is a fairly minor one — it seems that in PHP5.2, the array will be filtered automatically only for servers running Apache 1.x. Others will be enabled in later releases. The reason I find this alarming is that it raised an issue of which I wasn’t fully aware — namely, that certain fields in the $_SERVER array cannot necessarily be trusted. I guess I had heard about this before but the potential severity hadn’t really dawned on me. If this issue concerns you, here are some blog entries that might shed some more light.

On a final note, one feature of PHP5.2 that I’m sure many people will latch onto is the new uploadprogress_get_info() function, which (as the name suggests) allows you to track the progress of uploaded files. So with a bit of Ajax-y magic you could create a real-time upload progress meter, which is great for large files. We currently use some homebrew C code to achieve the same thing, but it’ll be nice to be able to ditch that and use native PHP calls instead. You’ll find a little bit of info on the new functionality here. For more accurate info on this subject, check out this post.

The problem: using XSLT, I wanted to pass a node-tree as a parameter to a template and then loop over it using xsl:for-each. Now I can already sense XSLT purists’ hackles rising: yes I should probably have tried harder to come up with some way of achieving the same thing using template matching. But please take pity on my poor brain! It really hasn’t managed to absorb all the subtleties of XSLT yet (even after two years battling with it) and as hard as I tried, I just couldn’t achieve what I needed to in a pure functional way. I know, I know: I’m going to hell.

Anyway, first off I worked out that to pass a node-tree as a parameter you have to use xsl:copy-of rather than xsl:value-of (which just flattens the node-tree into a string). But then, just as I was celebrating getting over that particular hurdle, I found that trying to use a variable in a for-each statement like this (simplified for readability):

<xsl:template>
	<xsl:with-param name="data"/>
	<xsl:for-each select="$data/*">
		
	</xsl:for-each>
</xsl:template>

…gave an ‘Invalid Type’ error.

The key (at least as far as libxslt, the XSLT parser library used by PHP5, is concerned), is something called EXSLT. As the acronym suggests, EXSLT provides extensions to XSLT. One of these is a function called node-set(), which “returns a node-set from a result tree fragment”. Bingo!

To get EXSLT to work, first you need to add it to your stylesheet declaration:

xmlns:exslt="http://exslt.org/common"

Then just call the function (remembering to include the exslt: namespace):

<xsl:template>
	<xsl:with-param name="data"/>
	<xsl:for-each select="exslt:node-set($data)/*">
		
	</xsl:for-each>
</xsl:template>

NB: if you’re using PHP5, you’ll need to ensure that EXSLT is enabled on your PHP installation. To do this, you can check the result of the XSLTProcessor->hasExsltSupport() method.