CentralNotice is the Mediawiki extension that delivers announcements (usually in the form of banners) to WMF wikis. It is used heavily by the Fundraising team to solicit donations, and for announcements of interest to Wikimedia communities and users. CentralNotice can target announcements by country, language, project, device and logged-in status.
This page will contain information about the CentralNotice setup on the WMF's cluster. It is currently out of date. For developer information, or to learn how to install CentralNotice on your own wiki, please see Extension:CentralNotice on Mediawiki. For information about how to create and configure CentralNotice campaigns and banners, see Help:CentralNotice on Meta-Wiki.
|This document is out of date. (May, 2015)|
Disabling & Re-enabling CentralNotice
To disable CentralNotice, do the following:
- Login to fenari
- Edit the InitialiseSettings.php file
- cd /home/wikipedia/common/wmf-config && vim InitialiseSettings.php
- Locate the section wmgUseCentralNotice
- Comment out all lines that set a wiki to true, EXCEPT first entry default
- Set default to false.
- Save changes and sync out the file:
- sync-file InitialiseSettings.php 'disabling CentralNotice'
To re-enable it, just uncomment the lines you commented out, and put true for default
Special:BannerListLoader is excluded from the normal Squid cache header override. This is accomplished by having "cache=/cn.js" in the URL, which matches a regex filter on the Squid side. The BannerListLoader is normally cached for 5 minutes on the server side and 5 minutes on the client side.
Special:BannerLoader is subject to the normal Squid cache header override. It is cached for 10 minutes on the server side and not cached at all on the client side.
The way that banners are delivered to the client is somewhat complicated, mainly due to the requirement that banners be geotargetable. The following is a brief explanation of the process. On every wiki page request, there are several things that get loaded for CentralNotice:
- First, a direct call to bits.wikimedia.org/geoiplookup to load the GeoIP info - this happens in the head. bits.wikimedia.org/geoiplookup just returns a 1 line JS statement that sets the global Geo variable, including the important bit - Geo.country. IPv6 lookups are not yet supported.
- Next, it loads bannerController.js through a ResourceLoader module, also in the head. bannerController.js doesn't have any self executing code, it's just a bunch of function definitions.
- Next, as soon as the siteNotice div loads in the page, it calls the initialize function from bannerController.js. This causes bannerController.js to make an AJAX request for the BannerListLoader (which has a URL like https://en.wikipedia.org/w/index.php?cache=%2Fcn.js&title=Special%3ABannerListLoader&language=en&project=wikipedia&country=US). The BannerListLoader returns a JSON string with the banners that the user is eligible to see. This file is supposed to be cached for 5 minutes on the server side and 5 minutes on the client side.
- BannerController then processes this list and makes a JSONP request to the BannerLoader on meta wiki. The BannerLoader returns a JS statement to load a banner through a callback function in the BannerController (See example).
If this happens:
- Identify which memcached node/s is the problematic one by running php /home/wikipedia/common/php-1.5/maintenance/mctest.php on a host that has nfs mounted.
- For each host listed with a get: 0 time remove them from /home/wikipedia/common/php-1.5/mc-pmtpa.php and replace with a spare.
- sync-file to the cluster
GeoIP lookup failure