ad module generates block content even if no ads are to be displayed

Confirmed bug.

I have a similar issue. Just downloaded the HTML code for an Amazon.com affiliate ad. It is an iFrame. Width of the frame is less than my sidebar. Ad entered as HTML using "Full HTML" input mode. Set block to left sidebar. Displays top portion of block with block title, but no ad content (no iFrame) from Amazon. Non-iFrame HTML ads from remote source display without problem.

Do I need to set <iFrame> as an allowed tag somewhere?

Suggestions?

I strongly believe this is a different problem. This issue concerns output produced when no ad should be shown, *not* the absence of the ad where it should be.

Anyway, could you please check if you still have "Full HTML" specified as input format for that ad? If you don't, then there's another (fixed in dev, I believe) issue for that.

The latest DEV release doesn't fix the problem. Still an empty block shown when no ads are available for the group.

I was referring to #551598 Input format is changed to 0, which could be the problem mauryg has.

@tetramentis

Thank you. You hit it on the head. I do find that after setting the ad as 'Full HTML' and saving it, when I return to edit it, the input format is set back to 'Basic'. I am using Advertisement 6.x-2.1 (Aug 05, 2009). I will try the DEV version and see if it solves the problem.

UPDATE: Installed 6.x-2.x DEV. Problem solved.

ad_cache.inc:501-504 has this block of code, which at least contributes to the problem:

In my copy, I've replaced this code (and a bit of the following code) with a simple

I've also added if (!adserve_variable('error')) checks to all print statements in switch (adserve_variable('ad_display')).

Unfortunately, this only solves the problem for the "raw" display method (tested).

Patch attached.

Thanks for the patch, I appreciate your contributions! However, I'm not going to commit it as it doesn't fully fix the bug.

Here's a patch that I believe fixes the bug for all display types. It could use more testing to be sure it doesn't cause any problems I didn't think of. The solution this patch uses is CSS, hiding the block if there was an error.

Testing and feedback welcome!

I believe your patch doesn't fully fix the problem either, as output is still produced - just hidden by JS. What if someone has disabled JS for increased security? (I'm not talking about text browsers, as they wouldn't be visually affected anyway.)

However, I do not have enough knowledge of the Ad module to offer a better solution right now.

I suggest that both fixes are applied: my fix to the Raw display type (where it hides any output completely), and your fix to all other display types.

And leave the issue open, until (eventually) all the display types have proper fixes.

> I believe your patch doesn't fully fix the problem either, as output is still
> produced - just hidden by JS. What if someone has disabled JS for increased
> security? (I'm not talking about text browsers, as they wouldn't be visually affected anyway.)

There is no fix for that, really. The reason being, when using any display method except raw there is _always_ going to be block output. If using the Js or jQuery display methods, then the output is a little javascript. That script then loads the appropriate ad(s) -- if there are none, the only solution we have at this point is to hide the block with CSS.

Anyone that is disabling JS on their website will be seeing modified pages anyway, so they've already made this choice.

I agree though, for the raw method we can prevent the display of the block altogether, and thus I will do so.

Otherwise, I'm just looking for testers to confirm that my patch successfully hides the block when no ads are displayed in all browsers on all operating systems. As you have noted, it won't work on browsers that don't have JS enabled, but it should work on the rest.

> There is no fix for that, really. (...)

I did suspect that, as you state somewhere that thanks to JS and JQuery methods ads are't cached even if someone saves the HTML page locally (or if a proxy caches that page organization-wide).

I now believe that all display types (except for Raw) "by design" have some content to produce.

> I agree though, for the raw method we can prevent the display of the block altogether, and thus I will do so.

Thanks.

> Otherwise, I'm just looking for testers to confirm that my patch successfully hides the block (...)

I'll check FF 3.0.14/Linux, FF 3.5/Windows, Opera ?.?/Linux+Windows soon.

> I now believe that all display types (except for Raw) "by design" have some content to produce.

Though one could check if (current_page needs Ads) when the block is generated, and then decide whether to output JS/JQuery code.

I can only think of the performance and labour (code rewrite) drawbacks to this solution. Am I missing something else?

Subscribing to this because it is also critical for my site design that *no output* be generated in the block when there is no ad to be displayed. Seems like the module should be able to determine if no ad is being displayed and then prevent the output of the html and javascript.

In my case, I'm using Image Ads. I have different Ad Groups that are displayed on different pages. If a particular Ad Group doesn't contain any ads, then I don't want any HTML output for that block on that page.

Subscribing as well since having the same issues as above. Will try the patch out!

Edit: tried the patch but didn't get it to work, the output is parent.document.getElementById('block-ad-t25').style.display="none"; but my block is called block-ad-25 is that the problem?

Looks like this isn't working as intended, so I'm not going to merge the patch for the next release. If someone wants to build on what I've attached above and contribute back something that works better, that would be much appreciated.