Jump to content

Empty multiple upload fields are read as non-empty arrays


snugRugBug

Recommended Posts

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?

Link to comment
Share on other sites

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}}

 

Link to comment
Share on other sites

@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: 

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...