Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Showheroes Bid Adapter : full rework of the adapter #12283

Open
wants to merge 21 commits into
base: master
Choose a base branch
from

Conversation

FilipStamenkovic
Copy link
Contributor

Type of change

  • Updated bidder adapter

Description of change

Update the showheroes-bs bidder adapter.

PR has the following updates:

  • remove legacy code that is not supported anymore
  • replace the old endpoint with prebid-sh with the new openrtb2/auction
  • use ortbConverter to construct a bid request
  • in case of outstream ads, provide the renderer-related parameters in the response (the old static renderer is not working anymore)
  • by using openRTB, automatically add support for: fpd, floor module, eids, etc.

To test the upgrade just set the openRTB request as a test request:

pbjs.setConfig({ortb2: {test: 1}})

Other information

@ChrisHuie ChrisHuie changed the title Showheroes bid adapter: full rework of the adapter Showheroes Bid Adapter : full rework of the adapter Oct 2, 2024
Copy link
Collaborator

@Rothalack Rothalack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, working in testing for me

@Rothalack
Copy link
Collaborator

I thought this was good to go, but it shows conflicts preventing it from merging. Can you resolve the conflicts? @FilipStamenkovic

@FilipStamenkovic
Copy link
Contributor Author

@Rothalack Thanks for the review. I resolved the conflicts. On master branch behavior of the loadExternalScript was changed and this PR simply removes the usage of that function. Please take another look.

Copy link
Collaborator

@robertrmartinez robertrmartinez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor things + one question for committee

// delete user agent from oRTB, we'll get it from the header
(req?.device?.ua) && delete req.device['ua'];
// 'sua' is 2.6 standard, we operate with 2.5
(req?.device?.sua) && delete req.device['sua'];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do not necessarily need to check can just call delete (either way is fine just pointing out)

delete req?.device?.ua;
delete req?.device?.sua;

code: BIDDER_CODE,
gvlid: GVLID,
aliases: ['showheroesBs'],
supportedMediaTypes: [VIDEO],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this PR is removing BANNER support from this adapter?

I feel like this could be considered a "breaking change" and might have to be put into a "major" prebid version.

Lets ask @patmmccann @bretg @dgirardi @ChrisHuie

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, we don't have anyone using showheroes prebid bidder for banner ads. We plan to do the 'full rework' of banner ads handling next year (probably).

My initial thought was because of that is to temporarily remove the support for BANNER and then later open a new PR where BANNER is re-enabled.

But if this would be a 'breaking change' requiring us to wait for next major release, I can revert my commit and 're-enable' legacy BANNER support.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually do not really care either way but figured it would be good to double check.

I am not aware of us having this use case come up before (where an adapter removes a supported media type)

@patmmccann @bretg @dgirardi @ChrisHuie

@@ -210,6 +132,7 @@ export const spec = {
});
});
}
logInfo(`found urls to sync:`, syncs);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just making sure this info log is wanted still

// 'sua' is 2.6 standard, we operate with 2.5
(req?.device?.sua) && delete req.device['sua'];
return req;
},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we decided to completely remove this logic instead?

So your server is okay with receiving both ua and sua ??

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the server is ok with receiving both.

  • sua we don't support at the moment, but there is a plan to upgrade to 2.6, so at that point, we'll start using and we won't need to open another PR for our bidder.
  • ua we'll use it and as a fallback we'll use a header if ua is not provided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants