I am currently working on getting ads up and running on a site, but noticed that the current state of the 7.x-1.x-dev branch doesn't particularly print the correct markup for the dfp ads on the page (at least based on their documentation: https://support.google.com/dfp_sb/answer/4623874?hl=en).
On my end, I only got the ads to work on the test page, but on none of the front-facing themes themes, even on the ones supported by Drupal core. After doing a little bit of reading, I've kind of got the impression that due to some changes in browser security and potential API changes, the current code may not be up to standard and may not reliably serve ads properly.
Installed the module, but no ads are working on my site regardless of the parameters I put in
| Comment | File | Size | Author |
|---|---|---|---|
| #30 | interdiff-2629154-25-30.txt | 3.19 KB | scottalan |
| #30 | dfp-js-2869225-2-D7.patch | 20.25 KB | scottalan |
| #25 | interdiff-2629154-20-25.txt | 919 bytes | scottalan |
| #25 | update_to_dfp_ad_code-2629154-25.patch | 19.34 KB | scottalan |
| #23 | interdiff-2629154-20-23.txt | 537 bytes | scottalan |
Comments
Comment #2
bleen commentedCanyou give more specifics about what changes you think need to be made? There are ~1200 sites using this module and if ads weren't working because the module couldn't connect to DFP properly then a LOT of people would be complaining of problems
Comment #3
pcho commentedI've written a patch to address this. If the current module still works, you may not need to apply this. This is a blocker for me, so I might have to use this going forward.
You can view the diffs in a more prettier format here: https://github.com/pchop2/drupal_dfp/pull/1/files
Note: This was originally a fork, but I don't think the changes are drastic enough to warrant it be a refactor.
Another note: Patch also has changes to the way we import the gpt.js file from the old method, rewriting the spaces to the output $js variable, and additional documentation to make the code more readable.
Comment #4
pcho commentedI have one minor update to my patch, which fixes an issue with breakpoints in the js. I am deferring loading that stuff to later.
Comment #5
pcho commentedFor a more in depth explanation, when I installed the module originally, I noticed that a lot of the method calls were not placed in the proper scope. In addition, I could not find any evidence that the googletag object was actually read all the ads being compiled in the array prior to the push() method.
The third party vendor gave me code that slightly deviates from what the module sets up. Though I am not expecting this patch gets merged due to my edge case, I put it out there just in case someone else might have ran into the same problems I did due to code compliance.
This is what I got as sample code:
Comment #6
marcelovaniRe-rolling the patch
Comment #7
marcelovaniComment #8
marcelovaniTrying to make CI show the button that said something like 'Do not wait for the test to pass'
Comment #9
marcelovaniComment #10
marcelovaniComment #15
scottalan commentedI'm posting this patch here since this is where this refactor began.
I'm taking pieces of the original patch but also decided to move most of the inline JS to files.
This has been tested on a site that serves lots of ads. Let me know what you think.
Scott
Comment #16
scottalan commentedand the patch...forgot to attach it
Comment #17
scottalan commentedWill be pushing a new patch. I didn't realize that there were some dfp formatters that needed to be updated as well to handle the changes I've made.
e.g.,
and a few other things as well.
Comment #18
scottalan commentedHere's an updated patch. This does not contain any changes to tests but just wanted to get this up so others can test it.
This takes some of what was being done here https://github.com/pchop2/drupal_dfp.
For example taking VAST ads into consideration. This also adds the ability to save a GTM (Google Tag Manger) key that will automatically add GTM to the site.
Comment #19
scottalan commentedComment #20
scottalan commentedI'm not sure what's going on but it seems that
git applydoesn't like the fact that I've added a `js` directory and two files.It applies cleanly using:
curl https://www.drupal.org/files/issues/update_to_dfp_ad_code-2629154-20.patch | patch -p1
Comment #21
marcelovaniHi Scottalan
I am a bit confused with the patch. I am not saying it is wrong or anything, because I did not test it.
But it seems that what you are suggesting is to use Google Tag Manager with DFP.
Should not this be a separate issue?
Also, I was wondering if its possible to deliver DFP ads using https://www.drupal.org/project/google_tag
more info here https://georgegarside.com/blog/google/doubleclick-publishers-google-tag-...
Comment #22
marcelovaniComment #23
scottalan commentedMinor update. Needed to modify logic for targeting.
I added an interdiff to show the change.
Comment #24
scottalan commented@marcelovani
I'm sure it's possible to use https://www.drupal.org/project/google_tag but seemed like a lot of bloat when you can simply add a snippet of code, reference: https://developers.google.com/tag-manager/quickstart, and just add the container ID for your account. Just seemed like a nice, simple add-on.
As far as moving all the javascript to Drupal settings, it seemed like the logical thing to do. I'm not saying it's "wrong" but I prefer to have all JS in files and let Drupal settings do what it was meant to do. If you notice, I did not add the "User defined JS (1 & 2)". I'm also not a fan of allowing JS (nor PHP) in textfields in the UI. Moving all the JS to settings with weighting allows a developer to easily inject JS where (weighted) they want.
Let me give you a specific use case we ran into: The ad agency requested some special sizing parameters solely based on browser dimensions for banner ads. It was much easier to move the front-end logic being built in PHP functions to stand-alone files so I could manipulate what was needed. Apparently, another dev was trying to use the "User defined" JS fields to do this but it seemed messy to me. I was able to create a very simple JS file, weight it appropriately, and create a global variable that was accessible. Could this be done with the textfield...sure, but like I said, not a fan of "evalish" code in textfields.
I'm curious as to why this module chose to build the JS inline through string concatenation vs using Drupal settings to begin with, maybe just a preference? Either way, I had already setup most of the variable needed for Drupal settings in a custom implementation anyway so I thought I would just complete the task and post it back here as a patch.
I was thinking maybe this could just be the start of a 7.x-2.x branch or something. I realize without the eval textfields this would break backwards compatibility for those that are actually using them.
I'd be more than glad to make any changes you deem necessary to the patch I've provided if you want to go that direction and use it.
Thanks,
Scott
Comment #25
scottalan commentedMissed the same fix for 'breakpoints'. Adding a patch and another interdiff that shows both fixes.
Comment #26
marcelovaniHi Scottalan
Totally valid points.
I agree with creating a new 2.x branch too.
I was wondering if we should start a new ticket to propose this, what do you think?
Comment #27
scottalan commented@marcelovani,
Sounds like a plan. Do you want to create the new ticket with the information you would like to see in it and then we could just link to the latest patch here or I could just upload to the new ticket.
Comment #28
marcelovaniYou can create it and explain your proposed solution as you did on #24
Then add the link on this issue for reference.
Comment #29
scottalan commentedWill do.
I'm working through any potential bugs and then I'll create a new ticket.
Comment #30
scottalan commentedI'll go ahead and add the latest patch here with an interdiff but I created a new issue here: https://www.drupal.org/node/2869225 with the full patch.
Comment #36
vladimirausThank you for your contributions.
Drupal 7 is no longer supported.
Closing issue as outdated.