When "Hide rewriting if empty" is selected and "Count the number 0 as empty" is not selected, the number 0 is not displayed. Unchecking "Hide rewriting if empty" causes the rewritten field to be displayed.
This patch moves the rewriting after the empty check.
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | views-1433596-21.patch | 15.75 KB | tim.plunkett |
| #18 | views-1433596-18.patch | 15.75 KB | tim.plunkett |
| #17 | views-1433596-17-test-only.patch | 12.42 KB | tim.plunkett |
| #17 | views-1433596-17.patch | 15.75 KB | tim.plunkett |
| #13 | views-1433596-13-test-only.patch | 12.68 KB | tim.plunkett |
Comments
Comment #1
imclean commentedWrong status.
Possibly related: #1428256: No results behavior "Hide rewriting if empty " is not working
Comment #2
imclean commentedI've gone about this the wrong way. The problem seems to be the empty check is performed on the rewritten value ($value) on the second pass rather than the original value.
This means the following, after being rewritten, would evaluate to true:
Specifically, the following should be false in the case of zero:
&& (($value !== 0 && $value !== '0')Checking the original value instead gives the expected response:
&& (($this->original_value !== 0 && $this->original_value !== '0')Possibly also related: #1273486: “Empty Text” does not work when “Hide Rewriting if field is empty" option is selected.
Comment #3
imclean commented#2 won't work. $this->original_value isn't set if the field isn't being rewritten. Maybe the first approach was better.
Does the empty check really need to be done on the rewritten value? I guess potentially the original field could be "empty" while the rewritten field may or may not produce output using tokens + html, but "hide if empty" should take care of this.
I think "Hide if empty" should always hide the field, including any rewriting. What would be the purpose of rewriting the field before performing the empty check?
Comment #4
dawehnerIs this still required on the current version? There was some logic applied recently. Additional the patch does definitive not apply anymore.
Comment #5
dawehnerIs this still required on the current version? There was some logic applied recently. Additional the patch does definitive not apply anymore.
Comment #6
imclean commentedSame problem with the current version.
empty()always considers 0 to be empty.The following returns true when hide_alter_empty is set and the original_value is 0, regardless of empty_zero setting.
This patch adds some extra checks. I'm not sure if it's the most efficient method but it works for me.
Comment #7
imclean commentedGah, same mistake as before. If the value hasn't been rewritten, $this->original_value may not be set to check for 0 so an error is produced.
$value may be the rewritten value so that can't be checked either.
Comment #8
imclean commentedTry again.
Comment #9
tim.plunkettThe patch doesn't address all situations.
I checked both a non-empty field rewritten to 0, and an empty field rewritten to 10, with all possible combinations of the checkboxes.
This adds a helper function, because the !== 0/'0' pattern appears in 4 distinct places, one of them wrong.
Comment #10
tim.plunkettI strongly debated leaving this part out of the function and just calling empty() in the code, but I do believe this is cleaner.
Comment #11
dawehnerIt would be kind of cool to extend the already existing tests. This code has to many cases that you can be sure all the time.
Introducing a helper function definitive makes things a bit clearer.
Comment #12
tim.plunkettI'm working on the tests.
Comment #13
tim.plunkettAlright, I went a little overboard on the tests, but they needed to be cleaned up.
Should have about 2 fails on the test only patch, and all passes on the other.
Comment #14
tim.plunkettWell you'd have to run it locally to see that. Simpletest > Views Handler > Field.
Comment #15
tim.plunkettTriggering the testbot.
Comment #17
tim.plunkettReroll
Comment #18
tim.plunkettIn IRC @dereine suggested switching the default value for is_value_empty().
Comment #20
dawehnerJust a small issue: It could be that the rewritten value is used, as both are equal, what about creating another random name for the actual value?
Comment #21
tim.plunkettDuh, I switched which function calls used the third parameter, but not what they were passing. Those fails were a good thing :)
Also included the suggestion from #20.
Comment #22
dawehnerThe patch is fine and has a phenomenal test coverage. Let's get it in! Thanks for the work!
Comment #23
chris matthews commentedThe Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue