possibility to restrict empty results

No, and I don't know how to detect whether a view is empty before displaying it. Feel free to submit patches if you work it out.

I know the issue is closed, but I'm responding anyway because I need this feature too and I can imagine other people as well. In EVA attached views that have no results turn up empty (i.e.: they don't return the view's title if the view has no results). EVA works differently (it's a views plugin in which you specify to what entities you want to attach it to) but perhaps the maintainer has an idea how to do this? I am nowhere competent enough to dig in myself.

Feel free to close the issue again if this isn't going anywhere.

I notice from the first sentence of the EVA module description:

it provides a Views display plugin

That's the game changer right there; writing your own Views display plugin. Then you have control of the View itself. But this module doesn't do that.

The other difference is that this module stores the field value as a reference to the view, regardless if it exists, works, shows anything, etc... the view isn't touched until the field formatter kicks in, at which point your field is already (being) rendered. So there's no turning back at this point from within this function.

EVA executes the view, and if it is not empty, it gets attached with hook_content_extra_fields() which can return nothing and gets ignored.

So the workflow happens in a different order and decisions are made at different points. The way view reference works is inherent to a typical Field API module.

Of course I'm still willing to accept patches if someone works out a way to do it without changing the design of the module. It might not really be worth it though. A better idea would be to create a better View to Entity relation module that can at the front end encompass both (and other) approaches.

Hi Daniel,

I looked into this because it was a major nuisance in a project, and I prepared a patch. Bear in mind, this is my first patch, and the fix I am making is probably not great. Basically, I am checking the preview of the view and if I don't find any "views-row" instances (the class for each row), the element is marked as empty.

Please see attached, and feel free to tell me if this is totally wrong. Don't hold back.

Interesting technique, I guess we can go with looking for views-row, however I don't think it is implemented in the spot it should be.

Actually, it's not a good technique. I'll post a better version tomorrow.

From my tests, this had to be in that function, because it has to unset the element. Otherwise, the field will get generated, and there will be an empty div with class=view and other view-specific classes. My particular scenario is of using the view in a tabbed group, and the tab display depends on whether the fields has an output or not. An empty div class="view" would give me an empty tab.

It's totally wrong :)

The first view I tested it on never actually contains the string "views-row" in the output. I assume that only exists in views that use a row style plugin of "row". There are any number of row style plugins.

I think I have another idea - the view object contains an array at $view->result, I'll try testing if that's empty.

That seems to work.
There is also $view->total_rows so we could try that if this doesn't work out.

I've also added a setting whether to skip it or not.
Thanks for having a go and spurring this on pmusaraj.

Hi Daniel,
You are most welcome. There is still a problem though.

The change you made still generates an empty field that gets outputted. The markup is something like this:

<div class="field field-name-field-edu-ref-act-enligne-hid field-type-viewreference field-label-hidden">
<div class="field-items">
<div class="field-item even"></div>
</div>
</div> 

When the field is in a fieldgroup, set to display as a tab for example, the tab still shows even though it has no content. And it shows because that field markup is generated. The implementation in my patch (disregard the silly check for the view class) does not generate any markup, and the tab doesn't show because it would have no fields where there are no rows. I'm pretty sure that in most cases, this is the behaviour we want. Especially if coupled with the checkbox in the settings you added, which is great.

So, sorry to be a pest, but I think this should be modified just slightly.

Thanks!

I know that but didn't think it would be a problem.
The issue I have with yours is that it requires loading and executing a view an extra time.
I will reconsider though.

Here is a patch where I've added extra code on top of what's already there to call the viewreference_get_view() in the formatter hook and a make a decision about skipping the empty element there, just as you had it.

But additionally it attaches any data returned to the $element so the data can be reused by that function the next time it is called, and won't have to execute the view again.

Haven't tested.

well i've committed it, let me know if there is a problem

I have updated to the new version of the module, and needed to mention that there is still an issue. If there is a view reference field in a tab (using field group) or a fieldset, and if the view has no results, the tab/fieldset will still show.

The following patch avoids this from happening, by removing the viewreference field when the results of the view = 0. I know this adds extra overhead, so you may not want to integrate this in the module. It may be useful for those who use fieldgroups.

(Marking issue as needs review, but feel free to close it, danielb.)

No the code right above that:

    $element[$delta]['#element']['view'] = viewreference_get_view($element[$delta]['#element']);
    if (!$element[$delta]['#element']['view']) {
      unset($element[$delta]);
    }

Will do exactly the same thing when viewreference_get_view() returns FALSE, which it does if you turn on the option "Do not output view if no rows are detected".

If that functions isn't returning false, then the problem should be addressed there I think.

Adding a 3rd execution of the view is not good!