Most times, hiding a View you've created in Drupal is a fairly easy task to accomplish.

In fact, most times this isn't even an issue, because Views does a fairly good job at hiding the markup if there isn't any data to display.

Generally, there are some common causes of a View still rendering, even if there is nothing to show:

1. You've assigned a Header or Footer to the View, which is currently set to display even if there aren't any results. (Make sure you've configured this right!)
2. Your per-field configuration means that Views doesn't hide the field even if there isn't any data in it. (To solve this, go through each field manually and check 'Hide if empty'. Be sure to also tick 'Hide rewriting if empty'.
3. You've got some dodgy custom markup going on in your theme's Views template files: check on this, to ensure you're not rendering excessive markup around the actual View container itself.
4. A big fat problem with Drupal.

Unfortunately, for me, I was tasked with devising a solution for a problem caused by reason #4.

Sometimes, it may be the case that you have everything configured appropriately, you're hiding empty fields, your View has specific "No Results Behavior" already set up, your Filter Criteria are properly configured — but the View is still rendering markup.

Hm.

Perhaps you aren't seeing any results from the View (which is a good sign you've configured things correctly), but the Views container or surrounding divs are still making an appearance in your markup. And, if you're anything like me (an avid themer who uses lots of custom styling), you're possibly finding that the rendering of the unnecessary Views markup is posing a challenge.

A lot of noise has been created around this issue, with many a Drupal developer enquiring on whichever forum they can find, in desperate pursuit of a solution.

Funnily enough for me, all the resolutions I found weren't of any help. I didn't ever get down to the bottom of this, but no matter what I did, the hacky get-around solutions that others were using just wasn't hiding my View.

Some such suggestions are:

• To add a Global: Null contextual filter to the View, and configure it appropriately so that it hides the View if no results are found.
• To add a new Filter Criterion for one of the fields you've added in the View, and to configure it so that a specific content item's field must have a value of some kind (for example, that the body field is not empty, or NULL)
• Or, to manually enable the Hide if empty and Hide rewriting if empty options for each and every field in the View.

I tried all of these solutions, time and time again, and in my madness, even began playing with the weights of Contextual Filters and chopping-and-changing the settings for my new Filter Criterion... and of course, everything else that there possibly is to try in the Views UI.

I didn't want to implement any programmatic solutions or add any additional modules to accomplish this.

In my particular situation, I was managing a View which was already using a Contextual Filter, so adding Global: Null just resulted in the View not being displayed ever, regardless of whether it was "empty" or not.

So, after scrolling through perhaps 200 individual forum threads online, from Drupal.org, Drupal Answers, and indeed many individual blogs, I concluded that my View was in fact doomed to hiding-if-no-result hell.

Or, so I thought.

I did come across a few (and I mean, literally a few) comments during my search which proposed the use of jQuery to simply check whether the View container div in question had any rows or field elements or classes, and to subsequently remove the div from the DOM if it was "empty".

Of course, this is a little "hacky", and for many reasons (which I shall not dive into today), a less than desirable solution. So naturally, I was keen to avoid it. I really wanted to find a good, functional solution.

But, as the night grew longer and my patience became thinner, I remembered that one of the important qualities of any good developer is to recognize when they're against the odds (so to speak), and decide that the return on investment for the project is simply not quite worth the number of hours (or days, or weeks or months), that they're spending trying to resolve a particularly pesky situation.

We all know this. Sometimes, it's just better to have a fresh pair of eyes take a look at what you've got, because for some reason, you're missing a trick staring you in the face.

I finally caved, and resigned to the fact that it was probably more cost-effective for me to unwillingly succumb to jQuery as a tool to modify the DOM, in the event that the View didn't contain any actual content.

And then...

Just as I'd started adding a couple extra lines to the site's global jQuery file, something hit me.

I figured, a better solution may be to keep this strictly programmatical. Ideally, I wanted to avoid jQuery and implement a solution in a Views template file.

Which is exactly what I did. And in the end, I'm happy enough for now. Perhaps one of my colleagues can take another look at it next month, during our monthly project check-in. But for now, all I did was wrap the views-view.tpl.php file in the following:

<?php if ($rows) { ?>
  //rest of the file goes here... or rather, simply enclose what you need to within this statement
<?php } ?>

OMG, the relief I felt when I was done.

All those hours, for two (short) lines of code. I wish there had been a better way to accomplish this. But in my specific scenario, since I hadn't yet found an effective solution through hours of research and troubleshooting (or reading through all those darn forum threads), this was the easy way out.

And boy, was it easy.

Hopefully one of my colleagues will get around to looking into this further in a little bit... and perhaps then I'll update this post with some new information. I'm hopeful that a fresh set of eyes (and a stronger cup of coffee) can help settle what exactly was causing the resistance in this case.

But until next time, I hope this post made your day working with Drupal just a little bit easier. (Even if your manager does raise an eyebrow at the solution you were forced to use...)