Certain (admittedly odd) combinations of field handler options and CCK integer field values of 0 appear to result in those fields not being rendered. Since the code that appears to the issue is in Views, I'm putting this in the Views issue queue. Apologies if this is incorrect.
This particular integer field represents a numerical score, and can be 0 or any positive integer. Originally, it had had both the 'alter_text' and the 'hide_alter_empty' field handler options set. I then decided to do the altering in a template preprocess function to add a bit more logic to it, and unset the 'alter_text' option, but lazily left the 'hide_alter_empty' option set. In both cases, the 'hide_empty' and 'empty_zero' options were not set. After unsetting the 'alter_text' option, the resulting rendered View displayed nothing for this field if the value was 0. I disabled caching and preprocess functions for this View, with the same result for values of 0. While unsetting 'hide_alter_empty' as any reasonable person would do resolves the issue, I decided to dig a bit deeper.
No result is displayed for this field because the render_text method on views_handler_field is returning the empty string. On line 534 of handlers/views_handler_field.inc, a number of options and values are tested, and if the test is true, the the function returns true. If I'm reading this test correctly, it appears that the combination of a the field being 0 (i.e. $this->original_value), the variable $value being either the empty string or string '0', both the 'hide_empty' and 'empty_zero' options being unset, and the 'hide_alter_empty' option being set result in this test returning true.
Specifically, the test ($this->options['hide_alter_empty'] && empty($this->original_value)) is true because hide_alter_empty is set and $this->original_value is the string '0', and the test ($value !== 0 || $this->options['empty_zero']) is true because $value is either the empty string or the string '0', and it is strictly tested against integer 0. Casting $value to an integer in this expression, or loosening the test from '!==' to '!=' results in the field being displayed.
Since the value of 0 should not be interpreted as 'empty' for this field, I would expect that this test would not return true, even if the 'hide_empty' and/or 'hide_alter_empty' options are set, or if the 0 value is of type string or integer. If a specific value for a field should not be interpreted as 'empty', I would expect that the 'hide_empty' and 'hide_alter_empty' options would be irrelevant, even if they're left set by a lazy developer like myself. I suspect that the type issue is a slightly different issue, perhaps hidden by the fact that no reasonable person leaves 'hide_alter_empty' set when not altering the result.
I'm afraid I don't have any thoughts on how to deal with the variable type issues. I would, however, suggest that this test could be rewritten to be a bit more clear. Much like this bug report.
Thanks for all your work on Views!
-G
Comments
Comment #1
aerodub commentedI face this problem in views in combination with cck computed field module, 0 values are not displayed. Any progress on that or any advice how I can fix it?
Thank you
Armen
Comment #2
gdl commentedHi aerodub,
You might be running into one of the issues I describe above, but it might be an entirely different issue with Computed Field. I'd recommend that you take a look at the Computed Field issue queue and see if there's anything there. A very quick search of that queue for "zero empty" turned up a few hits, though no real solution. If you don't find anything, you should go ahead and file an issue there to determine if the issue is with Computed Field.
Best,
-G
Comment #4
dawehnerSeems to be a duplicate of #559102: Views thinks that a 0 value is empty even when the box 'Count the number 0 as empty' is unchecked...