New Ads - No Destination URL on form
Starminder - March 10, 2009 - 19:01
| Project: | Advertisement |
| Version: | 6.x-2.0-rc1 |
| Component: | ad module |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
Just getting installed, am trying to create new types of ads, however, I don't see any field to type in the advertisement destination URL. Appreciate any thoughts, thanks!

#1
What ad type module have you enabled? Have you reviewed the documentation in the documentation directory?
#2
In this case an image ad. I thought I followed the directions but I will try again.
#3
OK....I...
disabled everything
used uninstall
deleted ad folder
ran cron, goofed around, did other stuff
uploaded ad folder (beta 3)
ran database updates (there were none)
enabled all module components
ran database updates (there were none)
checked settings (looked OK, but all added all permissions just in case)
checked user permissions, all are enabled for admin
create content: image ad
There is still no field to set a destination URL
So, either another module is stomping all over it (possible), or all database updates don't get run, or....?
In any case, I am:
still stuck
am open to any and all suggestions
Thanks!
#4
I rolled back to 1.1 hoping, but no dice.
#5
Setting this back to beta3
#6
To answer the original question, I've tried creating html, text, and image ads. Yes, I read the documentation but there is no field to enter a target URL. I did some searching around and it appears this has happened before with this module.
#7
Seems like another case similar to http://drupal.org/node/381216
#8
I agree, my form looks the same as the .png provided.
#9
Disabling Delegator (part of Chaos Tools) makes the missing fields reappear. (Many thanks to Greggus!)
#10
Automatically closed -- issue fixed for 2 weeks with no activity.
#11
I am having this problem also and not using Delegator... so not sure what to blame it on.
There is a workaround: the Destination URL and Mouseover fields do not appear when I first create the image ad, but if go back and Edit, they are then available.
#12
#13
deleted... another issue
#14
Did you get the fixed version of the code, as fixed here:
#436234: CCK nodes do not save on initial creation when ad_channel or ad_weight_probability is enabled
If not, can you try disabling modules half at a time trying to track down which once is conflicting?
#15
Haven't got it yet. Will test soon. Tks.
#16
I have this same problem. The thing works except for the missing Destination field. I dont know whats causing this, but when I figure it out, I'll post it here. I had none of the modules that were listed here as causing the field to disappear. If someone can tell me which ad module actually modifies the form (I assume it'll be in hook_form_alter() somewhere) then I can fix this. I'll probably find it before anyone actually reads this, but just in case you have no life like me, WHERE IS IT! lol.
Well this cant be a good sign. I have the module enabled, I was able to upload an image, I then hunted down the destination form element and put this in the function:
/**
* Adapi helper function for displaying a node form.
*/
function ad_image_node_form(&$node) {
$form = array();
print_r($node);
exit;
This resulted in nothing. It didnt even hit the exit or the print_r at all. It even had the image upload field still available. I expected it to at least die when I edited an ad image node. But it did no such thing. Off to do more digging.....
/**
* Adapi implementation.
*/
function ad_image_adapi($op, &$node) {
$output = NULL;
print_r($op);
exit;
Results in nothing. It doesnt exit or anything. This isnt going so well :/ It seems like it's not even trying to load the API at all, yet somehow it allowed an image field to be added.
I have run out of time to track this down. It's clearly a problem with the AdAPI but I dont have time to fix it. I've written my own ad module instead, same functionality as this one basically but without the troubles and extra features I didnt need. If I have time maybe someday I'll look at this again. For now, this module is pretty much unusable as an ad module if you need clickable ad's. It works as an image rotator well though. :P
Oh yea, and the versions I was testing were both the release and dev 5.x versions. I tried both, got the same results with both on clean drupal installs.
#17
#18
Forgot to follow up. I'm not having this issue anymore myself. New release took care of it. ... I am using 6x however.
#19
Restoring to 6.x, where the original bug report was filed. Still need more information to track it down, restoring status. Dropping priority to normal as it only affects some people and I'm unable to duplicate.
#20
I have not tried this with 6.x by the way. It was only with 5.x. I dont know a lot about the module so I dont know how similar the 5 and 6 versions would be. I'm going to be looking into this bug again today as I have another client who asked about this module. If I make any progress I'll post it here also. I'll leave the version of the report 6.x, but anything I report will be for 5.x since that is what they have for a website right now.
#21
I think I've found the problem. It has to do with how hook_form was meant to be used. Since this module uses args in the URL to determine the type, "add/ad/something", hook_form() never gets run. Thus none of the field ever get injected into the form. The fix for this seems to be to do the following in the ad_form_alter() call in the ad.module file:
<?phpif ($form_id == 'ad_node_form')
{
unset($form['title']);
unset($form['body_filter'])
$form['advertisement_module'] = ad_form($form['#node']);
}
?>
For me, in drupal 5.x, this fixed the problem of fields not showing on the node form. I am still in the process of testing this, but preliminary results show that it appears to work. It created the ad, I was able to edit it, and it seemed to function. I only tested it with text ad though.
I am 90% sure this is the correct fix. I have no idea why hook_form is not being called other than the extra args in the url are messing it up. Another fix might be to use session vars as a workaround so that the url doesnt have to be modified if you want to keep using hook_form(). Otherwise, just use form_alter.
#22
No longer an issue