Page MenuHomePhabricator

CentralNotice: banners not showing on mobile versions of, Wikidata and Wikisource
Closed, ResolvedPublic


Like the title sez... banners are not working on the several mobile sites.

This can be seen by opening the network tab in the browser developer tools and going to the banner preview link next to each host name, below.

For the first two sites, there are two requests to Special:BannerLoader: first to, which redirects to, which returns a 404. On Wikisource, we get a request to BannerLoader on the unresolvable m.meta.wikimedia.

The cause of the bug is our misuse of the function MobileContext::getMobileUrl() in CentralNotice.hooks.php. That function is designed to work only for the URL of the current wiki. However, we always call it to try to get the mobile URL of getMobileUrl() works by applying a template defined by $wgMobileUrlTemplate. The value of this variable is different for the sites in question (see [[ | InitialiseSettings.php ]]).

tl;dr: config + incorrect use of a function, but no obvious solution...

Maybe the cleanest route will be to reform how $wgCentralSelectedBannerDispatcher works...

Also note that the client-side JS is not handling the incorrect banner loader calls as expected. (I'll file a separate bug for that...)

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 14 2017, 5:07 AM

I guess this is particularly problematic with the increased use of mobile devices to access Wikimedia sites.

DStrine triaged this task as Medium priority.Feb 14 2017, 9:57 PM
AndyRussG updated the task description. (Show Details)Feb 15 2017, 12:26 AM

Why do you need to use getMobileUrl() at all?
You can request a JS resource on a desktop domain from a mobile domain.

Why do you need to use getMobileUrl() at all?
You can request a JS resource on a desktop domain from a mobile domain.

Yeah, that may be the best solution... Since we use ugly URLs, they don't redirect to mobile URLs on mobile devices.

My only hesitation is a possible impact on Analytics, since in webrequest logs, this would show up as a desktop request even when it's really mobile traffic... So Analytics work might be needed avoid skewing the numbers there.

Working out the mobile domain for an external site is going to be tricky. Could you use a blacklist for the time being given its 3 wikis which have the problem?

Definitely no problem to put together a temporary measure like that... I was looking for something a bit nicer, since this issue is also blocking a clean solution for T154954. So, maybe an additional CentralNotice config variable with the mobile banner loader URL on meta, for the time being...?

Change 338160 had a related patch set uploaded (by AndyRussG):
Add $wgCentralSelectedMobileBannerDispatcher global for mobile

Change 338160 merged by jenkins-bot:
Add $wgCentralSelectedMobileBannerDispatcher global for mobile

AndyRussG closed this task as Resolved.Sep 13 2019, 4:35 PM
AndyRussG claimed this task.

This has been working for a while, it just seems that we forgot to close it!