Manual talk:$wgPingback/Flow

Needed to wait for search index

I noticed this article doesn't get suggested in the search box when typing "wgPingback". Other wg variables do work -- e.g., I type wgSitename and it suggests Manual:$wgSitename. This is in the Vector 2022 skin.

Is something misconfigured on this page? I thought it might be because there was no $wgPingback redirect page, but I created that and no change.

Works for me. The search takes a while to update its index, which means it doesn't appear immediately after creating the redirect

Good for me too now, marking as resolved!

I dont like that the box "share data" is auto-checked. It's easily overlooked, especially if you just want to set up a quick test-wiki, for which you certainly dont want to share data.

Documented

• How it is generated
• How it is used
• What is the purpose of it
• How to reset it, and what the effects of doing so will be

Table should cover everything now

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)?

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

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.

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?

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.

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

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

Added rationales for everything.

I added a table indicating the data sent and why we wanted those data points. I couldn't come up with reasons for two of the fields, so it would be helpful if someone else could fill those in.

Added to wiki page

I guess the page should also state were the collected information is stored and if it is publicly accessible or not.

@Legoktm @Ori Livneh Does anybody know?

Updated the page with the basic info that I know of...hope that's helpful.

It indeed is. Thanks a lot!

Enabled this feature on one wiki a couple of weeks ago so there should already be some data available. :)