See T126947 for context. Apparently the popular ad blockers consider /pageviews, /viewcounts, and other similar routes to be serving ads. This includes the WMF pageviews API itself, so we'll have to "shadow" usage of it in order to get past the ad blockers. Ad blockers are very popular, and it appears some wikis are apprehensive about linking to Pageviews Analysis for this very reason.
This is especially a problem for us as the route of the application itself is /pageviews. This means the assets (CSS/JS) are also blocked by default. A known workaround is to:
- Use a middleman API service with an acceptable route to make requests to the pageviews API for us
- Also move our assets to a different route
I did some quick testing by adding a pageviews API wrapper on one of my Ruby apps. This works, but I worry about the overhead of using Ruby, and also my app in particular does not have good caching at the moment. If it did, I can say with some confidence that this won't be too much slower than hitting the actual API directly. Serving the assets for Pageviews Analysis could live at the same place our API wrapper lives.
So my proposal is we look into creating a lightweight PHP app that only acts as an API wrapper, and serves our static assets. This way we could use the default lighttpd server Tool Labs offers, and the assets at least will load just as fast as they do now. For the API wrapper, we'll need some talented PHP developers to put it together, perhaps naming it pv. So the route we'd hit via AJAX from Pageviews Analysis would mimic the actual API and send back the same response, something like:
as opposed to:
Does this seem worthwhile? How difficult would it be to implement the API wrapper? Are there any alternative solutions you can think of?
- Move the tool to a different URL?
- Talk to Ublock about taking this off the list
- Show a notice to people who can't see part of the page, encouraging them to update ad blocker