Hide if empty in Views3 doesn't match the Views3 row plugin

I believe this issue is related: #773238: Reduce white space and line breaks in HTML output?. Essentially, the field output was comprised of new lines and therefore not empty. I suspect that if you did a

empty(trim($field_output));

it would make the hide if empty work again.

Doing that makes it work with user profile pictures who return something different when the row is empty. Which is why Earl did it that way to begin with Im sure...

Ah, darn. The pagers won't go away, it still counts the empty rows.

this patch doesn't deal with empty rows. It deals with empty columns in the row. And if fixes a bug where Semantic Views doesn't work the same way as the normal Fields row plugin works.

What you are trying to achieve doesn't sound like Views can handle it. Its not a Row style plugin issue its a Views issue.

because of the linked issue above, Semantic Views adds new line to the output.

Perhaps its better to fix the new line, so prevent adding new line to the output from the style plugin->get_field() when the field is empty.

White space collapses in HTML

Sure, but

$string = "\n";
if (!empty($string)) {
  print 'not empty';
}
else {
  print 'pass everything is ok';
}

prints not empty. Which is a simplified version of

     $field_output = $view->style_plugin->get_field($view->row_index, $id);
     $empty = $field_output !== 0 && empty($field_output);

This means that hide when empty doesn't work when the $view->style_plugin->get_field() returns "\n"

I want to verify that this happens in Views without Semantic Views plugins enabled.

It doesn't thats how I decided to open an issue here.

Interestly, I see what you are getting at. views_plugin_style::get_fields(). Strange that this is returning non-empty stuff

$this->rendered_fields[$count][$id] = $this->view->field[$id]->theme($row);

The field handler in question is just views_handler_field.

 $data['location_user']['city'] = array(
    'title' => t('City'),
    'help' => t('The city this user is located within.'),
    'field' => array(
      'handler' => 'views_handler_field'
    ),
  );

I might spend some more time on it but honestly, this patch fixed it for us. Its no longer a bug. And Views standard style plugins worked just fine and behaved properly. It has to be a bug here, just not sure why.