I'm on version 4.1.7. I have added an 'images' field to one of my databases, which allows users to upload multiple images to a record. I have encountered a strange quirk when working with multiple upload fields that are empty. When pulling the data from the 'images' field using something like 

$record->customFieldDisplayByKey('images', 'raw');

, you get an array containing the URL objects of the images. So when pulling the data from a record that has an empty 'images' field, one would expect to get an empty array. This is, however, not the case. If I do a var_dump of an empty 'images' field, this is what I get:

array (size=1)
  0 => 
    object(IPS\Http\Url)[354]
      protected 'url' => string 'http://localhost/1/uploads/' (length=27)
      public 'data' => 
        array (size=3)
          'scheme' => string 'http' (length=4)
          'host' => string 'localhost' (length=9)
          'path' => string '/1/uploads/' (length=11)
      public 'queryString' => 
        array (size=0)
          empty
      public 'isInternal' => boolean true
      public 'isFriendly' => boolean true

This is a URL object leading to my uploads directory on the server. I don't understand why this object would be returned, or why it is useful in this context. It also makes it really difficult to check if there are any images in the field, since one would usually just check if the array is empty or not.

Should I report this as a bug, or is there some logic behind this I'm missing?

For anyone else wondering about this, the fix to get around this is the following:

{{$images = $record->customFieldDisplayByKey('images', 'raw');}}
{{if isset( $images[0] ) && "".$images[0] === "".\IPS\File::get( 'cms_Records', "" )->url }}
	{{unset($images[0]);}}
{{endif}}

 

I usually just add {{if $formValue}} … {{endif}} to “Display Custom Format” and/or “Listing Custom Format” in the field settings. That checks correctly and easily whether there are entries. 

@opentype I'm packaging this functionality as part of an application, so to expect users to make this specific change to their field is far from ideal. I'm thinking it would be better if this were addressed by IPS, since it does not seem like intended behavior. I will post a bug report. Thanks for the info, though.

Bug report: