The render function of area handlers is passed the argument $empty which is TRUE if the view is empty and FALSE otherwise. However, this is only true for the header and footer area. For the empty area, this variable will always be set to FALSE (the default value).

  $empty = empty($vars['rows']);

  $vars['header'] = $view->display_handler->render_area('header', $empty);
  $vars['footer'] = $view->display_handler->render_area('footer', $empty);
  if ($empty) {
    $vars['empty'] = $view->display_handler->render_area('empty');
  }

This is confusing since the view really is empty and the variable should reflect that.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

damiankloip’s picture

Status: Active » Fixed

I don't think this is that confusing, and it is not causing any sort of bug I can see.

Jax’s picture

Status: Fixed » Needs review
FileSize
596 bytes

It actually is confusing since one would expect $empty to be TRUE when rendering the empty area but now it's FALSE. We had to go dig into views code to understand why it's FALSE when the view is empty which should at least be an indication that it can be better. Moreover it's just inconsistent.

I've added a patch which makes the calls consistent and which makes the behavior more predictable.

damiankloip’s picture

ok, I guess this makes sense and is more consistant, but the empty area is only ever going to be invoked when $empty is TRUE. So It doesn't really matter too much.

Jax’s picture

Again, it does matter since an area handler can be added to any area, not only the empty area. So if you want to develop an area handler that does one thing when the view is empty and another thing when there are results you cannot use the $empty variable for this since it doesn't work. You'd actually have to check in which area you are and according to that result either check $empty or not.

So if someone could please set this to RTBC that would be nice.

damiankloip’s picture

Status: Needs review » Reviewed & tested by the community
dawehner’s picture

Status: Reviewed & tested by the community » Fixed

This makes totally sense, let's get this in.

Committed to 6.x-3.x, 7.x-3.x and 8.x-3.x

kenneth.venken’s picture

Status: Fixed » Needs review
FileSize
491 bytes

#2 breaks the 'No results behaviour' for the Global text area.
We should force the 'Display even if view has no results' option to TRUE for these empty area handlers.
Attached is a patch that does just that.

Even after applying my patch, old sites that upgrade the views module will break their empty handlers since the value for 'Display even if views has no results' for these handlers will be set to FALSE.

dawehner’s picture

Priority: Minor » Major

This seems to be more then just "minor" from my perspective, i even consider to reroll the patch until it is solved without breaking something.

Would like to get some oppinions.

Jax’s picture

Status: Needs review » Needs work

The thing is that the area handler just hides the checkbox when it is added to the empty area and this used to work because of the side effect that $empty is FALSE for the empty handler.

The patch in #7 fixes that behavior but maybe an update hook should be added to correct the existing data so that people's empty handlers suddenly don't disappear after an upgrade.

PedroMiguel’s picture

I can confirm all my empty text disappear whit latest dev (2 Aug), have to redo the #2 patch to having texts back.

I try the #7 first, but that only apply to new views (or updated ones).

dawehner’s picture

Status: Needs work » Needs review
FileSize
1.15 KB

Here is a solution for this problem, please test it.
PS:
You can't simply use an update hook, because views aren't stored in the database if they are exported into code.

damiankloip’s picture

Status: Needs review » Reviewed & tested by the community

I have just tested this with and without the patch, and this fixes the empty text showing when there are no results.

dawehner’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for testing! Committed this fix to 7.x-3.x and 8.x-3.x

David4514’s picture

[Edit2: It appears that in some way my production system was refreshed prior to the August 7th commit a37b02 which is the patch in #11. Without that patch, the patch from #2 did in fact break the no results text as has been noted. Now that I have refreshed everything again and verified that the patch from #11 is also include, all works well. Sorry about that.]

[Edit: more detail. Commit d70d68 on July 27, 2012 indicates it is associated with this issue# 1677784. It is that comment in the commit that led me to this issue.

My actual problem is that the "no results" text is missing for an empty view with this commit applied. It is only happening on my PHP 5.2.17 level production site. The test site which is using PHP 5.3.6 does not show the problem. I'm guessing that it is the PHP difference. The sites are clones of each other.

The commit d70d68 on July 27, 2012 shows this diff:

--- a/theme/theme.inc
+++ b/theme/theme.inc
@@ -72,7 +72,7 @@ function template_preprocess_views_view(&$vars) {
$vars['header'] = $view->display_handler->render_area('header', $empty);
$vars['footer'] = $view->display_handler->render_area('footer', $empty);
if ($empty) {
- $vars['empty'] = $view->display_handler->render_area('empty');
+ $vars['empty'] = $view->display_handler->render_area('empty', $empty);
}

$vars['exposed'] = !empty($view->exposed_widgets) ? $view->exposed_widgets : '';

This does not seem to match the patches above, yet it is for sure the source of my problem on the the system with PHP 5.2.17. If I revert this commit (git revert d70d68) then the text again shows for "no results"

/edit]

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

pdrake’s picture

Version: 7.x-3.x-dev » 6.x-3.x-dev
Status: Closed (fixed) » Needs review
FileSize
1.07 KB

This same bug affects 6.x-3.x. Attached is a patch to resolve this.

WorldFallz’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Just got bit by this one-- in the current views dev, empty text doesn't show. Patch in #16 fixes it and is virtually identical to the one committed to d7 so should be good for 6.x-3.x as well.

tomsm’s picture

Please commit #16 to 6.x-3.x.
I had to use this patch to fix my site after upgrading to version 6.x-3.2.

margaux’s picture

+1 request to please commit the patch in #16. I also had to use it to fix my site after upgrading to Views 6.x-3.2. Note: I patched it manually because the line numbers didn't align with the D6 version.

DamienMcKenna’s picture

DamienMcKenna’s picture

FYI this does not affect 6.x-2.x.

DamienMcKenna’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
1.06 KB

Updated for a PHP 5.4 compatibility bug, see #2327005: E_STRICT compliance for more.

tim.plunkett’s picture

Status: Needs review » Reviewed & tested by the community
tim.plunkett’s picture

Status: Reviewed & tested by the community » Needs work

This is causing strange behavior for me, investigating.

tim.plunkett’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
2.58 KB
974 bytes

It's bad to reuse variable names while you're in a foreach loop. Especially if you do it by reference!

tim.plunkett’s picture

Ughhhh wrong issue.

mw4ll4c3’s picture

dawehner’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +DrupalBCDays

So its not actually RTBC

Chris Matthews’s picture

Status: Needs review » Closed (outdated)

The 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