ad_html editing results in redirection

What are you clicking to try and edit the ad? You should edit it like any other node, by clicking the "edit" tab next to "view".

No further updates, I'll assume you figured this out.

Hi Jeremy,

first of all, thank you for your valuable module and your contributions and support.

I would like to reopen this issue, because I ran into the same problem.
The setup is Drupal 5.15 and Ad 5.x-1.7 on a LAMP server with Suhosin patch. When I try to edit an Ad node, using the edit link on the node view page, I get redirected to a display of the ad on a white page. On this page the ad is shown twice and the page doesn't finish loading. For a very short time I can see the edit page, but the page load gets interrupted, the javascript of the ad node content gets executed and redirects. This only happens with html ads and it only happens, when the advertising html code contains javascript. I only tested this with Firefox 3. The problem is the same with version 5.x-1.6 of the Ad module. I made a new input format without restrictions and without using the html filter for those html ads. Also those ads are displayed correctly on the site and also the view statistics are recorded without problems.

My dirty fix for now is to edit the html code of the ads directly in the database. But it would be nice to have a solution for this in Drupal.

I would be happy to help solving this issue. Please, let me know if you need more details about it or if I can do some testing.

Thank you very much again for your work and support.

Best Regards

HannesK

Can you provide some sample JavaScript that is triggering this redirect?

Hi Jeremy,

thank you very much for your reply.

Here's some code that is triggering this redirect, taken from a German banner exchange network. "ANFANG" means start and "ENDE" end.

<!-- AdSee.de Bannercode ANFANG -->
<center>
<script language="JavaScript"> 
document.write('<s'+'cript language="JavaScript" src="http://www.adsee.de/work.php?n=20&size=1&j=1&c=10-7-3-2-4-12-9&code='+new Date().getTime()+'"></s'+'cript>'); 
</script> 
<NOSCRIPT>
<IFRAME SRC="http://www.adsee.de/work.php?n=20&size=1&c=10-7-3-2-4-12-9" width=468 height=60 marginwidth=0 marginheight=0 hspace=0 vspace=0 frameborder=0 scrolling="no"></IFRAME>
</NOSCRIPT>
</center>
<!-- AdSee.de Bannercode ENDE-->

This also happens with google adsense codes, which also use javascript, for example.
Other code's I use are using iframes and no direct javascript for example and don't have this redirect.

Thank you for your help and support.

Best Regards

HannesK

I have the same problem

subscribing...I got the same problem too

Hi,
Does anyone solved the problem.
I have the same issue for Google Adsense code, the ad is displaying well but when trying to edit the ad even by clicking the "edit" next to the view button, I still get the same white page, and nothing displayed on that page.
Any ideas ?

Thanks,

Hi everybody,

I've looked at this problem a little further and found out the following:

When one disables the inclusion of "/misc/jquery.js" in the header of the edit page, the problematic redirect doesn't happen. The tested version of jquery.js is 1.2.6 from the jquery update module in a drupal 5 environment. I'm Sorry, but I don't know anything about this javascript code, so I don't know, why this is happening.

Because I want to continue using jquery_update, I tried another solution: Disabling the ad display on the edit form, (displayed in the HTML part just above the Ad HTML edit textarea) also makes the redirect not happening and one can stay on the edit page.
The downside of this is not having the actual ad display on the edit page, but one can still see it on the node view page of the ad.

This is the code change to apply this for the drupal 5 version of ad module:
In file ad_html.module from directory /sites/all/modules/ad/html change this (around line 81)

  $form['ad_html']['display'] = array(
    '#type' => 'markup',
    '#value' => ad_html_display_ad($node),
  );

to this

//  $form['ad_html']['display'] = array(
//    '#type' => 'markup',
//    '#value' => ad_html_display_ad($node),
//  );

This simply disables the ad display on the node edit page.
I haven't tried, but a solution for drupal 6 version of this could be similiar.

I know, this is not a nice solution, but maybe it can serve temporary. Again this redirect only happens with html ads that contain javascript, so maybe someone with knowledge about javascript can check out the possible jquery relation to this.

Hope this helps someone.
Again, thanks a lot for this wonderful module.

Best Regards

hannesk

Thank you for your suggestion, hannesk, but your solution ended up not working for me. Maybe this is because I am running Drupal 6.12, and not 5x.

Has anyone managed to figure this out on Drupal 6x?

Hi Akela,

I'm Sorry, but currently I have no possibility to test out the drupal 6 version.
But maybe a solution could be something like this for version ad-6.x-2.0.
in file /sites/all/modules/ad/html/ad_html.module change this (around line 129)
from:

  $form['ad_html']['display'] = array(
    '#type' => 'markup',
    '#value' => ad_html_display_ad($node),
  );

to:

  $form['ad_html']['display'] = array(
    '#type' => 'markup',
    '#value' => 'removed ad display',
  );

This is just an untested guess by me, but maybe it can help.

Best Regards

hannesk

I have been dealing with this same issue in Drupal 5, and I'm running jQuery Update with jQuery 1.2.6. I noticed it was a problem after I modified common.inc with the patch suggested by Wim Leers to improve Drupal performance.

Since I was already modifying core to apply Wim's patch, I just added an extra conditional statement to fix the redirection problem:

<?php
function drupal_add_js($data = NULL, $type = 'module', $scope = 'footer', $defer = FALSE, $cache = TRUE) {
  if (!is_null($data)) {
     if($_GET['destination'] != 'admin/content/ad'){ _drupal_add_js('misc/jquery.js', 'core', 'footer', FALSE, $cache); }
     _drupal_add_js('misc/drupal.js', 'core', 'footer', FALSE, $cache);
  }
  return _drupal_add_js($data, $type, $scope, $defer, $cache);
}
?>

The code skips the loading of jquery.js if the query string has a name/value pair of "destination" and "admin/content/ad". Not the cleanest solution, but this seemed to work as an interim solution.

I also subscribe cause facing the same issue - it just appears with the ad (html) node not with any other node nor with a block.

I found out that the same issue appears when a user comments on a node on which a block is shown with the ad. I solved this problem by adding "comment/reply/*" to the list of sites where the block should not be shown

Related:
#433404: Adsense problem

quick workaround (not solving the cause) - disable javascript in your browser while editing this ad

This is also happening to me, but not when I am editing.

When I configure the ads to display using JavaScript, it all works as expected. However, the longer page load times are undesirable. I tried the IFrame display mode, but it really doesn't work for my site at all. When I switch to JQuery (which would be ideal), everything works just fine in Internet Explorer (7 or 8, haven't tested older versions). However, in Firefox (3.5, haven't tested other versions), when an affilliate ad is selected for display on a page, the redirection happens. I haven't tried editing the problem ads using Firefox (and don't have access to it on the computer I'm using at this moment), but would expect to see the same problem unless some of the above patches are in the current version of the module.

The ad type I'm using is HTML using the following code (one example):

<div align="center"><script src="http://www.anrdoezrs.net/lo97qtpegilsphiv378A747B?target=_blank&amp;mouseover=Y" type="text/javascript" language="javascript"></script></div>

I have other HTML ads that are working just fine such as (one example, which includes its own iframe):

<div align="center"><iframe topmargin="0" leftmargin="0" height="150" scrolling="no" width="180" frameborder="0" src="http://view.atdmt.com/TLC/iview/lflcklfl0030000016tlc/direct/01?promo_code=ampersat&amp;click=" marginheight="0" marginwidth="0"></iframe></div>

Some additional details that may aid in troubleshooting:
* Drupal 6.14
* Advertisement 6.x-2.1

When I get a chance, I'm going to do some more extensive troubleshooting. I suspect that the following block from ad.module is the best place to start investigating. I may easily be wrong, but I suspect either that the value of $display is not what it should be here or that jQuery has a bug in either its selector or load function.

  if ($method == 'jquery') {
    return "\n<div class=\"advertisement group-$group\" id=\"group-id-$id\">\n <script type=\"text/javascript\">\n//<![CDATA[\n  $(document).ready(function(){ jQuery(\"div#group-id-$id\").load(\"$display\"); });\n //]]>\n </script>\n</div>\n";
  }

I was able to do some testing and came up with some simple test cases that show the problem in action.

Case 1: Default Case

This is a version of the page where I experience the problem with everything stripped out except for the code needed to make the problem appear.

<html>
<head>
<script type="text/javascript" src="/misc/jquery.js"></script>
</head>
<body>
<h1>test</h1>
<div class="advertisement group-tids-2" id="group-id-1">
 <script type="text/javascript">
  $(document).ready(function(){ jQuery("div#group-id-1").load("https://ampersat.net/sites/all/modules/ad/serve.php?m=jquery&q=1&c=file&f=3&p=sites%2Fdefault%2Ffiles&t=2&u=node"); });
 </script>
</div>
</body>

Note that for this and all other cases, changing the jquery line to use the latest version (as follows) did not eliminate the problem.

<script type="text/javascript" src="http://code.jquery.com/jquery-latest.js"></script>

Case 2: Ad inserted into the jQuery

I bypassed the ad/serve.php and load code by placing the HTML ad directly into the test page as part of the jQuery ready function. This still exhibits the same issues.

Note that I tried the html, after, and replaceWith functions and each exhibited the same problem.

<html>
<head>
<script type="text/javascript" src="/misc/jquery.js"></script>
</head>
<body>
<h1>test</h1>
<div class="advertisement group-tids-2" id="group-id-1">
 <script type="text/javascript">
//<![CDATA[
  $(document).ready(function(){ jQuery("div#group-id-1").html('<div align="center"><script src="http://www.anrdoezrs.net/lo97qtpegilsphiv378A747B?target=_blank&amp;mouseover=Y" type="text/javascript" language="javascript"></' + 'script></div>'); });
 //]]>
 </script>
</div>
</body>
</html>

Case 3: Ad inserted directly into the HTML

This one works correctly, without issues.

<html>
<head>
</head>
<body>
<h1>test</h1>
<div class="advertisement group-tids-2" id="group-id-1">
  <div align="center"><script src="http://www.anrdoezrs.net/lo97qtpegilsphiv378A747B?target=_blank&amp;mouseover=Y" type="text/javascript" language="javascript"></script></div>
</div>
</body>
</html>

My Conclusion

It appears that the ad code is not at fault here, since I was able to demonstrate the problem without any ad code being invoked. This leaves Firefox and jQuery as possible culprits. I'm going to try to report this as a jQuery bug and see where that gets us. It may be that Firefox is ultimately to blame, but even if that is the case, I think that jQuery should be coded to work around bugs, if possible.

What does everyone else think?

The ticket has been opened with jQuery.

http://dev.jquery.com/ticket/5366

Apparently there are multiple tickets open with jQuery already regarding problems of this sort (i.e., "the processing of scripts via ajax"). The recommendation is to use a different method to display ads. :-(

I experience this aswell, and my solution is to disable javascript while editing an ad. Not the most time efficient solution, but it works.

I also bump into the same problem ...

Same issue experienced with latest version

Something that's interesting is if you put

as the ad HTML you get a popup "hello" box ONCE on the view page and TWICE on the edit page. The javascript is actually being run twice on the editing page.

It loads into a hidden form field and somehow executes. This could be quite problematic.

I've also changed my display to an iframe, but that doesn't work. It doesn't wrap it in an iframe on the view or edit page (and I've flushed the caches.)

I recommend removing the ad preview on the edit page. Here's a patch to remove it:

--- ad_html.module
+++ ad_html.module
@@ -128,7 +128,7 @@
 
   $form['ad_html']['display'] = array(
     '#type' => 'markup',
-    '#value' => ad_html_display_ad($node),
+    '#value' => '',
   );
 
   if (isset($node->nid) && ad_permission($node->nid, 'manage ad html') || arg(1) == 'add' && user_access('create advertisements')) {

Just to summarize for those of you, like me, who aren't into reading, here's what I think is going on, and a temporary solution.

Certain HTML Ads (typically provided by 3rd party affiliates etc), which use JavaScript with document.write or document.writeln trigger an additional page load when using the Ad display type "jQuery". The result is a blank page displaying only the ad (at least in FF, not sure how it acts in other browsers, but I think IE also has this issue).

Changing my Ad Settings "display type" to JavaScript instead of jQuery appears to resolve the issue when displaying Ads throughout the site, but the issue will perpetuate on the "edit" tab for that particular HTML ad.

*If you change your display type and you're still having issues, make sure you've refreshed your page, cleared your drupal cache files etc.

I bet we can create an override to put in your template.php file to disable the ad preview on the edit form — otherwise you'll need to disable javascript while you create/update the HTML ads.

I have the same issue with 6.x-2.x-dev and Google AdSense.

Once you create them, if you try to edit them, you get the white screen with only the ad but can't edit them. To make any changes, you would have to delete and then recreate them.

I will try the suggestions in #26 by philpro above.

The preview display modification in #25 worked for me.

Drupal 6 is EOL and no longer supported. Closing this as outdated for that reason. Thanks for your contribution!