Minor FieldtypePage update in 2.1

[ryan]

Just in case anyone is interested, I posted an update to the 2.1 source that can be handy when working in the API with Page fieldtypes. With Page references that hold a single page, you used to have to check if the field had a value before you accessed it (at least, if you wanted to avoid a PHP warning). For instance, this code would produce a warning if your $page->category didn't contain a value:

echo "<h2>Category: {$page->category->title}</h2>";

If you hadn't selected a value for $page->category, then the above snippet would result in a PHP warning (at least in debug mode). So to code it properly you would have wanted to do this:

if($page->category) echo "<h2>Category: {$page->category->title}</h2>";

In the latest update, you can now configure the Page fieldtype to define what it's non-selected value is. You have a choice of either boolean false (the existing behavior), or a blank Page (NullPage). The advantage of having your undefined Page reference resolve to a blank page is that you no longer have to check if the field has a value before you access it. So you can now do this...

echo "<h2>Category: {$page->category->title}</h2>";

...and it won't produce a warning when the $page->category value is not set. Of course, you'd still get blank output of "<h2>Category: </h2>", but I'm just using this as an example. If you use a lot of single-page references, you'll find this can simplify your code in some instances.

So as to be backwards compatible, this behavior is optional, and you can choose the behavior when you define your field (see screenshot below).

When using a Page fieldtype to hold multiple pages, there is no difference, as those always resolved to a PageArray regardless of how many pages it contained.