Unable to see banners when block cache is enabled
tcornish - December 26, 2008 - 02:12
| Project: | Google Ad Manager |
| Version: | 6.x-1.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
I followed four steps to set up Ad manager with Drupal 6.8 but am unable to see banners even though I have the block set to show on page.
Any help greatly appreciated.

#1
same here... any help???
#2
I'm also having this issue.
#3
Looks like I needed
if (module_exists('google_admanager')) {$variables['scripts'] .= google_admanager_add_js();
}
instead of
if (module_exists('google_admanager')) {$vars['scripts'] .= google_admanager_add_js();
}
in my template.php file to rid myself of the JS error and get everything on the page. I'm still not seeing the ads though.
#4
I'm seeing our Google Ads only when I'm signed in. I sign out and they disappear. I know I have the right permissions set for that Block. Any ideas?
#5
UPDATE:
This seems to be impacted directly by changes in the 'Performance' section in 'Site Configuration.' As soon as 'Bandwidth optimizations' (both 'Optimize CSS files' and 'Optimize JavaScript files') and 'Block cache' are enabled, the issue described below seems to occur. I hope this helps...
*** original comment ***
Firstly, thank you for this module.
I am however, also having the issue that as logged in user, I am able to see the ads. As anonymous user though, the ads are not displayed. A quick look at the source code indicates that the blocks themselves (with the Javascript function GA_googleFillSlot() are printed, but the head Javascripts are missing.
Thanks again!
#6
I'm the maintainer of the module but I'm not using the module on a D6 installation. Does anyone have a patch?
#7
I just tried to install this module but had issues with the ads not showing.
In line with the changes suggested by mmondok above I adjusted the code that I added to template.php.
Currently ads are showing to both registered and unregistered users.
I will now go and test with caching on.
/* google ad manager toevoegen */
function phptemplate_preprocess_page(&$variables) {
// Insert Google Ad Manager scripts into header
if (module_exists('google_admanager')) {
$variables['scripts'] .= google_admanager_add_js();
}
}
function _phptemplate_variables($hook, $variables) {
if ($hook == 'page') {
if (module_exists('google_admanager')) {
$variables['scripts'] .= google_admanager_add_js();
}
return $variables;
}
return array();
}
/*done*/
#8
I just disabled 'block cache' and the ads are now appearing for all users, signed in or not. But looks like Drupal recommends that 'block cache' be enabled. Any ideas here?
#9
It is indeed the block cache function. I think the problem is as follows.
Ad manager only shows the ad manager code in the HEAD section if there is a block on that page containing ad manager code. If you would remove all blocks from a page using the visibility settings, the code in the HEAD section will not show. If you have multiple ad manager blocks but only show one on specific page, you will note that the admanager code in the HEAD section only contains the part related to the block showing on that specific page.
This mechanism gets confused if you use block caching. For some reason the ad manager module seems to think that no blocks are shown if block cache is enabled and therefore it does not show the code in the HEAD section. Subsequently you will not see any banners.
There are two solutions to this problem
1) Do not enable block cache.
If you do not have a busy site this is perfectly fine. Block cache helps you improve performance if your number of visitors is rising. For smaller sites the benefit of block cache is minimal.
2) hardcode the code in your head section
If you have ad manager generate your HTML, copy paste the HEAD section code into your template page and you are fine. You can enable caching and everything works fine.
My site just started so I just disabled block cache. However, I would like to use block caching in the future so I hope the issue above will be repaired. If not the module is less attractive. If I hardcode the ad manager code in my template files it is a small step to also make custom blocks to include my ad manager code and delete the ad manager module entirely.
#10
why are we using the theme layer at all? why not use:
<?phpdrupal_add_js( google_admanager_add_js(), 'inline', 'header');
?>
and have the js added directly?
#11
@frankcarey
Feel free to create a patch and if someone tested it, I'll commit to the D6 branch.
#12
I'll try to work on this when i can.
some notes:
What additional options can we provide in the JS?
https://www.google.com/admanager/help/en_US/tips/tagging.html
Drupal block api - how to get drupal_add_js to only be called once... when one or more ad blocks are being show on this page?
http://api.drupal.org/api/function/hook_block/6
#13
frankcarey - have you been able to make progress on this? - It appears to me that when block and page caching are enabled the Javascript code needed isn't included in the header.
Thanks so much!
#14
I am currently using the preprocess hook and it works well, without modifications to the template. However, I am using a custom caching module, I had some issues in this area too.
I like the comment in 12, tagging is definetly an important function, ideally I would like to see a custom hook to add tags. We could then write separate connectors to taxonomy and other modules.
#15
i haven't really gotten to it yet, sorry.
#16
this patch should stop ad blocks from being cached. please test and see if that solves part of the issue?
#17
Awesome frankcarey - thank you for working on this. I will patch and test. - Another thing I noticed that when I have these settings in place:
Caching mode: Normal
Page compression: Enabled
Block cache: Enabled
The necessary Javascript code is not added to the header portion of the HTML output for anonymous users. I am thinking that this may be due to the module's use of the theme layer to add the Javascript. But what would be the best alternative to this? Ideally, I won't need to hardcode this into the theme...
Thank you for your thoughts!
#18
i started working on the ability to not have to use theme layer... trick is to add js to head based on previous calls google_admanager_add_js() that for now happens in the block render step. I tried to use hook_init(), but this happens to early. The other option is hook_exit(), but i didn't get a chance to test that yet, and hook_exit code isn't able to be cached.
The alternative would be to load ALL js for all block on every page, then only the ads for the block that are actually shown on that page would show up. (this is what i did by just adding googles head js right into my page template.) There has got to be a better way... any thoughts?
If this patch works, then the issue here was that the blocks were being cached, and thus not calling google_admanager_add_js() for each block, when in turn generates the final js output.
#19
Any updates to this issue?
I have an install with the standard Garland theme and have installed the module according to instructions. It works on certain pages when logged in, but when logged out with caching settings all turned on, the Google JS code is not included in the header of the page.
So far I have tried on my own to modify the inclusion settings without success. I followed the chnage to
Any advice? It seems to work on the home page after I log out, but any other page is missing the Google JS headers.
#20
seangw, you have to make sure that the BLOCK_NO_CACHE setting is also applied to existing blocks, in case you just applied the patch.
#21
Right. So there are two parts to this.
First, an explanation of why this happens. Here's a lightly annotated version of the relevant snippet from block_list():
<?phpif (!count(module_implements('node_grants')) && $_SERVER['REQUEST_METHOD'] == 'GET' && ($cid = _block_get_cache_id($block)) && ($cache = cache_get($cid, 'cache_block'))) {
# Awesome! We're not using a node access module and this block is cacheable
# in some way. Go ahead and serve it from cache.
$array = $cache->data;
}
else {
# Either this block isn't cacheable, or node access modules are involved (it would
# be very bad for something intended for someone else to show up), so invoke
# hook_block op 'view'.
$array = module_invoke($block->module, 'block', 'view', $block->delta);
if (isset($cid)) {
cache_set($cid, $array, 'cache_block', CACHE_TEMPORARY);
}
}
?>
Therefore, since hook_block op view is never called in the event of block caching, theme_google_admanager_block() is never called to register any blocks on this page request, and google_admanager_add_js() blithely goes on its merry way thinking there's nothing to do here.
Frank's patch at #16 is the correct fix. This marks any Google Ad Manager blocks as non-cacheable, so that google_admanager_add_js() will get called reliably.
However! Because this property was not there when the module was first installed, all of the blocks got added to the database with the default cache method, which is BLOCK_CACHE_PER_ROLE (1).
Therefore, what we need is both Frank's patch and an upgrade path for existing sites. I'll roll a patch shortly.
#22
Here we go.
Note that you can also run the query manually, but if you do so, you'll need to clear the cache. update.php already does this automatically.
#23
Also, updating title to be more specific.
#24
nice!, thanks webchick, both for the clarification and the patch. Will patch and test.
#25
Just dropping in to see if anyone has tried the patch(es) yet. I'll try to test it in the next few days and report back.
Thanks for all the hard work on this, frankcarey and webchick!
#26
I now have ads displaying on my install... but, in addition to the above patch, I also added the second bit of code for install from Installation Instructions, which I hadn't done.
Some of my (non-promo) ad blocks aren't showing, but I'm guessing that's an issue with there not being any ads slotted in the specific, named blocks that I've assigned. (I don't manage the ads for the site; I only develop.)
So, my best guess is that the patch worked, or at least didn't make anything fail.
Thanks frankcarey and webchick!
#27
works as advertised. RTBC
#28
Committed. 6.x-1.1 will be made available. http://drupal.org/cvs?commit=279996
#29
I was only able to get my ads displaying correctly again by disabling block caching. I'd love to test this change. Are you ready to release 6.x-1.1? If not, could you please release a 6.x-1.1-beta?
Also, please note that your "View All Releases" includes an out-of-date "6.x-1.x-dev". Is it possible to have that dev release actually contain a nightly snapshot from CVS, as it claims to be now?
Thanks for the great module, which is incredibly helpful to me.
#30
I just exposed the 6.x-1.x-dev release to project page. I hope it will be automatically repackaged with the latest DRUPAL6 branch. I'm not sure whether I can trigger it.
Regarding releasing 6.x-1.1, I'm waiting for a review on another bug at http://drupal.org/node/530300#comment-2191688
#31
The block caching setting added to the Google Ad Manager blocks was added to the hook_block view $op and not the list $op which is where it belongs. Attached patch adds BLOCK_NO_CACHE to the right place.
#32
It turns out that Drupal 6 doesn't refresh the cache column in the {blocks} table once a block has already been added even if you change the block's cache setting in module code. See #235673: Changes to block caching mode not caught for details on this problem.
Since the previous patch moves the BLOCK_NO_CACHE setting to the right place, blocks added after this module's update 6100 was run but before the above patch is applied will not have the right cache setting and due to the Drupal core issue mentioned above simply applying the patch in #31 won't fix that.
So added to the patch to add another module update to essentially just rerun update 6100 to force the blocks to all be set as BLOCK_NO_CACHE.
After applying #31, any new blocks created with this module by adding new Google Ad Manager slots should get the proper cache settings.
#33
Applied to the 6-1 branch. Needs one more tester to closed this issue as fixed.