Topic on Manual talk:$wgPingback

Jump to navigation Jump to search

Commit message for this feature

7
Summary by Legoktm

Table should cover everything now

RobLa-WMF (talkcontribs)

Quoting Ori's commit message:

Add option for sharing info about this MediaWiki install via pingback When $wgPingback is true, MediaWiki will periodically ping https://www.mediawiki.org/beacon with basic information about the local MediaWiki installation. This data includes, for example, the type of system, PHP version, and chosen database backend.
The pingback is sent via a deferred (post-send) update whenever $wgVersion changes, using the updatelog table to ensure we don't send duplicate pingbacks. A database lock ensures only one thread attempts to send the pingback, and a cache key throttles attempts to no more than once per hour.
$wgPingback is false by default. The web installer has a checkbox for controlling this option, and it is checked by default. This nudges new installs to turn on pingbacks, but does not sneak this decision past sysops of existing installs.

Do we need to incorporate this information in the page? How/where do we document the data we plan to collect (other than in the code)?

Legoktm (talkcontribs)

I added a table indicating what data would be collected, and some examples of what the data might be.

šŸ˜‚ (talkcontribs)

It should be more than just examples....I think it's crucial that we clearly document every piece of data that's included, and when we add a new piece of data it must be added here.

RobLa-WMF (talkcontribs)

Thanks for bringing this up @^demon. On first read, I thought "it looks like @Legoktm has a really complete set of examples". However, it's possible to accidentally create a monster here. For example, the HTTP User-agent field has a mess of layered ad hoc information, and has been prone to years of engineering and analytics abuse. ^demon, when you emphasize "every piece of data", do you mean that each possible value for each field should be enumerated?

Legoktm (talkcontribs)

I don't think that's even possible. For example, php_uname( 'r' ) on my system returns "4.6.6-300.fc24.x86_64", which changes on every kernel update.

šŸ˜‚ (talkcontribs)

Nah, not ever possibly value, just every type of data (with an example or two of possible values)....like Lego says, it's impossible to be exhaustive here. And yeah, it's up to date now, I was mainly making sure they're not forgotten in the future. See

Legoktm (talkcontribs)

OK, I think the current table should cover everything. Please edit the wiki page if something is missingĀ :)