Blocking ads triggers nag even when no ad would be displayed

[davidfischer]

Details

• Read the Docs URL: https://phpunit.readthedocs.io/en/7.1/
  See: https://twitter.com/s_bergmann/status/1005062504962318341

Expected Result

There shouldn't be ads on this page.

Edit: PHP Unit is a project that has paid to remove ads. As a result, there are not ads on this page. However, if somebody running an ad-blocker tuned to restrict these ads, they will still get an ad block nag even when no ad would be displayed normally.

Actual Result

There are ads? I actually don't see them myself.

Edit: there is an ad block nag when no ad would normally be displayed.

[davidfischer]

I'm not seeing any ads on PHPUnit even in an incognito window.

Is it possible Sebastian saw ads on different docs and had been logged out of RTD?

[sebastianbergmann]

I see this

in a browser with uBlock Origin.

I neither see ads nor the "suggestion to turn off ad blocking" shown above in a browser without an adblocker.

I expect to not get the anti-adblock message when no ads are to be displayed anyway. Looks like a bug to me.

[davidfischer]

Hmmm. I now understand the problem.

The problem here is that the check to see whether an ad should be displayed or not is done server side. With uBlock Origin, you are blocking the server side request. Blocking the server side request triggers this message. If you allowed the server side request, you would not see this message or get an ad.

I'm going to have to think about this as a good solution is not immediately coming to mind.

I'm going to change the name of this issue to better reflect the underlying problem..

[davidfischer]

Counter-intuitively, if you were to whitelist our advertising, you wouldn't get this nag OR the ads.

[Matthewrbowker]

Can also confirm this issue (partially commenting so I can be subscribed).

[davidfischer]

I wanted to give a small update here. I am working on this and I haven't forgotten about it. I expect a fix within a week or two.

Since the server side request to get an ad is being blocked, there are a few possibilities I can see:

• Add yet another API call that just checks if the user has donated (user is ad-free) or if the project has donated (project is ad-free). Presumably this would happen after the page has loaded and before an ad is loaded. I don't love this solution because that check is already done as part of the ads API so I'm specifically slowing down the time-to-ad and the site generally.
• Rather than an extra API, hack this into the footer_html API call -- the one that gets the list of versions to be displayed in the version menu. Since both this API and the ads API are async, the responses could come out of order causing some weirdness or slowness.
• Work something into the docs build process that outputs a flag noting whether the project should be ad-free. If the project is ad-free, don't even call the ads API at all. This could be part of READTHEDOCS_DATA for example. This solves the issue for projects although an individual may see an ad when they shouldn't. That is less of a big deal to me since an individual can allow the ads (and then they won't ever get an ad). I like this solution the best but it is only a partial solution. (EDIT: it would also let people disable advertising by setting a JS variable -- probably not a good solution. However, it could just disable the "nag" and rely on the API still for advertising....)

[davidfischer]

Just to give an update here there is a partial fix for this (will cause ad-free projects to not show the nag, doesn't fix ad-free users) that will go live on Monday. It will not take effect until the project is rebuilt because it writes out the ad-free status as part of the build process.

[davidfischer]

The fix didn't quite work out as planned. I need to look at this again.