You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

CentralNotice: Difference between revisions

From Wikitech-static
Jump to navigation Jump to search
imported>Krinkle
No edit summary
imported>AndyRussG
(Remove outdated material and add WMF deployment documentation)
 
Line 1: Line 1:
{{Outdated|year=2015}}
'''CentralNotice''' is the MediaWiki extension that delivers announcements (usually in the form of banners) to WMF wikis. It is used by the [[Fundraising|Advancement]] 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.


'''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 contains information about the CentralNotice setup on the WMF's cluster. For developer information, or to learn how to install CentralNotice on your own wiki, please see [[mw:Extension:CentralNotice|Extension:CentralNotice]] on [[mw:|Mediawiki]]. For information about how to create and configure CentralNotice campaigns and banners, see [[:meta:Help:CentralNotice|Help:CentralNotice]] on [[meta:|Meta-Wiki]].


'''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 [[mw:Extension:CentralNotice|Extension:CentralNotice]] on [[mw:|Mediawiki]]. For information about how to create and configure CentralNotice campaigns and banners, see [[:meta:Help:CentralNotice|Help:CentralNotice]] on [[meta:|Meta-Wiki]].
=Deployment=


CentralNotice deployments are different from those of most other extensions, since changes merged to the master branch on Gerrit are not automatically included in the weekly [[mw:Wikimedia_Release_Engineering_Team/Train_deploys|train deploys]].


Instead, branches for each weekly train deploy are created from the wmf_deploy branch, and those are deployed each week with the train.


= Operations =
Changes to wmf_deploy should be made in such a way that future merges from master are simple and conflict-free. New patches should always be created first on the master branch, and never directly on the wmf_deploy branch.


Since the [https://meta.wikimedia.beta.wmflabs.org/wiki/Special:CentralNotice beta cluster] is synced to the master branch of CentralNotice (and of other codebases) and is set up similarly to production, it's an ideal place to smoke-test changes currently in master before deploying them.


== Disabling & Re-enabling CentralNotice ==
==Train deploys==


To disable CentralNotice, do the following:
To put changes out on the train, merge or cherry-pick them from master to wmf_deploy. To push out all changes that have accumulated in master since the last deploy, just merge master into wmf_deploy.


* Login to fenari
Since the train starts on Tuesday, it's often a good idea to do this on a Friday or a Monday, to keep wmf_deploy in sync with what is deployed on production.
* Edit the InitialiseSettings.php file
:* <tt>cd /home/wikipedia/common/wmf-config && vim InitialiseSettings.php</tt>
* Locate the section <tt>wmgUseCentralNotice</tt>
* Comment out all lines that set a wiki to true, '''EXCEPT''' first entry <tt>default</tt>
* Set <tt>default</tt> to <tt>false</tt>.
* Save changes and sync out the file:
:* <tt>sync-file InitialiseSettings.php 'disabling CentralNotice'</tt>


To re-enable it, just uncomment the lines you commented out, and put <tt>true</tt> for <tt>default</tt>
To see what has accumulated on master and since the last time master was merged to wmf_deploy (other than translation updates) use this command:


== Caching ==
<pre>git log --pretty=format:"%h%x09%s" --no-merges wmf_deploy..master | grep -v "Localisation updates"</pre>
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.
(Note that changes that have already been cherry-picked to wmf_deploy will still show up in that log.)


== Banner delivery ==
==SWAT deploys==
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 [http://meta.wikimedia.org/w/index.php?title=Special%3ABannerLoader&banner=B_JM_Junetest_WS&campaign=none&userlang=en&db=enwiki&sitename=Wikipedia&country=US example]).


== Issues ==
Changes that need to be deployed urgently may be placed on a [[SWAT_deploys|SWAT deploy]]. See that page for details on what changes may be placed on a SWAT deploy. To request a SAT deployment, edit the appropriate slot on the [[Deployments|Deployments page]].


=== Memcached failure ===
CentralNotice changes to be deployed on a SWAT deploy should be cherry-picked from master to wmf_deploy. The Gerrit change for the merged wmf_deploy patch should be linked on the Deployments page.


If there is a memcached lookup failure when a banner is requested, the banner will not be shown. Instead, the Special:BannerLoader file will load with just the JavaScript comment "/* Failed cache lookup */". No error or other output from CentralNotice will be shown to the user.
When deploying on a SWAT deploy on Tuesday, Wednesday or Thursday, the change will likely be required for both Mediawiki versions currently on production on that day; this should be noted in the request on the Deployments page. For details on what's on production, see the [[mw:MediaWiki_1.35/Roadmap|Roadmap]] for the current Mediawiki version. (The preceding link is only for Mediawiki 1.35.)
 
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 ===
 
CentralNotice adds a GeoIP lookup to the head of each page request. Once the lookup is completed, the rest of the JavaScript gets executed and the banner is displayed. If the GeoIP lookup fails, it may block the execution of other JavaScript or delay loading the page. If this is a chronic problem, it may be necessary to increase caching for the GeoIP lookups or to completely disable CentralNotice.
 
===Banners bump down page content after page has loaded===
See [[/Optimizing banner loading]]
 
[[Category:Fundraising]]
[[Category:MediaWiki production]]

Latest revision as of 16:35, 16 March 2020

CentralNotice is the MediaWiki extension that delivers announcements (usually in the form of banners) to WMF wikis. It is used by the Advancement 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 contains information about the CentralNotice setup on the WMF's cluster. 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.

Deployment

CentralNotice deployments are different from those of most other extensions, since changes merged to the master branch on Gerrit are not automatically included in the weekly train deploys.

Instead, branches for each weekly train deploy are created from the wmf_deploy branch, and those are deployed each week with the train.

Changes to wmf_deploy should be made in such a way that future merges from master are simple and conflict-free. New patches should always be created first on the master branch, and never directly on the wmf_deploy branch.

Since the beta cluster is synced to the master branch of CentralNotice (and of other codebases) and is set up similarly to production, it's an ideal place to smoke-test changes currently in master before deploying them.

Train deploys

To put changes out on the train, merge or cherry-pick them from master to wmf_deploy. To push out all changes that have accumulated in master since the last deploy, just merge master into wmf_deploy.

Since the train starts on Tuesday, it's often a good idea to do this on a Friday or a Monday, to keep wmf_deploy in sync with what is deployed on production.

To see what has accumulated on master and since the last time master was merged to wmf_deploy (other than translation updates) use this command:

git log --pretty=format:"%h%x09%s" --no-merges wmf_deploy..master | grep -v "Localisation updates"

(Note that changes that have already been cherry-picked to wmf_deploy will still show up in that log.)

SWAT deploys

Changes that need to be deployed urgently may be placed on a SWAT deploy. See that page for details on what changes may be placed on a SWAT deploy. To request a SAT deployment, edit the appropriate slot on the Deployments page.

CentralNotice changes to be deployed on a SWAT deploy should be cherry-picked from master to wmf_deploy. The Gerrit change for the merged wmf_deploy patch should be linked on the Deployments page.

When deploying on a SWAT deploy on Tuesday, Wednesday or Thursday, the change will likely be required for both Mediawiki versions currently on production on that day; this should be noted in the request on the Deployments page. For details on what's on production, see the Roadmap for the current Mediawiki version. (The preceding link is only for Mediawiki 1.35.)