Should $Page->Image Depend On An Option?

[Yannick Albert]

The last days I had to work a lot with PageImage. And right from the start, $page->image makes my hair weird. The stone at which I began to stumble, was the configuration part in the backend (Admin > Setup > Fields > Edit Field: images -> [Details]). Here we've to setup the maximum files allowed to 1, otherwise $page->image is not available.

Is there a reason why image should not contain always the first image?

I hooked into Page and made a simple method which does exactly what I've explained above:

wire()->addHook('Page::image', null, 'hookPageFirstImage');
wire()->addHookProperty('Page::image', null, 'hookPageFirstImage');
function hookPageFirstImage (HookEvent $event) {
  $event->return = $event->object->images->eq($event->arguments[0]);
}

This simple hook makes it possible to do things like this (In a DIY-fashion) without repeating yourself:

// Take the first image
$page->image;

// ...or even as a method, to take the nth image
$page->image(2);

Any thoughts on this?

[adrian]

Hi Yannick,

I am sure others will chime in, but I don't see why this is easier than:

$page->image->first();
$page->image->last();
$page->image->eq(n);

Are you suggesting your approach over these options, or were you simply not aware of them?

EDIT: Sorry, I see that you have been around on the forums for more than six months, so I am sure you do know about first, last, eq, and you're even using eq in your method. Sorry about that 

[teppo]

$page->image (assuming it has the capacity of containing multiple images) returning only first image is a problem if you're going to iterate contained images. Sure, you can make $page->image return first image of many, but then you'd need another method, something like $page->image->getArray() in order to iterate over many items.

I don't think that one use case trumps another, especially since it would be a breaking change.

Judging from your sample code, I'm kind of wondering if you are aware that $page->image is just a call to custom field called 'image', not something that's really built-in to the core? If that's just a proof of concept, that's cool, but in real-world use cases you can't reliably assume field 'image' to always exist

Edit: forgot to mention that the ability for multi-file field to return single item has actually been added to dev branch. It's not quite what you described it (it won't work as a method) and the use case might be different from what you envisioned (though what do I know..) but you might want to check it out anyway: https://github.com/ryancramerdesign/ProcessWire/commit/83826e993ecd57af22373cc878abac8a51f11ffe.

Edit 2: re-reading your post, you seem to use 'image' and 'images' somewhat interchangeably, when, in fact, there's no connection at all between these. Changing max files allowed to '1' in field 'images', like you mentioned in your post, definitely won't enable $page->image.

Perhaps I'm misinterpreting this (or it's simply a typo), but if you're suggesting that $page->image should point to first item in $page->images, that's not feasible, as 'images' is also a custom field with no guarantee to be around everywhere (and any template might have dozens of other image fields too, which would then need similar logic).

Edited July 28, 2014 by teppo

[mr-fan]

For my start i was going hard on this topic, too -> because i renamed my "image" field in "Bilder" .....so $page->image; really didn't worked....

But i'm more and more familiar with the API - especially reading day by day here!

The great and at the same time "frightened" thing on PW is....there is so much function and logic within the API - so you don't have to code/work around like in other CMS or systems....so thanks to all that explains and teach all the nifty under the cowl....

Best Regards

[Nico Knoll]

At first it looked like a good idea to me but I think teppo is right. How would you output all of the images if this is enabled? Normally it goes like:

foreach ($page->images as $image) {
// output image
}

But now $page->images (or $page->image) would be a string or object and not a WireArray anymore.

[adrian]

teppo deserves an extra like for mentioning that new functionality in the dev version.

Here's a screenshot of how it looks: