Closed (fixed)
Project:
Doubleclick for Publishers (DFP)
Version:
7.x-1.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
24 Jan 2017 at 15:57 UTC
Updated:
30 Mar 2017 at 18:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
dorficus commentedComment #3
dorficus commentedComment #5
dorficus commentedI'm curious if this might be an issue ofI was wrong. Nothing to see hereassertNoRawvsassertRaw. The test string looks like something we _wouldn't_ want to see on a click URL, but I could definitely be mistaken.Comment #6
dorficus commentedI think the error goes back to the domain. Since we can't be sure of what the testing domain is going to be, unless we can and I don't know it. Either way, I think it would be safer to remove the domain from the
assertRawcall and check to see if the module filtered out the bad protocol. This will result in not testing for absolute, but it will test for filtering.Comment #7
bleen commentedComment #8
dorficus commented@bleen can we pull in
$base_urlto test for absolute still?Comment #9
dorficus commentedComment #12
dorficus commentedTrying without encoded characters
Comment #13
dorficus commentedI forgot to call the global in the last patch. This should do the trick!
Comment #14
dorficus commentedBleh... someday I'll remember to check my work before pushing patches. Sorry for all the notifications!
Comment #17
dorficus commentedThe failure is generating this error in Jenkins
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this messagewhich seems to be an issue with Jenkins and not the DFP module. I think we have 2 options, you can either push forward with the fix as fixed despite the failed test, or we can only test for the filtered bad protocols and not absolute. I've attached a patch that only checks for the bad protocols filtered.Comment #19
marcelovaniMy solution: Use assertPattern()
This will work with http/https on any domain
Changing the priority because this is breaking automated tests for all patches
Comment #21
marcelovaniI reckon the automated test won't pass. The code that tests this patch has a broken test.
It needs to be tested locally and merged in.
Comment #23
bleen commentedWoot!!
Comment #24
marcelovaniAutomated tests are still failing
https://dispatcher.drupalci.org/job/drupal_d7/7025/testReport/DFP/dfpDis...
But it passes on my local. No idea what is going on...
Comment #25
bleen commentedSame here :(
Comment #26
marcelovaniI tried with different php versions locally and all work.
Its really hard to understand what is going on on that CI since there are no screenshots.
Trying changing the pattern...
Comment #28
marcelovaniAgain, the only way to test is by committing the patch, since CI uses the last commit
see https://dispatcher.drupalci.org/job/drupal_d7/7675/artifact/jenkins-drup...
Comment #30
bleen commented/me crosses fingers
Comment #31
bleen commentedstill no dice :( .... BOOOO
Comment #32
marcelovaniComment #33
marcelovaniClean urls is what was breaking it
Comment #35
bleen commentedWell done!!! 10 points to Griffendor