Views thinks that a 0 value is empty even when the box 'Count the number 0 as empty' is unchecked...

Have you checked the very latest -dev code? dww committed a patch (would have to check changelog to see which one) that I think fixed this last week.

And I believe I can reproduce this in the latest 6.x-2.x-dev as well. I've tried both with integer and text cck fields which have a value of 0-- they don't show in the view. Moreover, when you set some empty text, the empty text is listed in the field output rather than blank or zero. If you need more info, let me know.

I can verify that I can duplicate this as well. Drupal 6.13 and Views 6.x-2.6

Was hoping that 6.x-2.7 would fix this but alas it did not.

subscribing, Views 6.x-2.6 was OK but after upgrade 0 values just gone...

I'm displaying number of new comments. When there is no new comments nothing is displayed no matter what I set in views. I can set ,,empty text'', thread 0 as empty and so on, nothing changes.

Take a look at http://tarsjusz.pl/node/2789/talk . Column " / " is displaying [new_comments] / [comment_count] with ,,Rewrite the output of this field''. ,,Link this to new comments'' is also checked, however output is a link <=> new comments exist (in 2.6 it was always a link, no matter if there were new comments).

Ok, solution to my small trouble was:
from 2.6 to 2.7 line
if (!empty($values->{$this->field_alias}) || empty($this->options['no_empty'])) {
changed into:
if (!empty($values->{$this->field_alias})) {
(why?)
in views_handler_field_node_new_comments.inc file.

Any hints on how you found this entry that was causing the problem? My fields are in CCK fields and I am struggling to get this "fixed".

merlinofchaos refers to dww's fix in #546586: 0 not considered valid alternate or empty text. I'm marking this issue as duplicate.

See my comment #4 on that issue for an additional change that was necessary for me to see my zeros...

I have changed this issue to active as I believe that it is not a duplicate of #546586: 0 not considered valid alternate or empty text. merlinofchaos has referenced that issue as an issue about arguments, while this is an issue about a field (in this case an integer field) that does not display a valid "0" in a view. See #674046: CCK field containing 0 handled as empty for others experiencing the same issue (I will mark that issue as a duplicate of this issue as it is).

I had someone in doing some testing on the Views module, and he was unable to solve the problem as of yesterday. We did identify a few things.

#1 - Fields that are integers do not display a valid "0" in a view (duh.. this is the basis for this issue being open). The person I was working with has narrowed the reason down a bit I think and is working to fix this as I need this to work for our Drupal-based application. From what I gather, there is a known "problem" (more like this is the way PHP handles this type of data and people have to work with that when designing code) with PHP in that it has a "...partial distinction between false and zero. In PHP, false is boolean, and zero is numeric. But if you treat a zero value as a boolean expression, the zero gets converted to a boolean false." ref Tip. From what I interpreted with what we were looking at yesterday views is trying to compensate for that but it is (as of the current code) unsuccessful in doing this for an Integer field type. Unsure if it is related to what I put in #2 but I am curious.

#2 - Fields that are text do not display a valid "0" in a view unless the global settings for text processing for the CCK field is set to "Filtered Text". When it is set to filtered text the "0" displays properly.

Now there is no equivalent setting in an Integer CCK field to change from Plain Text to Filtered text. But Views is processing the integer field containing a "0" as a "False" or "NULL". The person I was working with was messing with the code in the views_handler_field.inc file and was able to have alternative text appear in place of the blanks. We are working to try and fix this as I do ned this fix to move forward...

Will provide feedback and suggestions if we can get them fixed. Also if anyone has any insight to guide us it would be appreciated. We will be working on this on Jan 7/2010 so we have 24 hours to get some ideas !

No fix for this yet.

from what I get of our testing, it appears that the values are coming to the views_handler_field.inc script already as a string and the code to check for zero vs null is bound to fail.

I would be interested to hear from the maintainers if this is in fact correct, and I wonder what the best way to fix it is...

I'm having this issue in the 6.x-2.8 version.

I tried changing the operator in views_handler_field.inc:

if ($this->last_render !== 0 || !empty($this->options['empty_zero'])) {

to:

if ($this->last_render !== 0 && !empty($this->options['empty_zero'])) {

Not being an expert on the topic of views field handlers, I'm not sure whether this approach is proper or not, but it seems to work in my _rudimentary_ testing. This is not a patch for the 3.x version.

@matt: your patch worked for me on Views 2.8. My CCK select list (field_fserver_versionpatch, which holds the version patch for a features project release in a features server) showed "0" when I was using Views 2.6, but upgrading to 2.8 meant it didn't display at all. Applying your patch allowed views to show the zero, which means my feature server is now working again (*whew*!).

I'm not sure if changing the || to && will break anything else in Views, though?

Setting status so it gets into the needs review queue.

Sorry if I'm not testing the latest .dev version, but I would like to report an issue with 6.x-2.8, which looks slightly different from the topic starter's issue. Just see it as an additional test case you need to take into account.

The situation:
- I have a list of news (nodes), using the field "Node: Comment count".
- As the "empty text" for this field, I defined "No Comments".
- I checked "Count the number 0 as empty."
- I have " Comments" as a suffix, and I want to output this field as a link.

Now, as long as I specify a non-empty suffix, or "rewrite the output of this field", or "output this field as a link", the "count 0 as empty" will not work. I imagine that it checks if the final string (such as "0 Comments") equals "0", which it never does, obviously.

I applied Matt's patch to views 6.x-2.x-dev. It solves the issue that I reported in http://drupal.org/node/674046. So I would like to have a solution like this implemented in a next version of views.

@donquixote, does applying the patch fix your issue?

Lot of confusion on this issue. Here is the simple breakdown of the problem and solution.

There is 0 as an integer and '0' as a text string.
The PHP boolean function empty() treats both integer 0 and string '0' as true (yes they are empty).

The original function is as so

    if (empty($this->last_render)) {
      if ($this->last_render !== 0 || !empty($this->options['empty_zero'])) {
        $this->last_render = $this->options['empty'];
      }

Which says
1. if value is empty move on
2. 0 and '0' qualify as empty
3. if the Views->Fields checkbox->"Count the number 0 as empty" is checked then proceed #6
4. OR
5. if the value is not equal AND identical to the Integer 0 then proceed #6
6. Return an empty value, ie. display nothiing

!== 0 is the key here. The "Count the number 0 as empty" checkbox is only intended to allow 0 as an integer through, not zero as a string. If the help text under the checkbox actually said "If the field contains the number zero as an integer but not a string, display the empty text instead. String 0's will always be empty" - then it would be clear to everyone why their 0's aren't appearing or in some cases appearing but others not.

The #12 patch is not a good idea in my evaluation as it changes the rules to say "hide the number 0 only if it is a string". Which means now you have the problem of checking "Count the number 0 as empty" but still seeing 0 when its an integer.

The big question here is "why was 0 as an integer originally allowed to go through but '0' as a string specifically not allowed to ever go through?

Instead of !== 0 which only allows one type of zero through, != 0 could instead have been used which says to allow either type of 0 through.

A simply resolution to the 0 display problem is to simply say
if ($this->last_render != 0 || !empty($this->options['empty_zero'])) {
However I am reluctant to submit a patch or advocate this change until there is a clearer explaination as to why the Not Identical operator was used originally instead of simply Not Equal. It seems there was likely a reason behind it but maybe only a reason of style.

I've applied your patch, and it works perfectly. Even the "Count the number 0 as empty" checkbox is work as intended.
Hopefully someone will clarify why it was a !==0, this and it will go into the release soon!

The reason !== is used because ('' != 0) evaluates to true.

Returning this to duplicate, because it is the same issue that was being discussed: http://drupal.org/node/546586#comment-2703080

I hesitate to respectfully disagree, but the patch that was posted in http://drupal.org/node/546586#comment-2703080 does not fix the issue that the original poster has started this thread about (and one that I continue to see).

I have the 6.x-2.x-dev installed.

Yes, the patch works to ensure that a non-integer CCK field that contains only a "0" displays only a "0" if the text processing is displayed to Filtered Text in the CCK node type (see my comment in #10 above). If it is set to plain text the "0" is seen as empty.

No, the patch does not work to ensure that a CCK field that is an integer type contains the integer "0" displays a "0". As I mentioned in #11, the way that views is handling the fields seems to indicate that the views_handler gets the fields as a string already, and PHP cannot evaluate zero vs null in a string.

Obviously views is handling integers different than text.

Hope this helps.

You can respectfully disagree. However, I tested 'text', 'integer' and 'float' fields with a 0, and the patch did work on all 3 for me, with an eye toward making sure that all 3 data types were respected, so I was paying attention to this.

Reading a second time, I have an addition to make. The 'filtered text' comment is a boondoggle:

If you set it to filtered text, a 0 is not actually a 0.

It's <p>0</p> and that simply cannot be seen as empty.

Well dammit it is not working on my system... May have to blow it up and start over !

I have two potential things to check:

1) Perhaps the patch did not apply correctly?
2) Perhaps there is a specific edge case I am missing? If you can show me how to replicate this with very specific instructions that may lead to something we all did not see.

Ok I will see what I can do.

(1) As far as I can see the patch that you committed is in the dev version, so it shoudl be fine. I did not patch views, I just downloaded the latest dev snapshot from Mar 11

I will try and get to (2) in a while when I can get some time - hopefully soon.

Thanks

Subscribe. (Getting this on 6.x-2.8.)

OK here is a shot at (2).

I have attached one of the views that is affected (AFAIK all views that I have that need an integer "0" are affected).

One of the integer fields is as follows:

field_name: field_ln_involved
type: number_integer
global_settings: a:6:{s:6:"prefix";s:0:"";s:6:"suffix";s:0:"";s:3:"min";s:0:"";s:3:"max";s:0:"";s:14:"allowed_values";s:0:"";s:18:"allowed_values_php";s:0:"";}
module: number
db_column: a:1:{s:5:"value";a:3:{s:4:"type";s:3:"int";s:8:"not null";b:0;s:8:"sortable";b:1;}}

In that field I have only integers - 0,1,2 etc.

In the above view I get the following output (only one line obviously, and truncated the colmns to make it readable; pipe used to show column breaks):

#|MRN|Edit|Path Report|Specimen / Verified Date|Path#|Sex|Histology|pT|Size|Tumour Dimensions|pN|N+| N(t)
2|12345678 |edit|…|Nov 17, 2009 - Nov 20, 2009|SP-XX-XX|Female|Infiltrating ductal|1b|0.9 cm|0.9 cm|0|<"0" missing here>|2

I am missing the integer "0" where noted. The "0" that is there is a CCK field type text with a set of allowed values. It can be made to not show if the text processing is set to plain text.

Does that help explaining things ?

Can we make the 0 as empty also recognize $0.00 fields? I use ubercart and would like to hide the List Price field if it's equal to $0.00. Thanks.

I think ubercart is going to have to handle that. Though. Price fields should probably be integers that are converted for display rather than actual strings. But I don't get to control the architecture.

Subscribe

The patch on comment #12 worked for me.

I'm using Drupal 6.15 and Views 2.8. One of my taxonomy fields had the 0 as an option and when I wanted views to show
the value as a link it showed 0 fine but as text it was considered empty, now its working fine.

Thanks guys.

Can I reopen this for 7.x? I, coincedentally, have a very similar use case to the original post. The scores of my matches are integers and in the case of a dual forfeit the league suggests this is recorded as a 0-0 draw. The option "Count the number 0 as empty" is unchecked. I'm using Views 7.x-3.x-dev. My view export is attached, and I'm specifically referring to the first "Page" display.

same here for D7.x

- Have a field to indicate breakfast price in a hotel.
- if the field is left empty I told Views to take over and put a 0 (zero) into the field ...

result : Views just leaves out the field completely...

Part of the problem certainly seems to be that the logic in views_handler_field_numeric->render($values) to check for whether the value is considered empty is wrong.
The current code includes a check for $this->options['hide_empty'] which doesn't belong there. (Dealing with 'hide_empty' is and should be handled by views_handler_field). The code toward the end of views_handler_field_numeric->render($values) :

 if ($this->options['hide_empty'] && empty($value) && ($value != 0 || $this->options['empty_zero'])) {
      return '';
    }

is wrong for the condition cited above in comment #15 ( [#559102#comment-2536442] ): ($value = 0, $this->options['empty_zero'] = true, $this->options['hide_empty'] = false)
This should only check to see if the value is considered empty, and if so, return an empty string so that view_field_handler can take it from there.
The logic at the end of views_handler_field_numeric->render($values) should instead be:

    if ( (!isset($value)) || 
         ( ($value == 0) && ($this->options['empty_zero']) ) ) {
            // we're considered empty
                return '';
    }

(Note that checking for !isset($value) is overkill since the preceding code in the function ensures that the value is set. Also, PHP considers empty(0) to be true, so we have to be careful not to use that.)

I haven't submitted it as a patch because I've only been testing for Views v. 6.x-2.12. and the conditions for views_handler_field_numeric. I can certainly see specifying this as a separate issue (and there seem to be variations/duplications of this issue in the queue); fixing this would then address at least some of the problem for this issue.
Having clearer programming documentation that specifies what the expected return value is and what the responsibilities are would help; seems that the logic for certain conditions and handling things is getting spread out into classes and functions where it doesn't belong. (SimpleTests would help clarify; I'm coming up a learning curve else would also help there.)

This seems to be somehow a duplicate of #1232920-1: Empty rounded numeric fields not hidden properly

Can you please verify it?

@dereine: not sure who you want to verify.... what? Can you be more specific, please? Do you want someone to verify that this is a duplicate of #1232920: Empty rounded numeric fields not hidden properly in version 7? version 6? both?
(I'm working on a version 6.x install, so can only verify things there.)

 Do you want someone to verify that this is a duplicate of #1232920: Empty rounded numeric fields not hidden properly in version 7? version 6? both?

Well in general ...

The problem is still here with 3.x in D6 D7

#1232920: Empty rounded numeric fields not hidden properly D7

#1163412: Count number 0 as empty / vote results D6

Some fix available?

Some problem should come from this code:

    if (empty($this->last_render)) {
      if (($this->last_render !== 0 && $this->last_render !== '0') || !empty($this->options['empty_zero'])) {
        $alter = $this->options['alter'];
        $alter['alter_text'] = 1;
        $alter['text'] = $this->options['empty'];
        $this->last_render = $this->render_text($alter);
      }
    }

    return $this->last_render;
  }

The bug is still present when using rounded numbers.

Empty text (Provide text to display if this field returns no results.) doesn't work as well when "Round" numbers option is check.

@dereine I'm not trying to be difficult; I just really don't know what you mean by

"Well, in general..."

'Well, in general...' what? I'd like to be helpful and share the load in getting this fixed, and I offered specific tasks that I could do. But I need a clear answer to my question so that I have direction and can do work that is helpful and worthwhile. Perhaps you're already working on fixing this for one version or another, or perhaps working on one version or another would be more helpful. Or perhaps this isn't what is needed right now.
(Sorry if this sounds a bit snippish or short. I don't really mean it to. I just want to be straightforward about this.)

Hey,

got same problem on d7 with 3.x. It's really easy to reproduce. Just make content type with text field or numeric field (checked both). put 0 inside that field and make any view to display it. You won't see 0 even with unchecked 'hide if 0' option (which is unchecked by default). Tracked down problem to same piece of code as in comment #36 thought it has changed abit.
it is method render_text of views_handler_field class views_handler_field.inc line 1012

  if ((($this->options['hide_empty'] && empty($value)) || ($this->options['hide_alter_empty'] && empty($this->original_value))) && ($value !== 0 || $this->options['empty_zero'])) {
      return '';
    }

i think its really major bug as you can't display any field that has value of 0 no matter if it is text field or numeric.

Some related issues: #1232920: Empty rounded numeric fields not hidden properly #1339044: Empty(0) numeric fields are hidden on table style.

I'm reposting the patch from #1339044: Empty(0) numeric fields are hidden on table style. and marking it as a duplicate.

I kind of prefer the practical approach, anyway committed the posted patch with much better include comments.

This is probably helpful for 6.x-3.x as well. The commit ID for the actual change is 1389e71

Patch applied as it is.

#47 solves the issue.
(3 years after submission...)

Can it be committed to the 6.2 branch?