Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#22 | views-n1677784-22.patch | 1.06 KB | DamienMcKenna |
Comments
Comment #1
damiankloip CreditAttribution: damiankloip commentedI don't think this is that confusing, and it is not causing any sort of bug I can see.
Comment #2
Jax CreditAttribution: Jax commentedIt 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.
Comment #3
damiankloip CreditAttribution: damiankloip commentedok, 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.
Comment #4
Jax CreditAttribution: Jax commentedAgain, 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.
Comment #5
damiankloip CreditAttribution: damiankloip commentedComment #6
dawehnerThis makes totally sense, let's get this in.
Committed to 6.x-3.x, 7.x-3.x and 8.x-3.x
Comment #7
kenneth.venken CreditAttribution: kenneth.venken commented#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.
Comment #8
dawehnerThis 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.
Comment #9
Jax CreditAttribution: Jax commentedThe 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.
Comment #10
PedroMiguel CreditAttribution: PedroMiguel commentedI 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).
Comment #11
dawehnerHere 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.
Comment #12
damiankloip CreditAttribution: damiankloip commentedI have just tested this with and without the patch, and this fixes the empty text showing when there are no results.
Comment #13
dawehnerThanks for testing! Committed this fix to 7.x-3.x and 8.x-3.x
Comment #14
David4514 CreditAttribution: David4514 commented[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]
Comment #16
pdrake CreditAttribution: pdrake commentedThis same bug affects 6.x-3.x. Attached is a patch to resolve this.
Comment #17
WorldFallz CreditAttribution: WorldFallz commentedJust 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.
Comment #18
tomsm CreditAttribution: tomsm commentedPlease 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.
Comment #19
margaux CreditAttribution: margaux commented+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.
Comment #20
DamienMcKennaComment #21
DamienMcKennaFYI this does not affect 6.x-2.x.
Comment #22
DamienMcKennaUpdated for a PHP 5.4 compatibility bug, see #2327005: E_STRICT compliance for more.
Comment #23
tim.plunkettComment #24
tim.plunkettThis is causing strange behavior for me, investigating.
Comment #25
tim.plunkettIt's bad to reuse variable names while you're in a foreach loop. Especially if you do it by reference!
Comment #26
tim.plunkettUghhhh wrong issue.
Comment #27
mw4ll4c3 CreditAttribution: mw4ll4c3 commentedComment #28
dawehnerSo its not actually RTBC
Comment #29
Chris Matthews CreditAttribution: Chris Matthews as a volunteer 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