Wikimedia Bugzilla is closed!

from the FR-Tech team:

"+1, let's abandon that extension :)"

"Yeah, I think we're moving pretty solidly toward abandoning FundraiserStatistics, as it hasn't worked in months. ...which means we need more pretty graphs on frdata. :)"

Short term it could be hacked to read off of db78, which will work only until pmtpa goes dark later this year. But my vote is just to remove the extension altogether.

Both ContributionReporting and ContributionTracking?

Change 83664 had a related patch set uploaded by Reedy:
Initial disable of ContributionReporting/Contributiontracking

https://gerrit.wikimedia.org/r/83664

Change 83668 had a related patch set uploaded by Reedy:
Remove ContributionReporting and ContributionTracking

https://gerrit.wikimedia.org/r/83668

Not ContributionTracking; that's still highly useful.

For the moment; because we do not have a good replacement for ContributionReporting and it is the best source of historical data -- can we just remove the cron jobs that are launching the scripts that hit db1008?

I'm not entirely sure where those are launching off from though.
The script is PopulateFundraisingStatistics.php

Change 83664 merged by jenkins-bot:
Initial disable of ContributionReporting

https://gerrit.wikimedia.org/r/83664

I don't think it's just cron jobs--there are also direct hits to the db by webservers at content generation time.

Change 83668 abandoned by Reedy:
Remove ContributionReporting and ContributionTracking

https://gerrit.wikimedia.org/r/83668

(In reply to comment #7)
> I don't think it's just cron jobs--there are also direct hits to the db by
> webservers at content generation time.
Grrr; you're correct. I hate this extension. I guess nuke it -- it's no longer live. How can we place a redirect to https://frdata.wikimedia.org on https://wikimediafoundation.org/wiki/Special:FundraiserStatistics

Apache rule something like the below?
    RewriteCond %{HTTP_HOST} ^frdata\.wikimedia\.org$
    RewriteRule ^(.*)$ https://wikimediafoundation.org/wiki/Special:FundraiserStatistics [R=301,L,NE]

That would work if that's an accepted solution for this type of problem.

Can you implement that Reedy?

(In reply to comment #11)
> Can you implement that Reedy?
* Correction -- deploy that; you already wrote it :p

It's on samarium.wikimedia.org, which I'm guessing is a frack host.

So it either needs to be done on that host (not sure where the apache config is for this - puppet). Or we can put it in the general redirects.conf in operations/apache-config,git, and then point it at the wikimedia loadbalancer

Not sure what else (if anything) that host is actually doing

Samarium is indeed a frack host and is on frack's puppet instance, but we don't need to make any changes there, since we're just redirecting to its existing top page.

(In reply to comment #14)
> Samarium is indeed a frack host and is on frack's puppet instance, but we
> don't
> need to make any changes there, since we're just redirecting to its existing
> top page.

I'm confused. If frdata.wikimedia.org is on samarium, unless we point the subdomain back to the main load balancers, there needs to be a redirect in the current apache config on samarium to point it to foundationwiki

(In reply to comment #15)
> I'm confused. If frdata.wikimedia.org is on samarium, unless we point the
> subdomain back to the main load balancers, there needs to be a redirect in
> the
> current apache config on samarium to point it to foundationwiki

(In reply to comment #9)
> [...] How can we place a redirect to https://frdata.wikimedia.org on
> https://wikimediafoundation.org/wiki/Special:FundraiserStatistics

Doesn't that mean from <https://wikimediafoundation.org/wiki/Special:FundraiserStatistics> to <https://frdata.wikimedia.org>, not the other way around?

Yes (Comment #16) exactly.

i.e. redirects.conf would get something along these lines:

RewriteCond %{HTTP_HOST} (^|\.)wikimediafoundation\.(org|com|net|info)$
RewriteRule ^/wiki/Special:FundraiserStatistics$ https://frdata.wikimedia.org/ [R=301,L]

Oh. Need to pay more attention.

Seems alright...

Can do it in MediaWiki and make a placeholder special page with something like:

$response = RequestContext::getMain()->getRequest()->response();
$response->header( "HTTP/1.1 301 " . HttpStatus::getMessage( 301 ) );

Yes we could; but that would mean perpetually having a stub special page/stub extension which sounds horrible.

In fact - I don't know if this is something to solve but:

When I come to this address:

http://wikimediafoundation.org/wiki/Support_Wikipedia/cs

And try to "donate", result is this:

Cannot contact the database server: Unknown MySQL server host 'db1008.eqiad.wmnet' (0) (db1008.eqiad.wmnet)

I googled the original address - I didn't come to it via any link in wikipedia, but for ex on French lang mutation it is solved nicely. It should be done for all mutations, shouldn't be?

http://wikimediafoundation.org/wiki/Support_Wikipedia/fr

Bye

That was an old out of date page. I've now redirected it (and all the other Support Wikipedia subpages) to our current page on donate.wikimedia.org.

(In reply to comment #21)
> In fact - I don't know if this is something to solve but:
> 
> When I come to this address:
> 
> http://wikimediafoundation.org/wiki/Support_Wikipedia/cs
> 
> And try to "donate", result is this:
> 
> Cannot contact the database server: Unknown MySQL server host
> 'db1008.eqiad.wmnet' (0) (db1008.eqiad.wmnet)
> 
> I googled the original address - I didn't come to it via any link in
> wikipedia,
> but for ex on French lang mutation it is solved nicely. It should be done for
> all mutations, shouldn't be?
> 
> http://wikimediafoundation.org/wiki/Support_Wikipedia/fr
> 
> Bye

(In reply to comment #18)
> i.e. redirects.conf would get something along these lines:
> 
> RewriteCond %{HTTP_HOST} (^|\.)wikimediafoundation\.(org|com|net|info)$
> RewriteRule ^/wiki/Special:FundraiserStatistics$ https://frdata.wikimedia.org/ [R=301,L]

Submitting a patch to do this should be pretty simple. The relevant repo is here: <https://git.wikimedia.org/tree/operations%2Fapache-config.git>.

as far as I can tell, this has been fixed