One issue that comes up time and again when working on classified sites such as Daft.ie and Adverts.ie is the inadvertent blocking of site functionality by the AdBlock Plus extension. As so many parts of classified sites will logically have phrases like “ad” in the url, legitimate site content and features can be blocked inadvertently under the mistaken assumption that they’re banner ads or the like.
So is there a way to detect AdBlock Plus being run in a user’s browser, and change the output accordingly?
The answer is “Yes. Well, sort of”.
Wait, what’s an ad block?
For those of you unfamiliar with what AdBlock Plus (ABP) does, it is a Firefox or Chrome extension which has:
the primary goal of removing advertisements. For that, it will look at all requests made by web pages and block the request if the address the request should go to matches a filter in Adblock Plus.
In plain English, this should mean that flashing banner and pop-up ads should be removed from the internet for any users with this plugin installed. So far, so good.
So what’s the problem?
ABP works by blocking content loaded from urls which match some predefined filters. For example, urls like http://www.example.com/ads/serveAds.php?adType=annoying+flashing+ad ABP is likely to load an ad which a user may not wish to see. ABP blocks this content from ever reaching the user.
However, on classified sites legitimate site content may be loaded from similar urls. On Adverts.ie for example, the url http://www.adverts.ie/ajax/getCategories.php?adType=1 loads up a list of categories used in one of the site’s menus. When ABP sees this url, it matches a filter for the term “adType” and blocks the script from loading. This results in one of the site menus not loading, despite it being a primary part of the site, and not another banner ad.
Uh oh. So what now?
There are two options realistically open:
- Rename all site urls and parameters to avoid mentioning “ad” or similar keywords
- Get users to add the classifieds site to their ABP whitelist
The first option above has the benefit of not requiring any user action. However the downside is that the code behind the site becomes gradually trickier to follow, as words like “adType” are appropriate variable names, likely to be re-used by developers at some point.
The attraction of the second option is that it only requires action by the minority of site users with ABP enabled. The downside is pretty significant though. As ABP becomes increasingly mainstream, its’ users are becoming less and less technical. Having to wait for users to contact the site owner with a complaint, then be instructed on using the ABP whitelist, can be a time-consuming process.
A compromise would be attempting to detect whether ABP is installed, and if so display a warning with instructions on how to use the whitelist to allow the site to function correctly.
Technical nuts and bolts
var abp = true;
This file should do nothing other than reset the flag, which shows that ABP is non-functional.
This load is followed by another script block, which will print a message to the user if the ABP flag is still set.
// Flag didn't get unset, assume ABP is active
If all has gone to plan, then any users with ABP enabled should see a warning like that shown in the image below.
If you have ABP enabled, you should already have seen something very similar towards the top of the page!
Is this guaranteed to work?
This method does work, but it depends heavily on the keywords being used. Obviously ABP don’t want sites to detect whether their plugin is active and work around it, rendering the extension useless. There have been similar tricks like this in the past which the extension developers have subsequently worked around.
The key is ensuring that the js file which will unset the ABP file matches as many ABP filters as possible. This should ensure that it gets treated like a regular ad url, so is a reliable indicator as to whether ABP is running or not.
Happily at this moment in time, the above method does the job just fine!