[[ https://lists.wikimedia.org/hyperkitty/list/wikimediapl-l@lists.wikimedia.org/message/FMWGW2P5G6XRUYI7DZD2XAZEIK3L6EVY/ | Message-ID: <CACNAgmwRgLo4Uy0w9ZtAi07kB_rA9wxC5T3p+kr+ftWDUq7hWg@mail.gmail.com> ]] has been sent to lists.wikimedia.org on **Mon, 19 Feb 2024 15:47:24 +0000** but it seems it got pushed out around **Thu, 22 Feb 2024 00:56:30 +0000**
Sadly it was a reminder for a event that was happening on Mon, 19 Feb 2024 CET.
I am the moderator of this list and there was no notificiation about this item being stuck in the moderators' queue.
What went wrong?
`Received` SMTP headers from my self-hosted email server:
```
1 Received: from lists.wikimedia.org (lists.wikimedia.org [IPv6:2620:0:861:1:208:80:154:21])
2 by q.saper.info (8.17.1/8.17.1) with ESMTPS id 41M0uhR8058340
3 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO)
4 for <saper@saper.info>; Thu, 22 Feb 2024 00:56:43 GMT
5 (envelope-from wikimediapl-l-bounces@lists.wikimedia.org)
6 Authentication-Results: q.saper.info;
7 dkim=pass (1024-bit key; unprotected) header.d=lists.wikimedia.org header.i=@lists.wikimedia.org header.b=eAVl31ja
8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
9 d=lists.wikimedia.org; s=wikimedia; h=Content-Transfer-Encoding:Content-Type:
10 List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Help:List-Archive:
11 List-Id:Subject:Reply-To:To:Message-ID:Date:From:MIME-Version:Sender:Cc:
12 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
13 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References;
14 bh=1qjG+WUpo9/38I6pbfe9tI8jkd9U1iJEoVm5d7f8xRo=; b=eAVl31jaiAc3M//XCMq0lIzCDW
15 TMQWd38Wk85vsAo8NMtr2naaGG598M6moS3Y9VDtdKNvkn4pF7yKRyT1bYtAqII3T30U5ifBcc06u
16 fFjxSGYHYQdM5gt8SFb1WonqBjKIXolvvpCM/VZPE6O4MKpz44TLSNtG1SQd2to7rMjk=;
17 Received: from localhost ([::1]:49108 helo=lists1001.wikimedia.org)
18 by lists1001.wikimedia.org with esmtp (Exim 4.92)
19 (envelope-from <wikimediapl-l-bounces@lists.wikimedia.org>)
20 id 1rcxO2-0000mo-V0; Thu, 22 Feb 2024 00:56:30 +0000
21 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:43259)
22 by lists1001.wikimedia.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128)
23 (Exim 4.92)
24 (envelope-from <malgorzata.gramatnikowska@wikimedia.pl>)
25 id 1rc5rX-0002Dn-5x
26 for wikimediapl-l@lists.wikimedia.org; Mon, 19 Feb 2024 15:47:24 +0000
27 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-5112bd13a4fso5921148e87.0
28 for <wikimediapl-l@lists.wikimedia.org>; Mon, 19 Feb 2024 07:47:23 -0800 (PST)
29 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
30 d=1e100.net; s=20230601; t=1708357637; x=1708962437;
31 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
32 :from:to:cc:subject:date:message-id:reply-to;
33 bh=vFy0GD0boBaaWXEMLEaaIIJ8JI916/MAOdh+7qxadW0=;
34 b=nMHe1JqEZn3JvuHAvbnlAaLzKBHFUS88yxcHOT7GMAD+GF0u1q9WidStYU1kUuWrTP
35 hNa/dymIRs6hJf5qAJ1FvBcurpcvZ4uffMIThs3ezlbWCyuEuvsacwnoxNR1YUZyfvb6
36 mKQ/GV+BPLz786QliaNkspzVAbN9W5bYiXNCaRry11C3pstqkKpQ5s0BfrGVlr68i4l+
37 yRqvvBDorpn4QnD2SDhjQ8ieOrBhP2JUFIHvNv0K7RFkPYJ2GcHYXhc+xxg0fP7IXxvG
38 9wMI4MDyGwq9Y0h7PGfmolAQHcfxW1A0sDGIH7JsV4GZzxOCaNmfDloowYqHpJdKjE7D
39 vsQg==
```
The delay seems to be between lines 17-20 and 21-26
**Steps to replicate the issue** (include links if applicable):
* Create virtual environment with `virtualenv-3.9 pywikibot`
* Activate it `. pywikibot/bin/activate`
* Try `pwb upload`
**What happens?**:
```
ERROR: upload.py not found! Misspelling?
```
**What should have happened instead?**:
Upload script should run as documented in https://www.mediawiki.org/wiki/Manual:Pywikibot/upload.py
**Software version** (skip for WMF-hosted wikis like Wikipedia):
pywikibot 8.1.2
**Other information** (browser name/version, screenshots, etc.):
Steps to Reproduce:
php ./maintenance/runJobs.php'
on MediaWiki 1.31 (FreeBSD package mediawiki131-php73-1.31.6) with PostgreSQL
Actual Results:
Jobs to execute:
```
pgwiki=# select job_id, job_cmd, job_timestamp, job_attempts from mediawiki.job;
job_id | job_cmd | job_timestamp | job_attempts
--------+-------------------------+------------------------+--------------
1 | refreshLinksPrioritized | 2020-01-04 05:11:56+00 | 0
2 | refreshLinksPrioritized | 2020-01-04 05:34:12+00 | 0
3 | refreshLinksPrioritized | 2020-01-04 05:35:26+00 | 0
4 | refreshLinksPrioritized | 2020-01-04 06:05:10+00 | 0
5 | refreshLinksPrioritized | 2020-01-04 06:52:20+00 | 0
6 | refreshLinksPrioritized | 2020-01-04 07:01:01+00 | 0
7 | refreshLinksPrioritized | 2020-01-04 07:27:10+00 | 0
8 | refreshLinksPrioritized | 2020-01-04 07:27:31+00 | 0
(8 rows)
```
LocalSettings.php (parts):
```
$wgSitename = "PostgreSQL wiki";
$wgMetaNamespace = "Project";
## The URL base path to the directory containing the wiki;
## defaults for all runtime URL paths are based off of this.
## For more information on customizing the URLs
## (like /w/index.php/Page_title to /wiki/Page_title) please see:
## https://www.mediawiki.org/wiki/Manual:Short_URL
$wgScriptPath = "";
$wgArticlePath = "/wiki/$1";
## The protocol and server name to use in fully-qualified URLs
$wgServer = "https://prehistoric.garden";
(...)
$wgDBtype = "postgres";
$wgDBserver = "localhost";
$wgDBname = "pgwiki";
$wgDBuser = "mediawiki";
(...)
$wgDebugLogPrefix = date( '[Y-m-d H:i:s] ' );
$wgDebugLogFile = "/var/log/php/mw-debug-{$wgDBname}.log";
```
Debug log:
```
[2020-02-09 23:21:57] IP: 127.0.0.1
[2020-02-09 23:21:57] Start command line script ./maintenance/runJobs.php
[caches] cluster: APCUBagOStuff, WAN: mediawiki-main-default, stash: db-replicated, message: APCUBagOStuff, session: MemcachedPhpBagOStuff
[caches] LocalisationCache: using store LCStoreCDB
[DBConnection] Wikimedia\Rdbms\LoadBalancer::openConnection: calling initLB() before first connection.
[DBReplication] Wikimedia\Rdbms\LBFactory::getChronologyProtector: using request info {
"IPAddress": "127.0.0.1",
"UserAgent": false,
"ChronologyProtection": false,
"ChronologyPositionIndex": 0
}
[DBQuery] Schema "mediawiki" already in the search path
[DBConnection] Wikimedia\Rdbms\LoadBalancer::openConnection: connected to database 0 at 'localhost'.
[exception] [2b7718629e1bb9406cd6d7f8] [no req] MWException from line 547 of /usr/local/www/mediawiki/includes/SiteConfiguration.php: No such wiki 'pgwiki-mediawiki'.
#0 /usr/local/www/mediawiki/includes/jobqueue/JobQueueGroup.php(453): SiteConfiguration->getConfig(string, array)
#1 /usr/local/www/mediawiki/includes/libs/objectcache/WANObjectCache.php(1243): JobQueueGroup->{closure}(boolean, integer, array, NULL)
#2 /usr/local/www/mediawiki/includes/libs/objectcache/WANObjectCache.php(1117): WANObjectCache->doGetWithSetCallback(string, integer, Closure, array)
#3 /usr/local/www/mediawiki/includes/jobqueue/JobQueueGroup.php(455): WANObjectCache->getWithSetCallback(string, integer, Closure, array)
#4 /usr/local/www/mediawiki/includes/jobqueue/JobQueueGroup.php(324): JobQueueGroup->getCachedConfigVar(string)
#5 /usr/local/www/mediawiki/includes/jobqueue/JobQueueGroup.php(425): JobQueueGroup->getQueueTypes()
#6 /usr/local/www/mediawiki/includes/jobqueue/JobQueueGroup.php(369): JobQueueGroup->getCoalescedQueues()
#7 /usr/local/www/mediawiki/includes/jobqueue/JobQueueGroup.php(254): JobQueueGroup->getQueuesWithJobs()
#8 /usr/local/www/mediawiki/includes/jobqueue/JobRunner.php(165): JobQueueGroup->pop(integer, integer, array)
#9 /usr/local/www/mediawiki/maintenance/runJobs.php(89): JobRunner->run(array)
#10 /usr/local/www/mediawiki/maintenance/doMaintenance.php(94): RunJobs->execute()
#11 /usr/local/www/mediawiki/maintenance/runJobs.php(122): require_once(string)
#12 {main}
[DBConnection] Wikimedia\Rdbms\{closure}: closing connection to database 'localhost'.
```
Expected Results:
Jobs should execute correctly
Consider the following scenario:
I go to https://stats.wikimedia.org/v2/#/pl.wikipedia.org/contributing/active-editors/normal|line|2-year|~total|monthly and figure out certain trend in the development of the number active editors on a community mailing list.
If I send that link as-is, it seems to me that it will always refer to the "last 2 years" - so when viewed, say, a month later, the timelime will shift so the graph will not be the same.
When I set the fixed timeline (say Apr 2018 to Jan 2019) the URL changes to point only to that period (a permalink):
https://stats.wikimedia.org/v2/#/pl.wikipedia.org/contributing/active-editors/normal|line|2018-04-07~2019-01-01|~total|monthly
{M296}
There are two use cases:
# I want to link to the functionality of getting last two years worth of active users of pl.wikipedia
# I want to a particular dataset I am seeing
I think the second use case is more prevalent and should be how the URLs behave
Mastodon users have discussed various ways to create synergy between Wikimedia movement and the [[ https://en.wikipedia.org/wiki/Fediverse | Fediverse ]] (communities exchanging messages with [[ https://en.wikipedia.org/wiki/ActivityPub | ActivityPub ]] and [[ https://en.wikipedia.org/wiki/OStatus | OStatus protocol ]]).
Ideas considered include:
* [[ https://social.nasqueron.org/@Dereckson/99826123376816249 | Curated Wikimedia Commons feeds ]] such as [[ https://commons.wikimedia.org/wiki/Commons:Media_of_the_day | Media of the day ]] by @Dereckson
* [[ https://mastodon.technology/@danielhglus/100278498498332671 | Mastodon instance hosted by the Wikimedia Foundation ]] by @enterprisey
* .... federated login ....
* .... talk pages ...
Identi.ca/Status.Net:
{T42456}
{T24076}
{T52109}
{T34745}
{T22079}
When trying to import plmediawiki into PostgreSQL-run MW instance I get a warning:
````
Revision 65616 using content model Scribunto cannot be stored on "Moduł:Wykres" on this wiki, since that model is not supported on that page.
````
but the import continues. The reason is probably a different language code for the wiki.
Environment: importing into almost empty PostgreSQL MediaWiki 4d6439e343559944fb5e31c4f90760020ca4ce97
Import file: [[ https://dumps.wikimedia.org/plwikimedia/20170220/plwikimedia-20170220-pages-meta-current.xml.bz2 | plwikimedia-20170220-pages-meta-current.xml.bz2 ]]
When importing into almost empty PostgreSQL MediaWiki 4d6439e343559944fb5e31c4f90760020ca4ce97
Import file: [[ https://dumps.wikimedia.org/plwikimedia/20170220/plwikimedia-20170220-pages-meta-current.xml.bz2 | plwikimedia-20170220-pages-meta-current.xml.bz2 ]]
````
Query: INSERT INTO "user_newtalk" (user_ip,user_last_timestamp) VALUES ('83.21.68.80',NULL) Function: User::updateNewtalk Error: 23502 ERROR: null value in column "user_id" violates not-null constraint
````
````[bd13c3795c1bd2cd8ad2e8d4] [no req] DBQueryError from line 1060 of /usr/home/saper/public_html/pg/w/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: INSERT INTO "user_newtalk" (user_ip,user_last_timestamp) VALUES ('83.21.68.80',NULL)
Function: User::updateNewtalk
Error: 23502 ERROR: null value in column "user_id" violates not-null constraint
Backtrace:
#0 /usr/home/saper/public_html/pg/w/includes/libs/rdbms/database/DatabasePostgres.php(252): Database->reportQueryError(string, string, string, string, boolean)
#1 /usr/home/saper/public_html/pg/w/includes/libs/rdbms/database/Database.php(918): DatabasePostgres->reportQueryError(string, string, string, string, SavepointPostgres)
#2 /usr/home/saper/public_html/pg/w/includes/libs/rdbms/database/DatabasePostgres.php(634): Database->query(string, string, SavepointPostgres)
#3 /usr/home/saper/public_html/pg/w/includes/user/User.php(2370): DatabasePostgres->insert(string, array, string, string)
#4 /usr/home/saper/public_html/pg/w/includes/user/User.php(2423): User->updateNewtalk(string, string, Revision)
#5 /usr/home/saper/public_html/pg/w/includes/page/WikiPage.php(2284): User->setNewtalk(boolean, Revision)
#6 /usr/home/saper/public_html/pg/w/includes/import/WikiRevision.php(551): WikiPage->doEditUpdates(Revision, User, array)
#7 /usr/home/saper/public_html/pg/w/includes/import/WikiImporter.php(346): WikiRevision->importOldRevision()
#8 [internal function]: WikiImporter->importRevision(WikiRevision)
#9 /usr/home/saper/public_html/pg/w/maintenance/importDump.php(187): call_user_func(array, WikiRevision)
#10 [internal function]: BackupReader->handleRevision(WikiRevision, WikiImporter)
#11 /usr/home/saper/public_html/pg/w/includes/import/WikiImporter.php(483): call_user_func_array(array, array)
#12 /usr/home/saper/public_html/pg/w/includes/import/WikiImporter.php(905): WikiImporter->revisionCallback(WikiRevision)
#13 /usr/home/saper/public_html/pg/w/includes/import/WikiImporter.php(827): WikiImporter->processRevision(array, array)
....
````
When filing T147138 I noticed two issues with the user interface:
Here's a screenshot:
{F4545962, width=800}
# clicking on "Events", "Beta Features" lists me events from the page
# to report the bug, I tried to right click on the "Events", "Beta Features" and expected to have a link to those pages. Unfortunately, it is not a real link anywhere.
# "Beta Features" notification item was actually referring to "Talk:Beta Features". I think it should have been somehow reflected in the UI (naming the item "Talk:Beta Features", providing namespace textual description with an icon or whatever).
As it is in the case of the watchlist I sometimes prefer to jump directly to the target page especially if there is a larger (more than two) notifications for it. This way I can see the final outcome of the events and browse the history myself as I see fit.
So it is unclear to me if the link on the item should point to the particular list of the notification items (this is more consistent with the behaviour of the non-existing link when clicked).
At the same time there would be a way to directly jump to the affected page without going through the notifications first (a direct link).
(Apologies if this is a dupe, there are too many items on Notifications board to go through them). Most descriptions on the board are pretty technical and it is hard to follow if one does not know the actual implementation.
Today I got 4 notifications on mediawiki.org (I saw them first as 4 cross-wiki notifications on pl.wikipedia.org).
Screenshot of the Notifications page:
{F4545962, width=800}
Notifications on [[https://www.mediawiki.org/wiki/Events|Events]] (1 entry) and [[https://www.mediawiki.org/wiki/Talk:Beta_Features|Beta Features]] (3 entries) are real.
but there is an additional entry [[https://www.mediawiki.org/wiki/Manual:How to debug/de|Manual:How to debug/de]] with a count of one, when clicked says "There are no notifications matching this criteria".
Where does this dud notification comes from?
(I am pretty sure it's a dupe but I had difficulty doing through the Notifications board).
I run a test wiki at http://tools.wikimedia.pl/~saper/b/index.php running:
MediaWiki git master (https://phabricator.wikimedia.org/r/revision/mediawiki/core.git;d9b2cdabdc0a11344158d81ee45a91675a51e945)
Extension:Graphs (3af5fe8) + 2 patches (see below)
I have copied https://www.mediawiki.org/wiki/Extension:Graph/Demo/HistoricalFertilityRates example to the wiki and adjusted data source paths to wikiraw:///Fertility-csv and wikiraw:///WorldMap-iso3-json respectively.
Both data files have been copied from the mediawiki.org to the respective shortened names
http://tools.wikimedia.pl/~saper/b/index.php?title=Fertility-csv and http://tools.wikimedia.pl/~saper/b/index.php?title=WorldMap-iso3-json
(setup is the same as for T145944).
To workaround T145944 I have applied
Two patches applied:
* https://github.com/saper/mediawiki-extensions-Graph/commit/7985fd39623b345f9a446a8a59ecef240a748f97 - a crude workaround for T145944 in my setup
* https://github.com/saper/mediawiki-extensions-Graph/commit/9e4a1085c9646a2c08a4a83ba94d59fa713a419c - to log values.
I am getting errors on the console, since the extension is trying to parse country data:
````
Object { batchcomplete: true, query: Object } vega.js:3269:1
Object { batchcomplete: true, query: Object } vega.js:3270:1
"[Vega Err]" "PARSE DATA FAILED: countries TypeError: t.objects is undefined" vega.js:10714:2
"[Vega Err]" TypeError: t.objects is undefined
Stack trace:
[20]</reader@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/vega2/vega.js?235e1:3271:1
read@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/vega2/vega.js?235e1:3515:1
onLoad/<@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/vega2/vega.js?235e1:15246:37
dataParser@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/graph2.compiled.js?c3ebd:552:5
VegaWrapper/datalib.load.loader/cb@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/graph2.compiled.js?c3ebd:245:20
respond@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/vega2/vega.js?235e1:3432:7
vega.js:10714:2
TypeError: t.objects is undefined
Stack trace:
[20]</reader@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/vega2/vega.js?235e1:3271:1
read@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/vega2/vega.js?235e1:3515:1
onLoad/<@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/vega2/vega.js?235e1:15246:37
dataParser@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/graph2.compiled.js?c3ebd:552:5
VegaWrapper/datalib.load.loader/cb@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/graph2.compiled.js?c3ebd:245:20
respond@http://tools.wikimedia.pl/~saper/b/extensions/Graph/lib/vega2/vega.js?235e1:3432:7
graph2.compiled.js:95:6
````
I run a test wiki at http://tools.wikimedia.pl/~saper/b/index.php running:
* MediaWiki git master (https://phabricator.wikimedia.org/r/revision/mediawiki/core.git;d9b2cdabdc0a11344158d81ee45a91675a51e945)
* Extension:Graphs (3af5fe8)
I have copied https://www.mediawiki.org/wiki/Extension:Graph/Demo/HistoricalFertilityRates example to the wiki and adjusted data source paths to wikiraw:///Fertility-csv and wikiraw:///WorldMap-iso3-json respectively.
Both data files have been copied from the mediawiki.org to the respective shortened names http://tools.wikimedia.pl/~saper/b/index.php?title=Fertility-csv and http://tools.wikimedia.pl/~saper/b/index.php?title=WorldMap-iso3-json
However, I keep getting "Error: URL hostname is not whitelisted: wikiraw:///Fertility-csv" on the console.
Setting
$wgGraphAllowedDomains = [ 'wikiraw' => [ 'tools.wikimedia.pl' ] ];
wfLoadExtension( "Graph" );
does not seem to help.
When I have added
$wgGraphAllowedDomains = [ 'wikiraw' => [ 'tools.wikimedia.pl' ], 'http' => [ 'tools.wikimedia.pl' ] ];
I started getting XHR error, since it tried getting
http://tools.wikimedia.pl/w/api.php?format=json&formatversion=2&action=query&prop=revisions&rvprop=content&titles=Fertility-csv
(my wiki lives in a subdirectory).
What is a proper way to whitelist 'wikiraw' pseudo-protocol?
How can run the wiki in a subdirectory and still use the wikiraw protocol?
https://packagist.org/packages/mediawiki/vector-skin says the URL to the repo is https://git.wikimedia.org/git/mediawiki/skins/Vector.git
From T139206 :
I just run into this today by adding this to my `composer.local.json`:
````
{
"require": {
"mediawiki/vector-skin": "@dev"
}
}
````
It ends up with
````
[RuntimeException]
Failed to execute git clone --no-checkout 'https://git.wikimedia.org/git/mediawiki/skins/Vector.git' 'skins/Vector/' && cd 'skins/Vector/' && git remote add composer 'https://
git.wikimedia.org/git/mediawiki/skins/Vector.git' && git fetch composer
Cloning into 'skins/Vector'...
fatal: https://git.wikimedia.org/git/mediawiki/skins/Vector.git/info/refs not valid: is this a git repository?
````
When run on MediaWiki 1.26, the extension generates a warning:
```
Warning: OutputPage::getModuleStyles: style module should define its position explicitly:
ext.semanticforms.wikieditor ResourceLoaderFileModule
[Called from OutputPage::getModuleStyles
in /srv/data/www/root/w/includes/OutputPage.php at line 621]
in /srv/data/www/root/w/includes/debug/MWDebug.php on line 300
```
In order to run MediaWiki in the [authoritative repo mode](http://docs.hhvm.com/hhvm/advanced-usage/repo-authoritative) I need to tell HHVM about all PHP files that might possibly get required or included.
Currently I am just adding `*.lesscache` all files that happen to be in my `$wgCacheDirectory` but it would be better to have something more robust for automated production deployment.
Something like a maintenance script to do that would be great.
In order to workaround T121490 I have symlinked "vector" in the "skins" directory to "Vector".
The CLI installer went fine, but running `update.php` fails with
`Exception encountered, of type "InvalidArgumentException"`
The stacktrace:
````
[5323b2ec] [no req] InvalidArgumentException from line 88 of /usr/home/saper/public_html/collaps/includes/config/ConfigFactory.php: Invalid callback provided
Backtrace:
#0 /usr/home/saper/public_html/collaps/includes/config/ConfigFactory.php(59): ConfigFactory->register(string, array)
#1 /usr/home/saper/public_html/collaps/maintenance/doMaintenance.php(100): ConfigFactory::getDefaultInstance()
#2 /usr/home/saper/public_html/collaps/maintenance/update.php(214): require_once(string)
#3 {main}
````
What happens is that vector is added twice to `$wgConfigRegistry`:
````
array(2) {
["vector"]=>
array(2) {
[0]=>
string(28) "GlobalVarConfig::newInstance"
[1]=>
string(28) "GlobalVarConfig::newInstance"
}
["main"]=>
string(28) "GlobalVarConfig::newInstance"
}
````
MediaWiki core: 5b0ebd7f3a6e1c215a6af56d966ee14047a9b44f
Not sure if this is problem with composer installers or vector, here is what happens:
- get an empty clone of mediawiki core git master
- put this into `composer.local.json`:
{
"require": {
"mediawiki/vector-skin": "dev-master"
},
"minimal-stabilty": "dev"
}
- run `composer update`
- run the CLI installer to create LocalSettings.php
- add `$wgResourceLoaderDebug = true`
then the console alerts me that http://tools.wikimedia.pl/~saper/sf/skins/Vector/collapsibleTabs.js is 404.
There are skins that usually install into the lowercased directory, too.
MediaWiki core 5b0ebd7f3a6e1c215a6af56d966ee14047a9b44f
Composer version 1.0-dev ([1c525b76f81123af180743d31c208c29351cf931](https://github.com/composer/composer/tree/1c525b76f81123af180743d31c208c29351cf931)) 2015-12-09 15:47:26
skins/vector d09432a65f6183e9dbd2380ed51f447064deee12
composer/installers v1.0.22 [bd9b14f094c89c8b5804a4e41edeb7853bb85046](https://github.com/composer/installers/tree/bd9b14f094c89c8b5804a4e41edeb7853bb85046) - master a the moment
Steps taken:
git checkout of the MediaWiki core (bb3da3829714d17315986b517e5286d73cd2953e).
My `composer.local.json`:
````
{
"require": {
"mediawiki/semantic-forms": "3.3.2"
}
}
````
Ran `composer install` and after this
````
php -c "${HOME}/php.ini" maintenance/install.php --dbtype="mysql" --dbname=sf \
--dbuser=wikiuser --dbpass=${pass} \
--installdbuser=${iuser} --installdbpass=${ipass} \
--server http://tools.wikimedia.pl --scriptpath "${script}" \
--showexceptions=true --pass XXXX mysqltest WikiAdmin
````
The result:
````
Script started on Sat Dec 12 21:45:00 2015
PHP 5.6.9-pl0-gentoo is installed.
Warning: Could not find APC, XCache or WinCache.
Object caching is not enabled.
Found ImageMagick: /usr/bin/convert.
Image thumbnailing will be enabled if you enable uploads.
Found the Git version control software: /usr/bin/git.
Using server URL "http://tools.wikimedia.pl/trunk/w".
Warning: Your default directory for uploads (/usr/home/saper/public_html/sf/images/) is not checked for vulnerability
to arbitrary script execution during the CLI install.
Using the intl PECL extension for Unicode normalization.
The environment has been checked.
You can install MediaWiki.
Setting up database
done
Creating tables
done
Creating database user
done
Populating default interwiki table
done
Initializing statistics
done
Generating secret keys
done
Prevent running unneeded updates
done
Creating administrator user account
done
Creating main page with default content
Could not insert main page: Invalid callback SFFormUtils::purgeCache in hooks for ArticleSave
RC: 1
A copy of your installation's LocalSettings.php
must exist and be readable in the source directory.
Use --conf to specify it.
Script done on Sat Dec 12 21:45:38 2015
````
````
After upgrading a Wiki running MediaWiki 1.24.4 to 1.26 I am getting:
Uncaught ReferenceError: jQuery is not defined with action=formedit on MW 1.26
in the browser's developer console (Chrome 47 on Win 8.1)
This error points to the following line in the HTML:
````
<script>jQuery(function()(mw.loader.using("ext.semanticforms.wikieditor",function()(jQuery('#input_2')...
````
It seems that jQuery is not loaded here at this point, probably because of {T107399} (therefore related to T115692).
Not sure what is the right component to file this.
After T120216 we should prepare a nice composer.json and add the extension as `mediawiki/hitcounters` to packagist.org
Example:
access:
http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FSemanticMediaWiki.git/master/COPYING
clicking "raw" link takes me to:
http://git.wikimedia.org/raw/mediawiki/extensions/SemanticMediaWiki.git/master/COPYING
which generates
````
Error
Sorry, the repository mediawiki does not have a extensions branch!
````
(Follow up from plwiki's technical village pump [[https://pl.wikipedia.org/w/index.php?title=Wikipedia:Kawiarenka/Kwestie_techniczne&oldid=44017013#pl-PL|"pl-PL"]] )
A template generated in the automatic mode for page:
http://eurosport.onet.pl/piecioboj-nowoczesny/ms-w-piecioboju-brazowy-medal-polskiej-druzyny-mezczyzn/0445q5
receives `lang = pl-pl` language code.
We have modified our `{{cite web}}` template (https://pl.wikipedia.org/w/index.php?title=Modu%C5%82%3ALang&type=revision&diff=44015091&oldid=40741992) to accept this, but it looks like an incorrect language code.
The target page contains `<html lang="pl" ... ` opening tag.
Related to T114376, but worse:
Try to edit a page which consists only of links:
https://pl.wikipedia.org/wiki/Test?veaction=edit&lang=en
It is possible to move to the next link with a keyboard, but the link window is always on and impossible to dismiss.
(Feel free to dupe with T114376 if this is really the same issue)
I am editing via tor with the global IP block exemption on my account ( https://meta.wikimedia.org/wiki/Special:CentralAuth/Saper ) but if a range block is applied, local range blocks prevent editing:
Two examples:
* Site: en.wikipedia
* IPv4 address: 37.187.7.74
* editing https://en.wikipedia.org/w/index.php?title=Western_Armenian&action=edit§ion=12
* hitting 37.187.0.0/16 rangeblock https://en.wikipedia.org/wiki/Special:BlockList?wpTarget=37.187.7.74&limit=50
* Site: ru.wikipedia
* IPv4 address: 85.25.103.119
* editing https://ru.wikipedia.org/w/index.php?title=%D0%9C%D0%BE%D0%BB%D0%B4%D0%B0%D0%B6%D0%B0%D0%BD%D0%BE%D0%B2%D0%B0,_%D0%93%D1%83%D0%BB%D1%8C%D0%B6%D0%B0%D0%BD_%D0%A2%D0%B0%D0%BB%D0%B0%D0%BF%D0%BE%D0%B2%D0%BD%D0%B0&action=edit
* hitting 85.25.0.0/16 rangeblock #597773 : https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BE%D0%BA?wpTarget=85.25.103.119&limit=50&uselang=en
Today I have recognized that Vector tabs are shifted to the left and overlap the logo. Sometimes the logo is on top so clicking takes me to the home page.
Screenshot:
http://tools.wikimedia.pl/~saper/bugs/mw-overlap.png
(my browser does not seem to handle dropping files to create a mock very well)
This class is not used in core (but I maybe used somewhere else - it is designed to test dumps).
https://gerrit.wikimedia.org/r/#/c/4155/14/tests/phpunit/maintenance/fetchTextTest.php (line 69)
an attempt is being made to mock standard input by providing fopen'ed string.
A similar problem has been solved in https://phabricator.wikimedia.org/T75283 by providing a different string-based implementation for the common interface - this is not possible with command line tools.
Getting this failure on a Gentoo Linux box
Original report: https://lists.wikimedia.org/pipermail/wikitech-l/2015-October/083675.html
{P2235}
````
$d = iconv( "SEN_850200_B", "UTF-8//IGNORE", "ÃÃø" );
````
returns `false` here.
Code using "data://" URLs requires `allow_url_fopen` to be enabled, which is not required (and not very good in general for the production setup).
Can we make sure we run tests with this disabled?
I catched
https://gerrit.wikimedia.org/r/#/c/4155/14/tests/phpunit/maintenance/fetchTextTest.php (line 69)
and https://phabricator.wikimedia.org/T116701 today.
XMP parsing tests fail with `allow_url_fopen` disabled:
To reproduce within the library XMPReader:
```
git clone https://gerrit.wikimedia.org/r/mediawiki/libs/XMPReader.git
cd XMPReader
composer install
php vendor/bin/phpunit # succeeds
php -d allow_url_fopen vendor/bin/phpunit # fails
```
Sample failures in MediaWiki tests:
{P2234}
Example failure from https://lists.wikimedia.org/pipermail/wikitech-l/2015-October/083675.html:
```
1) ApiFormatPhpTest::testGeneralEncoding with data set #7 (array(1.0E+42), 'a:1:{i:0;d:1.0E+42;}', array(1))
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-a:1:{i:0;d:1.0E+42;}
+a:1:{i:0;d:1000000000000000044885712678075916785549312;}
/usr/home/saper/public_html/ybabel/tests/phpunit/includes/api/format/ApiFormatTestBase.php:61
/usr/home/saper/public_html/ybabel/tests/phpunit/MediaWikiTestCase.php:137
2) ApiFormatPhpTest::testGeneralEncoding with data set #30 (array(1.0E+42), 'a:1:{i:0;d:1.0E+42;}', array(2))
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-a:1:{i:0;d:1.0E+42;}
+a:1:{i:0;d:1000000000000000044885712678075916785549312;}
/usr/home/saper/public_html/ybabel/tests/phpunit/includes/api/format/ApiFormatTestBase.php:61
/usr/home/saper/public_html/ybabel/tests/phpunit/MediaWikiTestCase.php:137
```
The cause was running PHP with `serialize_precision` set to 100.
How to reproduce; using git master:
````
+ git -C . log --oneline -1
5c63cce Merge "ApiQueryAllRevisions: Actually use 'start' and 'end'"
+ git -C vendor log --oneline -1
5efd7d7 Update OOjs UI to v0.12.12
+ git -C skins/Vector log --oneline -1
9f5f333 Localisation updates from https://translatewiki.net.
````
After configuring the database connection select advanced options ("Ask me more questions") and hit "Continue".
Pick up the defaults ("No caching (no functionality is removed, but speed may be impacted on larger wiki sites)" among others ) and hit "Continue"
An unstyled screen appears:
```
Install
By pressing "Continue →", you will begin the installation of MediaWiki. If you still want to make changes, press "← Back".
```
Hit "Continue ->"
An unstyled page is generated with an exception:
```
MediaWiki 1.27alpha installation
Language
Existing wiki
Welcome to MediaWiki!
Connect to database
Upgrade existing installation
Database settings
Name
Options
Install
Complete!
Restart installation
Install
Setting up database... done
Creating tables...
[22dd363a] /~saper/ybabel/mw-config/index.php?page=Install MWException from line 123 of /usr/home/saper/public_html/ybabel/includes/objectcache/ObjectCache.php: Invalid object cache type "none" requested. It is not present in $wgObjectCaches.
Backtrace:
#0 /usr/home/saper/public_html/ybabel/includes/objectcache/ObjectCache.php(91): ObjectCache::newFromId(string)
#1 /usr/home/saper/public_html/ybabel/includes/objectcache/ObjectCache.php(307): ObjectCache::getInstance(string)
#2 /usr/home/saper/public_html/ybabel/includes/GlobalFunctions.php(3589): ObjectCache::getLocalClusterInstance()
#3 /usr/home/saper/public_html/ybabel/includes/db/DatabaseMysqlBase.php(690): wfGlobalCacheKey(string, string)
#4 /usr/home/saper/public_html/ybabel/includes/db/Database.php(3485): DatabaseMysqlBase->getApproximateLagStatus()
#5 /usr/home/saper/public_html/ybabel/includes/installer/DatabaseInstaller.php(192): DatabaseBase->begin(string)
#6 /usr/home/saper/public_html/ybabel/includes/installer/DatabaseInstaller.php(218): DatabaseInstaller->stepApplySourceFile(string, string, boolean)
#7 [internal function]: DatabaseInstaller->createTables(MysqlInstaller)
#8 /usr/home/saper/public_html/ybabel/includes/installer/Installer.php(1596): call_user_func(array, MysqlInstaller)
#9 /usr/home/saper/public_html/ybabel/includes/installer/WebInstallerPage.php(1407): Installer->performInstallation(array, array)
#10 /usr/home/saper/public_html/ybabel/includes/installer/WebInstaller.php(280): WebInstallerInstall->execute()
#11 /usr/home/saper/public_html/ybabel/mw-config/index.php(77): WebInstaller->execute(array)
#12 /usr/home/saper/public_html/ybabel/mw-config/index.php(36): wfInstallerMain()
#13 {main}
```
Generated LocalSettings.php include:
````
$wgLogo = "$wgResourceBasePath/resources/assets/wiki.png";
````
but `$wgResourceBasePath` is not defined anywhere. I think https://gerrit.wikimedia.org/r/#/c/235263 might have broken this.
Change affected:
https://gerrit.wikimedia.org/r/#/c/11562/26
Error message from HHVM build (fine on Zend):
`Fatal error: unknown class CheckUserBase in /mnt/jenkins-workspace/workspace/mediawiki-extensions-hhvm/src/extensions/CheckUser/specials/SpecialCheckUser.php on line 3`
{P2221, highlight=785}
The `CheckUserBase` class seems to be added to the autoloader properly.
When running 1.27 alpha (currently [[https://git.wikimedia.org/tree/mediawiki%2Fcore.git/0158312d4bc3de9c15064a12a73b4bf57580e45e|0158312d4bc3de9c15064a12a73b4bf57580e45e]]) I always get "Create account" and "Log in" with pretty standard LocalSettings.php and also when setting `$wgShowIPinHeader = true` explicitly.
Having applied the following patch:
````diff
diff --git a/includes/skins/Skin.php b/includes/skins/Skin.php
index 12ebb54..6850f6a 100644
--- a/includes/skins/Skin.php
+++ b/includes/skins/Skin.php
@@ -730,7 +730,10 @@ abstract class Skin extends ContextSource {
*/
function showIPinHeader() {
global $wgShowIPinHeader;
- return $wgShowIPinHeader && session_id() != '';
+ wfDebugLog( __METHOD__, '$wgShowIPinHeader is ' . var_export( $wgShowIPinHeader, true ) );
+ $what = $wgShowIPinHeader && session_id() != '';
+ wfDebugLog( __METHOD__, "but returning " . var_export( $what, true ) );
+ return $what;
}
/**
````
I can see in the debug log the following when asking for http://tools.wikimedia.pl/~saper/y/index.php?title=Main_Page&action=edit
````
[Skin::showIPinHeader] $wgShowIPinHeader is true
[Skin::showIPinHeader] but returning false
[Skin::showIPinHeader] $wgShowIPinHeader is true
[Skin::showIPinHeader] but returning false
[Skin::showIPinHeader] $wgShowIPinHeader is true
[Skin::showIPinHeader] but returning false
````
It seems to me that [[https://git.wikimedia.org/blob/operations%2Fmediawiki-config.git/ab9b1c9e455d3aa7b71e29f5b88cf2faf3acd261/wmf-config%2FFeaturedFeedsWMF.php|FeaturedFeedsWMF.php]] and maybe others (HHVMRequestInit.php ?) are not available for viewing via http://noc.wikimedia.org/conf
If any API URL will be convertable to a feed in the future, how is the `wltoken` special? Should it become a "generic" API authentication method applicable to all modules (and maybe formats?).
In some cases (see T92469) a private wiki might want to give out tokens for RecentChanges etc.
Example:
If I set `$wgFeed=false` and try to access:
http://tools.wikimedia.pl/~saper/y/api.php?hidebots=1&days=7&limit=50&action=feedrecentchanges&feedformat=rss
I get:
````
HTTP/1.1 200 OK
Date: Wed, 21 Oct 2015 12:46:14 GMT
Server: Apache
X-Content-Type-Options: nosniff
MediaWiki-API-Error: feed-unavailable
X-Frame-Options: DENY
Content-language: pl,en
X-UA-Compatible: IE=Edge
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Content-Length: 4090
Connection: close
Content-Type: text/html; charset=UTF-8
````
with HTML-ized json response
````{
"error": {
"code": "feed-unavailable",
"info": "Syndication feeds are not available",
"*": "See http://tools.wikimedia.pl/~saper/y/api.php for API usage"
}
}````
But when I try to access watchlist feed:
http://tools.wikimedia.pl/~saper/y/api.php?action=feedwatchlist&allrev=1&wlowner=WikiAdmin&wltoken=0daccf797b431d3151e6026f2e066d8cb709fad8&feedformat=rss
I get
````
HTTP/1.1 200 OK
Date: Wed, 21 Oct 2015 12:48:38 GMT
Server: Apache
X-Content-Type-Options: nosniff
Vary: Accept-Encoding,Cookie
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate, max-age=0
Content-Length: 613
Connection: close
Content-Type: application/xml; charset=UTF-8
Content-Language: pl
````
with an RSS-formatted item with an error message.
I think we should send a proper HTTP error code (403 or something like that) and the XML message that RSS readers might interpret.
If `$wgFeed` is false we generate links to feeds that cause `feed-unavailable` error.
Pretty default MediaWiki installation running git 1.27alpha (dd5a887).
Debug log tells us we try to set cookie when sending internal request to the job queue:
````
[runJobs] refreshLinks Template:Documentation pages=array(1) rootJobSignature=d11df2eab71de9ae9409a4b2c5aeff5079cf9b99 rootJobTimestamp=20151013185830 masterPos= (id=19,timestamp=20151013190051) t=179 good
MediaWiki::doPreOutputCommit completed; all transactions committed
[cookie] setcookie: "blenderwikiUseDC", "master", "1444772280", "/", "", "", "1"
[error] [a92b0b3e] /~saper/b/index.php?title=Special%3ARunJobs&tasks=jobs&maxjobs=1&sigexpiry=1444772274&signature=53ee4a7d4a19ebc8f791062ab1f5986ae6a4f381 ErrorException from line 136 of /usr/home/saper/public_html/b/includes/WebResponse.php: PHP Warning: Cannot modify header information - headers already sent
#0 [internal function]: MWExceptionHandler::handleError(integer, string, string, integer, array)
#1 [internal function]: setcookie(string, string, integer, string, string, boolean, boolean)
#2 /usr/home/saper/public_html/b/includes/WebResponse.php(136): call_user_func(string, string, string, integer, string, string, boolean, boolean)
#3 /usr/home/saper/public_html/b/includes/MediaWiki.php(512): WebResponse->setCookie(string, string, integer)
#4 /usr/home/saper/public_html/b/includes/MediaWiki.php(674): MediaWiki->doPreOutputCommit()
#5 /usr/home/saper/public_html/b/includes/MediaWiki.php(475): MediaWiki->main()
#6 /usr/home/saper/public_html/b/index.php(41): MediaWiki->run()
#7 {main}
Request ended normally
[caches] main: Memcached
````
Introduced by 0a1c04beae41a7fe6f57152dfd7c0bc9261528e0
I was importing
https://svn.blender.org/svnroot/blend-doc/trunk/wiki/mediawiki/wiki.blender.org/imports/templates/Templates-Page.xml
and got:
```
PHP Fatal error: Call to a member function getNamespace() on null in /usr/home/saper/public_html/b/extensions/DynamicPageList/DPLMain.php on line 2613
<div class="php-error">
Fatal error: Call to a member function getNamespace() on null in /usr/home/saper/public_html/b/extensions/DynamicPageList/DPLMain.php on line 2613
<span onclick="$(this).parent().hide();">Dismiss</span>
</div>
````
Getting this when running maintenance/importDump and importing this file:
https://svn.blender.org/svnroot/blend-doc/trunk/wiki/mediawiki/wiki.blender.org/imports/templates/Templates-Page.xml
I got this today because my $wgTmpDirectory did not exist (I was installing from Git and using the command line installer).
It would be great to have a bit better error message here (which directory?), and possibly some advice about getting the temp directory right if possible.
Big thanks to @ori for a hint on IRC.
== Steps to reproduce
# Open "W" menu, "Więcej..." (more...) at the bottom
# Select "Przeszukaj $ Wikipedię" (Search $ Wikipedia)
# Select search icon
# Type "Wikipedysta:Saper"
# A list of "Czytaj więcej" ("Read more...") appears
# Select [[ https://pl.wikipedia.org/wiki/Wikipedysta:Saper/Obrazki.js | Wikipedysta:Saper/Obrazki.js ]]
# Press the pencil button on the upper right hand corner
== Expected results
Some form of editing
== Actual results
Error message:
There is no section 0 in r8717465
Listinfo https://lists.wikimedia.org/mailman/listinfo/wikimediapl-l is served by the server as ISO 8859-2 but contains:
1) <meta charset="utf-8"> header
2) mostly UTF-8 free text
3) some strangely mangled ISO 8859-2 messages
therefore some characters (especially in the form) are displayed incorrectly.
{P1979, highlight=8,9,11,14,15}
Lines 8, 9, 11 contain `C5 BC` ('ż'), `C4 85` ('ą'), `C3 B3` ('ó') which are correct.
Lines 14 and 15 have `C4 B9 C2 9B` (should be "ś")
and `C3 84 C2 87` (should be "ć") which are badly encoded.
Try to insert a link in a visual mode of Flow:
1. Invoke popup with `[[`
2. Find some page and press "Insert a link"
3. The link gets inserted (the link text is underlined and blue)
4. Press space and continue typing after the link normally
5. Save the comment
What happens after steps 4 and 5:
4a. The text typed after the link is also underlined and blue and seems to be the extension of the link text
5a. However, once saved - things look as expected - the link text only grows during preview
Browser:
Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Firefox/38.0
I just tried adding a link on one of the Polish Wikipedia test flow page (http://pl.wikipedia.org/wiki/Dyskusja_Wikipedii:Flow/) and the "Insert a link" wikitext shortcut ([[) is too slow:
1) Open a comment/thread
2) Try to type text fast
3) Type `[[Special:Block`
4) A linking popup appears but only `cial:Block` is entered into the linking field. Letters `Spe` are lost.
This is just too slow for power users.
Browser:
```
Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Firefox/38.0
```
There is a [[https://pl.wikisource.org/wiki/MediaWiki:Gadget-proofread-history.js|proofread history gadget]] that parses the revision text one-by-one and extracts the page level from the tag. This could have probably been achieved via the API call.
I run my bots in a fairly constrained and controlled environment (minimal software configuration, constrained permissions and network traffic) and I am running into problems like pywikibot trying to guess the version number.
I have proposed a Gerrit change to [override User-Agent](https://gerrit.wikimedia.org/r/#/c/208842/). Apparently `pywikibot-core` has a `config.user_agent_format` feature but it does not prevent auto-discovery of the bot version.
Overriding User-Agent is not enough since there may be more features checking the version, one of them is `writeToCommandLogFile()` (see also {T98106}).
When git is not available, it tries to fetch the irrelevant changelog, as I usually have some local patches/commits in the code. (Fetching also fails with {T98104}).
This feature is just not robust enough in my experience.
Having configured pywikibot with python `logging` module there is little need for this feature.
This feature insists on checking pywikibot version which may cause problems like inability to locate `git` or lack of SSL certificate for tools.wmflabs.org {T98104}.
It should be optional (config entry?)
`ssl` module may need strict checking:
````
m> env PATH= /usr/local/bin/python2.7 version.py
Retreving commit log from https://tools.wmflabs.org/pywikibot/gitlog.txt
Traceback (most recent call last):
File "version.py", line 20, in <module>
pywikibot.output('Pywikibot: %s' % getversion())
File "/home/saper/wikipedia/compat/pywikibot/version.py", line 46, in getversion
data = dict(getversiondict()) # copy dict to prevent changes in 'chache'
File "/home/saper/wikipedia/compat/pywikibot/version.py", line 70, in getversiondict
(tag, rev, date, hsh) = getversion_git(_program_dir)
File "/home/saper/wikipedia/compat/pywikibot/version.py", line 192, in getversion_git
rev, date = getversion_git_windows(hsh, path)
File "/home/saper/wikipedia/compat/pywikibot/version.py", line 111, in getversion_git_windows
ff = urllib2.urlopen(url).read().splitlines()
File "/usr/local/lib/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/usr/local/lib/python2.7/urllib2.py", line 431, in open
response = self._open(req, data)
File "/usr/local/lib/python2.7/urllib2.py", line 449, in _open
'_open', req)
File "/usr/local/lib/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/usr/local/lib/python2.7/urllib2.py", line 1240, in https_open
context=self._context)
File "/usr/local/lib/python2.7/urllib2.py", line 1197, in do_open
raise URLError(err)
urllib2.URLError: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)>
````
Workaround: [list of certificate authorities you trust](http://curl.haxx.se/ca/cacert.pem) `SSL_CERT_FILE`
I think SSL certificates could/should be supplied attached to the family files, not sure where else do we connect to (tools.wmflabs.org, anything else?...)
wfDebugLog() messages in the $wgDebugLog file are lacking time indications. It has neither date-timestamps (like the mediawiki error log file would), nor +0.01ms offset information (like profiling would).
This applies to the wgDebugToolbar feature as well.
From my newest PHPUnit run:
fix', 'Ex', array('Example', 'Example/Baz', 'Example Bar')))
Main namespace with title prefix
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
0 => 'Example'
- 1 => 'Example/Baz'
- 2 => 'Example Bar'
+ 1 => 'Example Bar'
+ 2 => 'Example/Baz'
)
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/Constraint/IsEqual.php:170
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/Assert.php:2134
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/Assert.php:475
/usr/home/saper/public_html/pg/w/tests/phpunit/includes/PrefixSearchTest.php:138
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:976
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:831
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestResult.php:648
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:776
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiTestCase.php:141
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:775
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:745
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:705
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:705
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:705
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/TestRunner.php:349
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/Command.php:176
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/Command.php:129
/usr/share/php/phpunit/phpunit.phar:531
Freshly installed empty wiki via the commandline installer
--------------------------
**Version**: 1.25-git
**Severity**: normal
--------------------------
**Version**: 1.25-git
**Severity**: normal
Here's my output:
Time: 2 seconds, Memory: 51.00Mb
There were 2 failures:
1) SpecialPageTest::testInvalidGetTitleFor
Failed asserting that exception of type "PHPUnit_Framework_Error_Notice" is thrown.
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/Constraint.php:144
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/Constraint.php:91
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/Assert.php:2134
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:1036
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:831
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestResult.php:648
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:776
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiTestCase.php:141
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:775
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:745
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/TestRunner.php:349
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/Command.php:176
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/Command.php:129
/usr/share/php/phpunit/phpunit.phar:531
2) SpecialPageTest::testGetTitleForWithWarning with data set #0 (Special:UserLogin, 'UserLogin')
Failed asserting that exception of type "PHPUnit_Framework_Error_Notice" is thrown.
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/Constraint.php:144
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/Constraint.php:91
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/Assert.php:2134
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:1036
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:831
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestResult.php:648
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:776
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiTestCase.php:141
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:775
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:745
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:705
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/TestRunner.php:349
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/Command.php:176
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/Command.php:129
/usr/share/php/phpunit/phpunit.phar:531
Might be PostgreSQL-related, of course...
--------------------------
**Version**: 1.25-git
**Severity**: normal
2) ImportTest::testHandlePageContainsRedirect with data set #1 ('<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.9/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.9/ http://www.mediawiki.org/xml/export-0.9.xsd" version="0.9" xml:lang="en">
<page>
<title>Test</title>
<ns>0</ns>
<id>42</id>
<revision>
<id>421</id>
<timestamp>2014-05-27T11:00:00Z</timestamp>
<contributor>
<username>Admin</username>
<id>10</id>
</contributor>
<text xml:space="preserve" bytes="4">Abcd</text>
<sha1>n7uomjq96szt60fy5w3x7ahf7q8m8rh</sha1>
<model>wikitext</model>
<format>text/x-wiki</format>
</revision>
</page>
</mediawiki>', NULL)
MWException: Cannot create InputStreamSource.
/usr/home/saper/public_html/pg/w/tests/phpunit/includes/ImportTest.php:16
/usr/home/saper/public_html/pg/w/tests/phpunit/includes/ImportTest.php:28
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:976
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:831
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestResult.php:648
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestCase.php:776
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiTestCase.php:141
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:775
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:745
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:705
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:705
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/Framework/TestSuite.php:705
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/TestRunner.php:349
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/Command.php:176
phar:///usr/share/php/phpunit/phpunit.phar/PHPUnit/TextUI/Command.php:129
/usr/share/php/phpunit/phpunit.phar:531
May be related to bug 72214, but that's a different message
--------------------------
**Version**: 1.25-git
**Severity**: normal
I just tried to upload
http://tools.wikimedia.pl/~odder/whitehouse/41d5129de542285b6c62.webm
using https://commons.wikimedia.org/wiki/Special:Upload as well as via API
(I have "upload_by_url" userright enabled).
Request URL:
https://commons.wikimedia.org/w/api.php?action=upload&format=json
POST data from API sandbox:
filename=Test%20test.webm&comment=Test%20bug%2072897&url=http%3A%2F%2Ftools.wikimedia.pl%2F~odder%2Fwhitehouse%2F41d5129de542285b6c62.webm&token=d27ea41fb633146835d1a2d1e962f37e545f9bd9%2B%5C
Result:
{
"servedby": "mw1139",
"error": {
"code": "http-bad-status",
"info": "Error fetching file from remote source",
"0": "403",
"1": "Forbidden",
"*": "See https://commons.wikimedia.org/w/api.php for API usage"
}
}
Log entry on the tools.wikimedia.pl server:
tools.wikimedia.pl 208.80.xxx.yyy - - [09/Nov/2014:18:03:30 +0100] "GET /~odder/whitehouse/41d5129de542285b6c62.webm HTTP/1.1" 200 932365538 "-" "MediaWiki/1.25wmf6"
so MediaWiki gets 200 from the origin server
--------------------------
**Version**: 1.25-git
**Severity**: normal
**URL**: https://commons.wikimedia.org/w/api.php?action=upload&format=json
OAuth uploads get logged under the toolserver IP address, impacting (among others) CheckUser
--------------------------
**Version**: unspecified
**Severity**: critical
After running:
php -c "${HOME}/php.ini" maintenance/install.php --dbtype="postgres" --dbname=${db} \
--dbuser=wikiuser --dbpass=${pass} \
--installdbuser=*someuser* --installdbpass=*somepassword* \
--server http://tools.wikimedia.pl --scriptpath "${script}" \
--showexceptions=true --pass test postgrestest WikiAdmin
a wiki installs fine, but the first invocation of /w/index.php gives:
(Cannot contact the database server: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied Is the server running locally and accepting connections on Unix domain socket "/run/postgresql/.s.PGSQL.5432"?)
Backtrace:
#0 w/includes/db/Database.php(822): DatabasePostgres->open('', 'wikiuser', '*pass*', '*database*')
#1 w/includes/db/Database.php(919): DatabaseBase->__construct(Array)
#2 w/includes/db/LoadBalancer.php(717): DatabaseBase::factory('postgres', Array)
#3 w/includes/db/LoadBalancer.php(591): LoadBalancer->reallyOpenConnection(Array, false)
#4 w/includes/db/LoadBalancer.php(471): LoadBalancer->openConnection(0, false)
#5 w/includes/GlobalFunctions.php(3618): LoadBalancer->getConnection(-1, Array, false)
#6 w/includes/page/WikiPage.php(379): wfGetDB(-1)
#7 w/includes/page/WikiPage.php(462): WikiPage->loadPageData()
#8 w/includes/page/WikiPage.php(515): WikiPage->exists()
#9 w/includes/page/WikiPage.php(222): WikiPage->getContentModel()
#10 w/includes/page/WikiPage.php(208): WikiPage->getContentHandler()
#11 w/includes/actions/Action.php(96): WikiPage->getActionOverrides()
#12 w/includes/actions/Action.php(149): Action::factory('view', Object(WikiPage), Object(RequestContext))
#13 w/includes/MediaWiki.php(164): Action::getActionName(Object(RequestContext))
#14 w/includes/MediaWiki.php(533): MediaWiki->getAction()
#15 w/includes/MediaWiki.php(460): MediaWiki->main()
#16 w/index.php(46): MediaWiki->run()
#17 {main}
LocalSettings.php include:
$wgDBtype = "postgres";
$wgDBserver = "";
$wgDBname = "*dbname*";
Running the installer with explicit --dbserver=localhost
php -c "${HOME}/php.ini" maintenance/install.php --dbtype="postgres" --dbname=${db} \
--dbuser=wikiuser --dbpass=${pass} \
--dbserver=localhost \
--installdbuser=*user* --installdbpass=*pass* \
--server http://tools.wikimedia.pl --scriptpath "${script}" \
--showexceptions=true --pass test postgrestest WikiAdmin
Seems to create LocalSettings.php with
Now LocalSettings.php include:
$wgDBtype = "postgres";
$wgDBserver = "localhost";
$wgDBname = "*dbname*";
which indicates this is probably another intstance of bug 69291
--------------------------
**Version**: 1.24rc
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=70223
On a freshly installed PostgreSQL wiki I had a problem with the database connection:
```
## Database settings
$wgDBtype = "postgres";
$wgDBserver = "";
$wgDBname = "clitest01";
$wgDBuser = "wikiuser";
$wgDBpassword = "*passwd*";
```
Installation went fine but those settings didn't work for some reason (this is another bug).
Wiki reports only:
> Sorry! This site is experiencing technical difficulties.
> Try waiting a few minutes and reloading.
> (Cannot contact the database server: No database connection)
> Backtrace:
> ```
>
> #0 w/includes/db/LoadBalancer.php(752): DatabaseBase->reportConnectionError('Unknown error (...')
> #1 w/includes/db/LoadBalancer.php(475): LoadBalancer->reportConnectionError()
> #2 w/includes/GlobalFunctions.php(3618): LoadBalancer->getConnection(-1, Array, false)
> #3 w/includes/page/WikiPage.php(379): wfGetDB(-1)
> #4 w/includes/page/WikiPage.php(462): WikiPage->loadPageData()
> #5 w/includes/page/WikiPage.php(515): WikiPage->exists()
> #6 w/includes/page/WikiPage.php(222): WikiPage->getContentModel()
> #7 w/includes/page/WikiPage.php(208): WikiPage->getContentHandler()
> #8 w/includes/actions/Action.php(96): WikiPage->getActionOverrides()
> #9 w/includes/actions/Action.php(149): Action::factory('view', Object(WikiPage), Object(RequestContext))
> #10 w/includes/MediaWiki.php(164): Action::getActionName(Object(RequestContext))
> #11 w/includes/MediaWiki.php(533): MediaWiki->getAction()
> #12 w/includes/MediaWiki.php(460): MediaWiki->main()
> #13 w/index.php(46): MediaWiki->run()
> #14 {main}
> ```
After commenting out the "ugly hack" in LoadBalancer::reallyOpenConnection() I am getting a real cause for the problem:
> (Cannot contact the database server: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Permission denied Is the server running locally and accepting connections on Unix domain socket "/run/postgresql/.s.PGSQL.5432"?)
>
> Backtrace:
> ```
> #0 w/includes/db/Database.php(822): DatabasePostgres->open('', 'wikiuser', 'minitest', 'clitest01')
> #1 w/includes/db/Database.php(919): DatabaseBase->__construct(Array)
> #2 w/includes/db/LoadBalancer.php(717): DatabaseBase::factory('postgres', Array)
> #3 w/includes/db/LoadBalancer.php(591): LoadBalancer->reallyOpenConnection(Array, false)
> #4 w/includes/db/LoadBalancer.php(471): LoadBalancer->openConnection(0, false)
> #5 w/includes/GlobalFunctions.php(3618): LoadBalancer->getConnection(-1, Array, false)
> #6 w/includes/page/WikiPage.php(379): wfGetDB(-1)
> #7 w/includes/page/WikiPage.php(462): WikiPage->loadPageData()
> #8 w/includes/page/WikiPage.php(515): WikiPage->exists()
> #9 w/includes/page/WikiPage.php(222): WikiPage->getContentModel()
> #10 w/includes/page/WikiPage.php(208): WikiPage->getContentHandler()
> #11 w/includes/actions/Action.php(96): WikiPage->getActionOverrides()
> #12 w/includes/actions/Action.php(149): Action::factory('view', Object(WikiPage), Object(RequestContext))
> #13 w/includes/MediaWiki.php(164): Action::getActionName(Object(RequestContext))
> #14 w/includes/MediaWiki.php(533): MediaWiki->getAction()
> #15 w/includes/MediaWiki.php(460): MediaWiki->main()
> #16 w/index.php(46): MediaWiki->run()
> #17 {main}
> ```
... which is some pg-specific installer problem we are working on it now.
--------------------------
**Version**: 1.24rc
**Severity**: major
**See Also**: {T72225}
After a fresh install (using maintenance/install.php command line installer on PostgreSQL) my new wiki greets me with a message:
Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available.
Your installation seems to include the following skins. See Manual: Skin configuration for information how to enable them and choose the default.
vector / Vector (disabled)
If you have just installed MediaWiki
You probably installed from git, or directly from the source code using some other method. This is expected. Try installing some skins from mediawiki.org's skin directory, by:
Downloading the tarball installer, which comes with several skins and extensions. You can copy and paste the skins/ directory from it.
Cloning one of the mediawiki/skins/* repositories via git into the skins/ directory of your MediaWiki installation.
Doing this should not interfere with your git repository if you're a MediaWiki developer.
If you have just upgraded MediaWiki
MediaWiki 1.24 and newer no longer automatically enables installed skins (see Manual: Skin autodiscovery). You can paste the following lines into LocalSettings.php to enable all currently installed skins:
require_once "$IP/skins/Vector/Vector.php";
If you have just modified LocalSettings.php
Double-check the skin names for typos.
Here is my "skins" directory:
$ ls -al skins/
total 20
drwxr-xr-x 3 saper wheel 4096 Aug 31 01:22 .
drwxr-xr-x 15 saper wheel 4096 Aug 31 01:52 ..
drwxr-xr-x 3 saper wheel 4096 Aug 31 01:22 common
-rw-r--r-- 1 saper wheel 26 Aug 31 01:22 .gitignore
-rw-r--r-- 1 saper wheel 1160 Aug 31 01:22 README
lrwxrwxrwx 1 saper wheel 31 Aug 31 00:27 Vector ->
../../../../gerrit/skins/Vector
$ ls -l skins/Vector/Vector.php
-rw-r--r-- 1 saper wheel 3857 Aug 26 21:36 skins/Vector/Vector.php
Actually, since I7b8bd77f5868af2ccf464e48db771f2e8e0472ff (https://gerrit.wikimedia.org/r/#/c/156440/) Vector skins worked in my installer
fine, but after the installation it fails badly.
Should this line:
require_once "$IP/skins/Vector/Vector.php";
be added automatically by the installer? Where does autodiscovery belong now?
https://www.mediawiki.org/wiki/Manual:Skin_autodiscovery promises:
The bundled skins which come with MediaWiki (like Vector or MonoBook) will continue to be updated with the MediaWiki Core. When you upgrade your installation to MediaWiki 1.24 or newer, you will also get a new version of these skins. (You should then remove the old copies from the skins/ folder, see Manual:Upgrading#Files remaining that may cause errors.)
... but this no longer seems true...
--------------------------
**Version**: 1.24rc
**Severity**: major
I would propose adding two components:
* "Wikimedia/PDF Rendering" (or "Mediawiki extensions/PDF Rendering") for the new renderer
* "Wikimedia/mwlib PDF Rendering" (or "Mediawiki extension/mwlib PDF Rendering") for the old mwlib-based one (to recategorize bugs).
I would like to have bugs related to the "Collection" extension only to be keep separated from rendering issues.
The reason is I am still willing to help with the extension itself (the bookmarking tool), and sometimes I can help with the mwlib renderer
(running one for myself), but not necessarily with the new one.
Therefore I'd like to be on default CC list for "Collection" only, if possible.
--------------------------
**Version**: wmf-deployment
**Severity**: normal
Tracking bug to understand MWTimestamp::getHumanTimestamp() should really do.
Additionally this function can be hooked (as it is done by Extension:CLDR) and
it is difficult to predict what should be its expected output.
--------------------------
**Version**: unspecified
**Severity**: normal
**See also**: {T69959}
**Whiteboard**: leteam?
We got an example of the user which has last edit (proper contribution) few months ago, but there are entries in the FlaggedRevs review log which indicate the user is reviewing changes.
When doing "get IP addresses" or "get edits" the message is shown:
> No matches found. Last edit was on 5 January 2014 at XX:YY.
Either FlaggedRevs is not logging to CheckUser or CU query is broken. Need to recreate the case on the test wiki.
Filing under "Extension:CheckUser" for now unless proven innocent.
All bugs related to effects with 127.0.0.1 IP address being used for various automated tasks.
--------------------------
**Version**: 1.23.0
**Severity**: normal
After applying I326bb4a189bf881299b9fb678033a927b916efac (a crude but working way to work around bug 37702 and have database constraints on the database during unit testing), BlockTest fails twice:
1) BlockTest::testBlockedUserCanNotCreateAccount
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php afte
r upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: COMMIT
Function: DatabaseBase::commit
Error: 23503 ERROR: insert or update on table "unittest_ipblocks" violates foreign key constr
aint "ut_ipblocks_ipb_user_fkey"
DETAIL: Key (ipb_user)=(14146) is not present in table "unittest_mwuser".
/usr/home/saper/test/mytest/includes/db/Database.php:1111
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:511
/usr/home/saper/test/mytest/includes/db/Database.php:1077
/usr/home/saper/test/mytest/includes/db/Database.php:3477
/usr/home/saper/test/mytest/includes/db/Database.php:3462
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:241
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:884
/usr/home/saper/test/mytest/includes/Block.php:475
/usr/home/saper/test/mytest/tests/phpunit/includes/BlockTest.php:177
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:115
2) BlockTest::testCrappyCrossWikiBlocks
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: COMMIT
Function: DatabaseBase::commit
Error: 23503 ERROR: insert or update on table "unittest_ipblocks" violates foreign key constraint "ut_ipblocks_ipb_user_fkey"
DETAIL: Key (ipb_user)=(14146) is not present in table "unittest_mwuser".
/usr/home/saper/test/mytest/includes/db/Database.php:1111
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:511
/usr/home/saper/test/mytest/includes/db/Database.php:1077
/usr/home/saper/test/mytest/includes/db/Database.php:3477
/usr/home/saper/test/mytest/includes/db/Database.php:3462
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:241
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:884
/usr/home/saper/test/mytest/includes/Block.php:475
/usr/home/saper/test/mytest/tests/phpunit/includes/BlockTest.php:229
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase./usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:115
php:123
Looks like the user ID 14146 is not fully in the database when the transaction is committed (we are using DEFERRED contraints so they are checked at commit, not immediately).
I have tried some simple ways to work around this and managed only fix
BlockTest::testCrappyCrossWikiBlocks by reordering calls.
--------------------------
**Version**: 1.23.0
**Severity**: normal
After enabling foreign key constraints on the database (see I326bb4a189bf881299b9fb678033a927b916efac) LinksTestUpdate gives 7 errors.
This is because wikipage content is created in memory only, why LinksUpdate attempts to operate on the database as well.
PostgreSQL in the current setup uses DEFERRED constraints, that means that all references are checked at commit time, allowing various operations in the meantime not immediately conforming to the constraints.
Sometimes fixings this kind of problem is trivial (see example at I653a8bccdaa748a9bea453cd1dbf609a30e1ff6f), but LinksUpdateTest makes it more
difficult because it attempts to use begin() and commit() in the middle
of the test.
7 errors:
1) LinksUpdateTest::testUpdate_pagelinks
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php after upgrad
ing? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: COMMIT
Function: DatabaseBase::commit
Error: 23503 ERROR: insert or update on table "unittest_pagelinks" violates foreign key constraint "u
t_pagelinks_pl_from_fkey"
DETAIL: Key (pl_from)=(111) is not present in table "unittest_page".
/usr/home/saper/test/mytest/includes/db/Database.php:1111
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:511
/usr/home/saper/test/mytest/includes/db/Database.php:1077
/usr/home/saper/test/mytest/includes/db/Database.php:3477
/usr/home/saper/test/mytest/includes/db/Database.php:3462
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:241
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:884
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:334
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:162
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:151
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:193
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:68
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:115
2) LinksUpdateTest::testUpdate_externallinks
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: COMMIT
Function: DatabaseBase::commit
Error: 23503 ERROR: insert or update on table "unittest_externallinks" violates foreign key constraint "ut_externallinks_el_from_fkey"
DETAIL: Key (el_from)=(111) is not present in table "unittest_page".
(...)
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:334
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:178
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:151
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:193
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:102
(...)
3) LinksUpdateTest::testUpdate_categorylinks
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: COMMIT
Function: DatabaseBase::commit
Error: 23503 ERROR: insert or update on table "unittest_categorylinks" violates foreign key constraint "ut_categorylinks_cl_from_fkey"
DETAIL: Key (cl_from)=(111) is not present in table "unittest_page".
(...)
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:334
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:201
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:151
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:193
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:117
(...)
4) LinksUpdateTest::testUpdate_templatelinks
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: COMMIT
Function: DatabaseBase::commit
Error: 23503 ERROR: insert or update on table "unittest_templatelinks" violates foreign key constraint "ut_templatelinks_tl_from_fkey"
DETAIL: Key (tl_from)=(111) is not present in table "unittest_page".
/usr/home/saper/test/mytest/includes/db/Database.php:1111
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:511
/usr/home/saper/test/mytest/includes/db/Database.php:1077
/usr/home/saper/test/mytest/includes/db/Database.php:3477
/usr/home/saper/test/mytest/includes/db/Database.php:3462
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:241
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:884
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:334
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:193
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:151
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:193
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:144
5) LinksUpdateTest::testUpdate_imagelinks
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: COMMIT
Function: DatabaseBase::commit
Error: 23503 ERROR: insert or update on table "unittest_imagelinks" violates foreign key constraint "ut_imagelinks_il_from_fkey"
DETAIL: Key (il_from)=(111) is not present in table "unittest_page".
/usr/home/saper/test/mytest/includes/db/Database.php:1111
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:511
/usr/home/saper/test/mytest/includes/db/Database.php:1077
/usr/home/saper/test/mytest/includes/db/Database.php:3477
/usr/home/saper/test/mytest/includes/db/Database.php:3462
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:241
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:884
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:334
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:169
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:151
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:193
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:157
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:115
6) LinksUpdateTest::testUpdate_langlinks
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: COMMIT
Function: DatabaseBase::commit
Error: 23503 ERROR: insert or update on table "unittest_langlinks" violates
foreign key constraint "ut_langlinks_ll_from_fkey"
DETAIL: Key (ll_from)=(111) is not present in table "unittest_page".
/usr/home/saper/test/mytest/includes/db/Database.php:1111
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:511
/usr/home/saper/test/mytest/includes/db/Database.php:1077
/usr/home/saper/test/mytest/includes/db/Database.php:3477
/usr/home/saper/test/mytest/includes/db/Database.php:3462
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:241
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:884
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:334
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:183
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:151
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:193
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:170
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:115
7) LinksUpdateTest::testUpdate_page_props
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: COMMIT
Function: DatabaseBase::commit
Error: 23503 ERROR: insert or update on table "unittest_page_props" violates foreign key constraint "ut_page_props_pp_page_fkey"
DETAIL: Key (pp_page)=(111) is not present in table "unittest_page".
/usr/home/saper/test/mytest/includes/db/Database.php:1111
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:511
/usr/home/saper/test/mytest/includes/db/Database.php:1077
/usr/home/saper/test/mytest/includes/db/Database.php:3477
/usr/home/saper/test/mytest/includes/db/Database.php:3462
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:241
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:884
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:334
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:215
/usr/home/saper/test/mytest/includes/deferred/LinksUpdate.php:151
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:193
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:183
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:115
Question #1: are LinksUpdates needed at all on the DB engine using triggers (ON DELETE CASCADE) to remove dependent rows? If yes, what can we do to make it create consistent contents of the database during this test?
Simplistic changes like
diff --git a/tests/phpunit/includes/LinksUpdateTest.php b/tests/phpunit/includes/LinksUpdateTest.php
index b37ff2e..60ad76e 100644
--- a/tests/phpunit/includes/LinksUpdateTest.php
+++ b/tests/phpunit/includes/LinksUpdateTest.php
@@ -49,6 +49,10 @@ class LinksUpdateTest extends MediaWikiTestCase {
$po = new ParserOutput();
$po->setTitleText( $t->getPrefixedText() );
+ $pg = WikiPage::factory( $t );
+ $dbw = wfGetDB ( DB_MASTER );
+ $pg->insertOn( $dbw );
+
return array( $t, $po );
}
don't fix the problem and make even more tests to fail, like on MySQL:
1) LinksUpdateTest::testUpdate_pagelinks
row #1 missing
Failed asserting that a boolean is not empty.
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:678
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:200
/usr/home/saper/test/mytest/tests/phpunit/includes/LinksUpdateTest.php:72
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:115
--------------------------
**Version**: 1.23.0
**Severity**: normal
wfWarn() is called, among others, from Database::rollback where it warns
that there is no transaction to rollback.
Rollback is used already in the error situation; in this case wfWarn exits and this prevents subsequent printing of the real database error message that caused the database problem in the first place.
With 4b291909e0e91ad4e8ed98030c1312a872ca3bd4 in place, SQL transactions on PostgreSQL fail with:
TestORMRowTest::testSaveAndRemove with data set #0 (array('Foobar', '2012-01-01 02:02:02 G
MT', 42, 9000.1, true, array(13, 11, 7, 5, 3, 2), stdClass), true)
DatabasePostgres::reportQueryError: No transaction to rollback, something got out of sync! [Ca
lled from DatabaseBase::rollback in /usr/home/saper/test/mytest/includes/db/Database.php at li
ne 3482]
/usr/home/saper/test/mytest/includes/debug/Debug.php:301
/usr/home/saper/test/mytest/includes/debug/Debug.php:157
/usr/home/saper/test/mytest/includes/GlobalFunctions.php:1110
/usr/home/saper/test/mytest/includes/db/Database.php:3482
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:510
/usr/home/saper/test/mytest/includes/db/Database.php:1077
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:871
/usr/home/saper/test/mytest/includes/db/ORMTable.php:1015
/usr/home/saper/test/mytest/includes/db/ORMRow.php:352
/usr/home/saper/test/mytest/tests/phpunit/includes/db/ORMRowTest.php:143
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:119
while the real error should be:
TestORMRowTest::testSaveAndRemove with data set #0 (array('Foobar', '2012-01-01 02:02:02 GM
T', 42, 9000.1, true, array(13, 11, 7, 5, 3, 2), stdClass), true)
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php afte
r upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: INSERT INTO "orm_test" (test_id,test_name,test_age,test_height,test_awesome,test_stuff,
test_moarstuff,test_time) VALUES (NULL,'Foobar','42','9000.1',1,'a:6:{i:0;i:13;i:1;i:11;i:2;i:
7;i:3;i:5;i:4;i:3;i:5;i:2;}','O:8:"stdClass":3:{s:3:"foo";s:3:"bar";s:3:"bar";a:2:{i:0;i:4;i:1
;i:2;}s:3:"baz";b:1;}','2012-01-01 02:02:02 GMT')
Function: ORMTable::insertRow
Error: 23502 ERROR: null value in column "test_id" violates not-null constraint
/usr/home/saper/test/mytest/includes/db/Database.php:1111
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:511
/usr/home/saper/test/mytest/includes/db/Database.php:1077
/usr/home/saper/test/mytest/includes/db/DatabasePostgres.php:871
/usr/home/saper/test/mytest/includes/db/ORMTable.php:1015
/usr/home/saper/test/mytest/includes/db/ORMRow.php:352
/usr/home/saper/test/mytest/tests/phpunit/includes/db/ORMRowTest.php:143
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:119
Warning about transaction not being open is completely irrelevant in this context.
It causes some less useful error reports like bug 57724.
Reverting 4b291909e0e91ad4e8ed98030c1312a872ca3bd4 restores proper error reporing and actually fixes ORMTableTest::testIgnoreErrorsOverride and some others on PostgreSQL.
--------------------------
**Version**: 1.23.0
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57724
I was running PostgreSQL and MySQL tests in parallel on one machine,
it seems that one test instance nuked /tmp/Foobar.svg needed by the other one :)
There were 2 errors:
1) ParserTests::testParserTest with data set #41 ('Italicized possessive', 'The \'\'[[Main Pag
e]]\'\'\'s talk page.', '<p>The <i><a href="/wiki/Main_Page" title="Main Page">Main Page</a>\'
</i>s talk page.
</p>', '', '')
filesize(): stat failed for /tmp/Foobar.svg
/usr/home/saper/test/mytest/includes/filebackend/FileBackendStore.php:163
/usr/home/saper/test/mytest/includes/filebackend/FileBackendStore.php:1097
/usr/home/saper/test/mytest/includes/filebackend/FileBackend.php:592
/usr/home/saper/test/mytest/includes/filebackend/FileBackend.php:612
/usr/home/saper/test/mytest/includes/filebackend/FileBackend.php:640
/usr/home/saper/test/mytest/tests/phpunit/includes/parser/NewParserTest.php:459
/usr/home/saper/test/mytest/tests/phpunit/includes/parser/NewParserTest.php:388
/usr/home/saper/test/mytest/tests/phpunit/includes/parser/NewParserTest.php:586
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:119
2) ParserTests::testParserTest with data set #196 ('BUG 787: Links with one slash after the ur
l protocol are invalid', 'http:/example.com
[http:/example.com title]', '<p>http:/example.com
</p><p>[http:/example.com title]
</p>', '', '')
filesize(): stat failed for /tmp/Foobar.svg
/usr/home/saper/test/mytest/includes/filebackend/FileBackendStore.php:163
/usr/home/saper/test/mytest/includes/filebackend/FileBackendStore.php:1097
/usr/home/saper/test/mytest/includes/filebackend/FileBackend.php:592
/usr/home/saper/test/mytest/includes/filebackend/FileBackend.php:612
/usr/home/saper/test/mytest/includes/filebackend/FileBackend.php:640
/usr/home/saper/test/mytest/tests/phpunit/includes/parser/NewParserTest.php:459
/usr/home/saper/test/mytest/tests/phpunit/includes/parser/NewParserTest.php:388
/usr/home/saper/test/mytest/tests/phpunit/includes/parser/NewParserTest.php:586
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:119
--------------------------
**Version**: 1.23.0
**Severity**: minor
When testing on PostgreSQL:
3) ApiQueryBasicTest::testGenerator
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'AQBT-All'
+'AQBT-Categories'
/usr/home/saper/test/mytest/tests/phpunit/includes/api/query/ApiQueryTestBase.php:143
/usr/home/saper/test/mytest/tests/phpunit/includes/api/query/ApiQueryTestBase.php:141
/usr/home/saper/test/mytest/tests/phpunit/includes/api/query/ApiQueryTestBase.php:141
/usr/home/saper/test/mytest/tests/phpunit/includes/api/query/ApiQueryTestBase.php:141
/usr/home/saper/test/mytest/tests/phpunit/includes/api/query/ApiQueryTestBase.php:105
/usr/home/saper/test/mytest/tests/phpunit/includes/api/query/ApiQueryTestBase.php:100
/usr/home/saper/test/mytest/tests/phpunit/includes/api/query/ApiQueryBasicTest.php:299
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiTestCase.php:123
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:80
/usr/home/saper/test/mytest/tests/phpunit/MediaWikiPHPUnitCommand.php:64
/usr/home/saper/test/mytest/tests/phpunit/phpunit.php:119
Looks like that list of pages returned by API is okay, only the order is different:
Request: generator=links&titles=AQBT-Links&action=query
Expected:
Array
(
[query] => Array
(
[pages] => Array
(
[1] => Array
(
[pageid] => 1
[ns] => 0
[title] => AQBT-All
)
[2] => Array
(
[pageid] => 2
[ns] => 0
[title] => AQBT-Categories
)
[4] => Array
(
[pageid] => 4
[ns] => 0
[title] => AQBT-Templates
)
)
)
)
Result:
Array
(
[query] => Array
(
[pages] => Array
(
[109] => Array
(
[pageid] => 109
[ns] => 0
[title] => AQBT-Categories
)
[108] => Array
(
[pageid] => 108
[ns] => 0
[title] => AQBT-All
)
[111] => Array
(
[pageid] => 111
[ns] => 0
[title] => AQBT-Templates
)
)
)
)
Not sure if order of page titles returned by API should be guaranteed? Should we test for it?
--------------------------
**Version**: 1.23.0
**Severity**: minor
Configuration read from /usr/home/saper/test/mytest/tests/phpunit/suite.xml
............................................................. 61 / 7428 ( 0%)
.................EEEEEEEE.................................... 122 / 7428 ( 1%)
............................................................. 183 / 7428 ( 2%)
............................................................. 244 / 7428 ( 3%)
............................................................. 305 / 7428 ( 4%)
............................................................. 366 / 7428 ( 4%)
............................................................. 427 / 7428 ( 5%)
............................................................. 488 / 7428 ( 6%)
............................................................. 549 / 7428 ( 7%)
............................................................. 610 / 7428 ( 8%)
............................................................. 671 / 7428 ( 9%)
............................................................. 732 / 7428 ( 9%)
............................................................. 793 / 7428 ( 10%)
............................................................. 854 / 7428 ( 11%)
............................................................. 915 / 7428 ( 12%)
............................................................. 976 / 7428 ( 13%)
............................................................. 1037 / 7428 ( 13%)
............................................................. 1098 / 7428 ( 14%)
............................................................. 1159 / 7428 ( 15%)
............................................................. 1220 / 7428 ( 16%)
............................................................. 1281 / 7428 ( 17%)
............................................................. 1342 / 7428 ( 18%)
............................................................. 1403 / 7428 ( 18%)
............................................................. 1464 / 7428 ( 19%)
............................................................. 1525 / 7428 ( 20%)
............................................................. 1586 / 7428 ( 21%)
............................................................. 1647 / 7428 ( 22%)
............................................................. 1708 / 7428 ( 22%)
...............E............................................. 1769 / 7428 ( 23%)
............................................................. 1830 / 7428 ( 24%)
............................................................. 1891 / 7428 ( 25%)
............................................................. 1952 / 7428 ( 26%)
............................................................. 2013 / 7428 ( 27%)
............................................................. 2074 / 7428 ( 27%)
......................EE..FF......E.......................... 2135 / 7428 ( 28%)
...........E................................................. 2196 / 7428 ( 29%)
............................................................. 2257 / 7428 ( 30%)
.......................................F
Request: generator=links&titles=AQBT-Links&action=query
Expected:
Array
(
[query] => Array
(
[pages] => Array
(
[1] => Array
(
[pageid] => 1
[ns] => 0
[title] => AQBT-All
)
[2] => Array
(
[pageid] => 2
[ns] => 0
[title] => AQBT-Categories
)
[4] => Array
(
[pageid] => 4
[ns] => 0
[title] => AQBT-Templates
)
)
)
)
Result:
Array
(
[query] => Array
(
[pages] => Array
(
[109] => Array
(
[pageid] => 109
[ns] => 0
[title] => AQBT-Categories
)
[108] => Array
(
[pageid] => 108
[ns] => 0
[title] => AQBT-All
)
[111] => Array
(
[pageid] => 111
[ns] => 0
[title] => AQBT-Templates
)
)
)
)
..................... 2318 / 7428 ( 31%)
--------------------------
**Version**: unspecified
**Severity**: trivial
When trying to access http://git.wikimedia.org/:
GET http://git.wikimedia.org/, from 127.0.0.1 via cp1044 cp1044 ([127.0.0.1]:80), Varnish XID 1195467226
Forwarded for: 2a01:198:200:15f::2, 127.0.0.1
Error: 500, Internal Server Error at Mon, 04 Nov 2013 11:14:37 GMT
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11 but that's probably irrelevant
--------------------------
**Version**: wmf-deployment
**Severity**: blocker
**URL**: http://git.wikimedia.org
When autoblocked, the user gets 'autoblocktext' message:
```
You do not have permission to edit this page, for the following reason:
Your IP address has been automatically blocked because it was used by another user, who was blocked by Saper. The reason given is:
Autoblocked because your IP address has been recently used by "Test1".
The reason given for Test1's block is "testing autoblock message"
• Start of block: 22:55, 27 October 2013
• Expiry of block: 22:55, 28 October 2013
• Intended blockee: 2A01:198:200:15F:0:0:0:2
You may contact Saper or one of the other administrators to discuss the block.
```
Special:BlockList reveals:
```
lang=html
</tr></thead><tbody>
<tr>
<td class="TablePager_col_ipb_timestamp">22:55, 27 October 2013</td>
<td class="TablePager_col_ipb_target">
<a href="/trunk/w/index.php?title=User:Test1&action=edit&redlink=1" class="new mw-userlink" title="User:Test1 (page does not exist)">Test1</a>
<span>...</span></td>
<td class="TablePager_col_ipb_expiry">22:55, 28 October 2013</td>
<td class="TablePager_col_ipb_by"><a href="/trunk/w/index.php?title=User:Saper&action=edit&redlink=1" class="new mw-userlink" title="User:Saper (page
does not exist)">Saper</a> <span>...</span></td>
<td class="TablePager_col_ipb_params">account creation disabled, cannot edit own talk page</td>
<td class="TablePager_col_ipb_reason">testing autoblock message</td>
</tr>
<tr>
<td class="TablePager_col_ipb_timestamp">22:55, 27 October 2013</td>
<td class="TablePager_col_ipb_target">Autoblock #10</td>
<td class="TablePager_col_ipb_expiry">22:55, 28 October 2013</td>
<td class="TablePager_col_ipb_by"><a href="/trunk/w/index.php?title=User:Saper&action=edit&redlink=1" class="new mw-userlink" title="User:Saper (page
does not exist)">Saper</a> <span>...</span></td>
<td class="TablePager_col_ipb_params">account creation disabled, cannot edit own talk page</td>
<td class="TablePager_col_ipb_reason">Autoblocked because your IP address has been recently used by "<a href="/trunk/w/index.php?title=User:Test1&act
ion=edit&redlink=1" class="new" title="User:Test1 (page does not exist)">Test1</a>". The reason given for Test1's block is "''testing autoblock message''"</td>
</tr>
</tbody>
```
This was just an autoblock on 2A01:198:200:15F:0:0:0:2 (Autoblock #10) and originally this block was intended to block "Test1".
Now, because we know which block is the parent to the autoblock, we may
give "the real culprit" and avoid disclosing IP address (see similar privacy issues in bug 53008).
It seems to me that providing the parent block target instead would be better.
--------------------------
**See Also**: T55008
In a fix to T34168 (bug 32168) rSVN103208 in line 458 introduced a case where relative URL (the one NOT containing "/") will *not* be expanded with $wgServer.
This caused T39868 (bug 37868) as well as ancillary issue with T40048 (bug 38048, wrong redirect).
I believe this behaviour should be reinstated.
1. Login as user A
2. Start creating book using Special:Book, add one page
3. Logout
4. Login as user B
5. Go to Special:Book
you will see the page added by user A in the Special:Book
While collaboration should be encouraged (see T46185) I think this is pretty
unexpected.
--------------------------
**Version**: master
**Severity**: minor
**See Also**: {T46185}
When using a text browser, the login page looks like here:
Jump to: navigation, search
Username [ ]
Password Reset your password [ ]
[ ] Keep me logged in (for up to 30 days)
[Log in]
Help with logging in
w3m (and some other text browsers) tabs over all links, images and fields, not obeying tabindex (for a reason - those need to be reachable somehow).
What happens now one has to tab over the "Reset your password" link once more to get to the password field. I suppose also screen reader user might be confused - "Reset your password" follows just the string "Password" in the HTML of the page:
<label for='wpPassword1'>
Password <a href="/wiki/Special:PasswordReset" title="Special:PasswordReset" class="mw-ui-flush-right">Reset your password</a> </label>
<input class="loginPassword" id="wpPassword1" tabindex="2" size="20" placeholder="Enter your password"
type="password" name="wpPassword" /> </div>
Arguably, "Reset your password" does not belong to this <label> at all.
Even in the graphical browser, when reading LTR, one glances over "Password " and "Reset your password" labels, probably focusing more on "Enter your password" prompt in the field itself. Eyeballs shouldn't be bothered with
some not very often used link if the user is going to provide the password
right away.
I think those fields should be re-ordered, at least in HTML (and may be even
in the layout for the graphical browser).
I would suggest to move "Reset your password" before or after "Help logging in" - actually this could be on a single line with "Reset your password" probably right justified. Not sure what relative position of those should be vis-a-vis "Log in" button, but logically "reset your password" is some specific tool address on particular login problem; while the rest of the problems should be addressed in "Help logging in".
Please note that some sites (Google I think) call their forgot password "Problems logging in?" and therefore one link might cover all cases -
forgotten psssword, some more complex account recovery tool and some
general help. Additional "Help logging in" button is then unnecessary.
Most popular workflow should be "User name" -> "Password" -> "Log in" with all other buttons (remember 30 days, recover and help) moved out of the way, if possible.
--------------------------
**Version**: 1.22.0
**Severity**: normal
**URL**: https://en.wikipedia.org/wiki/Special:Userlogin?uselang=en
When watching a typical Wikipedia page using a text browser (w3m in my case), I am getting:
Navigation menu
Personal tools
• Saper
• 1
• Talk
• Preferences
• Watchlist
• Contributions
• Log out
Namespaces
• Project page
• Discussion
Variants
..
I would say things are more or less clear and readable except this magic digit "one" in the second line.
It should be something along the lines:
* There is 1 unread message (or "notification available" or ...)
--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: https://commons.wikimedia.org/wiki/File:MediaWiki_Notifcation.png
Because Wikimedia Polska (Polish Wikimedia chapter) is receiving majority of funds via public donations done via Polish tax system, there are certain reporting requirements attached. One of those is to run a publicly-facing website that contains relevant "public sector information" as the information to the general public.
Those "public sector information" websites are plain websites with some certain requirements. There is a requirement that "public sector information database needs to be backed up on separate medium within 24 hours after the last change; if the information is changed more often than once per 24 hours, it is enough to provide a backup once per 24 hours".
To avoid duplicated effort, we currently explore the possibility to use the existing chapter's wiki, http://pl.wikimedia.org/ as the "public sector information" website (we currently meet 90%+ of requirements).
I have currently two ideas how to fulfill this "backup requirement":
1) to generate our own dumps using Special:Export or toolserver.org (or its labs equivalent, onces databases are available there),
2) to use Wikimedia XML dump service for this purpose.
I am not aware if Foundation-hosted wikis have some other form of backup available.
Would that be possible to increase frequency of plwikimedia XML dumps to occur once per 24 hours? I know there are currently some space issues, but maybe they will be resolved later.
Currently http://dumps.wikimedia.org/plwikimedia/20130821/plwikimedia-20130821-pages-meta-history.xml.7z is only 25 megabytes.
--------------------------
**Version**: unspecified
**Severity**: enhancement
**URL**: http://pl.wikimedia.org
When using a book rendered under the above URL
Sources section contains just "</includeonly>"
This is most probably just a buggy {{interview}}
template (or one of the other included ones),
but nevertheless MediaWiki parser does not has
this problem.
--------------------------
**Version**: master
**Severity**: normal
**URL**: https://en.wikinews.org/wiki/Wikinews:Books/Interviews_with_Paralympians
When uploading using [[Special:UploadWizard]] the image upload gets logged into the CheckUser log as:
(Rejestr operacji) . . 22:19 . . Saper (dyskusja | edycje | zablokuj) Saper uploaded "File:Screenshot one.png" (User created page with UploadWizard)
IP: 127.0.0.1
instead of
(Rejestr operacji) . . 22:37 . . Saper (dyskusja | edycje | zablokuj) Saper uploaded "File:No sighted version en.png" (User created page with UploadWizard)
IP: 2A01:198:200:15F:0:0:0:2 Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.57 Safari/536.11
This is because after commit a31d0f8edd167e9ee301b694a8092fe0cbcfdabf (Change ID: Iae38b93d65182158561b92168af51a1e9f50374c) the actual upload is handled by the command-line utility that does not receive all WebRequest metadata.
Reverting this commit has restored this functionality in my tests (even though there are multiple API requests in the log and only the final one adds the entry to the "image" table).
--------------------------
**Version**: master
**Severity**: critical
Screenshot of a page pending review right after undo
I have just undid
https://pl.wikipedia.org/w/index.php?title=Kurhaus_Publishing&diff=34150229&oldid=34148206
creating
https://pl.wikipedia.org/w/index.php?title=Kurhaus_Publishing&diff=34209359&oldid=34150229
and after reload I got "The stable version was checked on 9 January 2013. There is 1 pending change awaiting review." A screenshot is attached.
A previous version was manually checked:
20:59, 9 January 2013 John Belushi (Talk | contribs | block) reviewed a version of Kurhaus Publishing (changes reviewed) (revision: 20:59, 9 January 2013)
https://pl.wikipedia.org/w/index.php?title=Specjalna%3ARejestr&type=review&user=John+Belushi&page=Kurhaus+Publishing&year=&month=-1&tagfilter=
My permissions:
Administrators, Autoconfirmed users, Check users, Abuse filter editors, Editors, Users
From https://pl.wikipedia.org/wiki/Special:UserGroupRights:
Editors
(list of members)
Edit semi-protected pages (autoconfirmed)
Have one's own edits automatically marked as "checked" (autoreview)
Mark revisions as being "checked" (review)
Quickly rollback the edits of the last user who edited a particular page (rollback)
View recent changes patrol marks (patrolmarks)
View the list of unreviewed pages (unreviewedpages)
I had reviewed the change manually (and it worked).
--------------------------
**Version**: master
**Severity**: normal
**Attached**: {F10280}
```lang=irc
09:31 < Seddon> Nemo_bis, unless I am waking up in the middle of my sleep to send translation notifications.......... which would be pretty damn weird, the
notification extension is broken
09:32 < saper> Seddon: wrong timestamp?
09:33 < Seddon> saper: people are getting multiple notifications. one guy I saw got 4 notifications spread over a period of days
09:33 < saper> Seddon: do you have some links?
09:33 < Seddon> yeah one sec
09:34 < Platonides> Seddon, the "you get notifications with the wrong email content when someone reviews your translation" bug ?
09:34 < Seddon> no, talk page
09:34 < Seddon> http://meta.wikimedia.org/wiki/User_talk:Vladimir_Penov
09:34 < Seddon> this guy have 4 versions of one notification, 3 of another and two of the most recent
09:35 < Seddon> I checked my contributions and I apparently sent out two batches of notifications
09:39 < Seddon> I wonder...........
09:44 < saper> Seddon: https://meta.wikimedia.org/w/index.php?title=User_talk:Vladimir_Penov&diff=4751313&oldid=4748846 and
https://meta.wikimedia.org/w/index.php?title=User_talk:Vladimir_Penov&diff=4754445&oldid=4751313 ?
09:45 < Seddon> saper: Thats the latest instance of it yeah.... I couldn't have sent the second version cause at the time I was asleep
09:45 < saper> byte count is also identical, module one or two digit day
09:46 < Seddon> https://meta.wikimedia.org/w/index.php?title=Special%3ALog&type=notifytranslators&user=&page=&year=&month=-1&tagfilter=&hide_patrol_log=1
09:46 < Seddon> only two requests here as well
```
--------------------------
**Version**: 1.21.x
**Severity**: major
**URL**: https://meta.wikimedia.org/w/index.php?title=User_talk:Vladimir_Penov&action=history
**See Also**:
* {T44614}
* {T46960}
* {T46962}
* {T46963}
* {T59896}
1) Need to remove no longer working links to the streaming on toolserver.org
2) As we got new material to be successively uploaded that needs to be linked in various places of the Wiki (Schedule but not only)
3) There might be some discussion on the material/its presentation etc.
therefore I would like to unlock the wiki again for editing on usual terms.
We've just had an informal discussion with stewards on IRC and as it is not a one-time change any steward could do it might be better to just unlock the wiki.
I was the "owner", bureaucrat and sysop on the wiki and I think we can handle recent changes. I would like to have those permissions reinstated if possible.
After the operation is complete and there is no ongoing discussion this wiki can be closed again (I don't think it will take more than 2-3 months).
--------------------------
**Version**: unspecified
**Severity**: normal
T41273 uncovered actually an interesting possibility to explore - to have both live preview and live diff preview at the same time.
This would probably require adding another button to have downstairs:
[Save changes]
[Refresh preview]
[Hide preview]
[Hide changes]
--------------------------
**Version**: 1.21.x
**Severity**: enhancement
Some extensions like Cite or SyntaxHighlight_GeSHi (see gerrit change 20219) issue error messages (like "syntaxhighlight-specify") that are inserted into the page HTML and therefore are currently rendered in the content language instead of the user language.
This bug is about discussing whether (1) they should use user (chrome) language
instead and (2) how to do it without cache thrashing .
--------------------------
**Version**: unspecified
**Severity**: enhancement
1) Enable "Live preview (requires JavaScript)" experimental feature in editing.
2) Edit something, don't save
3) "Show changes"
4) "Preview"
You will see non-reloading preview screen generated by the Live Preview function, but below the preview you still have "show changes" displayed.
Maybe this would be a GoodThing(tm) to have "LiveShowChanges" as well, but the display is stale - the old "Show changes" stay as they were originally.
--------------------------
**Version**: unspecified
**Severity**: normal
(WARNING) Conversion of this tracking task to a project is discussing at T192074
This bug tracks all problems related to the "Live preview" feature that can be enabled in the preferences under "Editing".
RFC (later withdrawn): https://www.mediawiki.org/wiki/Requests_for_comment/Live_preview
**URL**: https://www.mediawiki.org/wiki/Manual:Live_preview
Currently the interface says:
"Selected accounts will be blocked indefinitely, with autoblocking of IP addresses enabled and account creation disabled. IP addresses will be blocked for one week for anonymous users only and account creation will be disabled."
and offers replacing the user and talk pages.
We could possibly allow two options from [[Special:Block]]:
Prevent user from sending e-mail
Prevent this user from editing their own talk page while blocked
--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=16306
https://bugzilla.wikimedia.org/show_bug.cgi?id=24482
My usual workflow: (Starting in the Category: namespace) 1) Search Commons categories 2) Find the most descriptive category - sometimes there is the only one, sometimes one has to pick few ones. This case deales with the simplest case of the only one. 3) Assume one finds the best matching category (or just created one) 4) I start file upload 5) The current category should at least be offered to be added to the image. Or even by added by default. Similar workflow: (Starting in the File: namespace) 1) I find an existing image that matches my new images perfectly. 2) My new uploaded image should have initially all the categories the original image had. Some of it might be easier to do using UploadWizard, but filing under core (it might be possible for the core as well). Maybe in general uploads should/could inherit catgories of the place the user is actually in. Might be a very usable thing for mobile uploads - find similar picture, upload more, next..., next..., next... Quick process without tedious category search (of course unless the user choses to edit them by hand)
--------------------------
**Version**: unspecified
**Severity**: enhancement
Usually searching right categories or adding a multi-lingual description
takes some time.
Yesterday I was uploading a single photo and I was surprised I had to wait
for a pretty long time for the upload to finish before I could select
license and work on metadata.
It would be nice to have upload progress in the background and be able to
work on meta data in the meantime.
--------------------------
**Version**: master
**Severity**: normal
When asked for username IP addresses or edits CheckUser might return entries for 127.0.0.1 (for internally generated entries via FauxRequest etc.).
When asked for users on 127.0.0.1 no results are shown, however.
```lang=sql
select * from cu_changes where cuc_ip_hex = '7F000001';```
returns no results
It seems like 127.0.0.1 entries are stored like this:
```lang=sql
# select * from cu_changes where cuc_ip_hex='0';
-[ RECORD 1 ]--+--------------------------------
cuc_id | 68
cuc_namespace | 90
cuc_title | Dyskusja_użytkownika:Saper/test
cuc_user | 1
cuc_user_text | Saper
cuc_actiontext |
cuc_comment | Nowy wątek – test
cuc_minor | 1
cuc_page_id | 1717
cuc_this_oldid | 63082
cuc_last_oldid | 0
cuc_type | 1
cuc_timestamp | 2012-05-07 23:21:58+02
cuc_ip | 127.0.0.1/32
cuc_ip_hex | 0
cuc_xff |
cuc_xff_hex |
cuc_agent |
```
and have cuc_ip_hex stored as zero instead of 7F0001
For MySQL 127.0.0.1 entries are correct:
``` cuc_id: 22
cuc_namespace: 4
cuc_title: Książki/Moja_książka
cuc_user: 1
cuc_user_text: Saper
cuc_actiontext:
cuc_comment: Utworzył nową stronę „{{zapisane_książki}} == Moja książka == === test === :[[Strona główna]] [[Kategoria:Książki|Książki/Moja książka]]”
cuc_minor: 0
cuc_page_id: 8
cuc_this_oldid: 15
cuc_last_oldid: 0
cuc_type: 1
cuc_timestamp: 20120301052308
cuc_ip: 127.0.0.1
cuc_ip_hex: 7F000001
cuc_xff:
cuc_xff_hex: NULL
cuc_agent:
4 rows in set (0.00 sec)```
--------------------------
**Version**: master
**Severity**: normal
History of the article
Recent changes from curid=12171 on plwiki show strange changes in bytecount (+117 556) and (+117 576) that do not match article history. We believe that history is correct:
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&action=history
21:45 (cur | prev) . . (+42) . . Saper (Talk | contribs | block) (→Faza pucharowa: wynik ITA-ENG) [rollback]
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776912&oldid=31776858
m 21:39 (cur | prev) . . (+41) . . Flyz1 (Talk | contribs | block) (→Ćwierćfinały: drobne techniczne)
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776858&oldid=31776843
m 21:37 (cur | prev) . . (-4) . . Flyz1 (Talk | contribs | block) (→Zakwalifikowane drużyny: drobne techniczne)
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776843&oldid=31776818
21:34 (cur | prev) . . (+2) . . Adriaanek95 (Talk | contribs | block) (euro)
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776818&oldid=31776804
21:32 (cur | prev) . . (-3) . . 62.133.138.179 (Talk | block) (→Zakwalifikowane drużyny: )
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776804&oldid=31776797
21:31 (cur | prev) . . (+117,556) . . 89.191.147.127 (Talk | block) (→Ćwierćfinały: )
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776797&oldid=31776794
21:31 (cur | prev) . . (+3) . . 89.228.228.162 (Talk | block) (→Ćwierćfinały: )
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776794&oldid=31776786
21:30 (cur | prev) . . (+24) . . Saper (Talk | contribs | block) (→Faza pucharowa: ITA)
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776786&oldid=31776779
21:29 (cur | prev) . . (-30) . . Kobrabones (Talk | contribs | block) (→Strzelcy: drobne techniczne)
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776779&oldid=31776769
21:28 (cur | prev) . . (-14) . . Saper (Talk | contribs | block) (→Finał: -ENG)
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776769&oldid=31776763
21:27 (cur | prev) . . (+117,576) . . Saper (Talk | contribs | block) (→Półfinały: ITA)
https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776763&oldid=31776758
21:26 (cur | prev) . . (-7) . . Patryk1210 (Talk | contribs | block) (→Zakwalifikowane drużyny: akt. po 24 czerwca) https://pl.wikipedia.org/w/index.php?title=Mistrzostwa_Europy_w_Pi%C5%82ce_No%C5%BCnej_2012&curid=127131&diff=31776758&oldid=31774907
--------------------------
**Version**: 1.20.x
**Severity**: normal
**Attached**: {F9421}
standard/cologneblue/chick/skin/nostalgia skins do not have "permalink" - link to the current revision of the page (it it's an article) and do not support
"SkinTemplateBuildNavUrlsNav_urlsAfterPermalink" hook that allows adding more links my extensions (most notably Cite and Collection extensions)
--------------------------
**Version**: unspecified
**Severity**: normal
"Cite this page" link is not present for standard/chick/cologneblue/simple/nostalgia skins.
--------------------------
**Version**: unspecified
**Severity**: normal
Looks like tables used for unit tests do not have all relationships of the original ones:
(below was obtained from running unit tests with temporary tables disabled)
minitest=# \d pagelinks
Table "mediawiki.pagelinks"
| Column | Type | Modifiers
| --- | --- | --- |
| pl_from | integer | not null
| pl_namespace | smallint | not null
| pl_title | text | not null
```
Indexes:
"pagelink_unique" UNIQUE, btree (pl_from, pl_namespace, pl_title)
"pagelinks_title" btree (pl_title)
Foreign-key constraints:
"pagelinks_pl_from_fkey" FOREIGN KEY (pl_from) REFERENCES page(page_id) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED
```
minitest=# \d page
minitest=# \d unittest_pagelinks
Table "mediawiki.unittest_pagelinks"
| Column | Type | Modifiers
|--------------|----------|-----------
| pl_from | integer | not null
| pl_namespace | smallint | not null
| pl_title | text | not null
--------------------------
**Version**: 1.20.x
**Severity**: major
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57724
+++ This bug was initially created as a clone of Bug #37612 +++
Sample result from the test wiki:
(diff) (hist) . . N Test . . 01:44 . . Saper (Talk | contribs | block) (test)
IP: 2001:6a0:200:121::2/128 XFF: 0 Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11
on MySQL:
(różn.) (hist.) . . N Test . . 02:24 . . Saper (dyskusja | edycje | zablokuj) (cu test)
IP: 2001:6A0:200:121:0:0:0:2 Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11
"XFF: 0" starts to appear after May 7th trunk (edits made on May 7th and earlier have no XFF, edits made on June 14th and later have "XFF: 0").
Not only edits are affected, log entries are affected as well.
--------------------------
**Version**: unspecified
**Severity**: normal
Sample result from the test wiki:
(diff) (hist) . . N Test . . 01:44 . . Saper (Talk | contribs | block) (test)
IP: 2001:6a0:200:121::2/128 XFF: 0 Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11
on MySQL:
(różn.) (hist.) . . N Test . . 02:24 . . Saper (dyskusja | edycje | zablokuj) (cu test)
IP: 2001:6A0:200:121:0:0:0:2 Mozilla/5.0 (X11; FreeBSD amd64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11
Bug 36780 proposes that the canonical form of the IP address should be "2001:6a0:200:121::2", but we might want to get rid of /128 for IPv6 and /32 for IPv4.
This is because PostgreSQL CIDR type always returns CIDR mask from the database.
--------------------------
**Version**: unspecified
**Severity**: minor
As of c15d0a7521231c2cb71e664265e08d0ae514fc73 we have now 3 unit tests failing and 1 error due to lack of upgrade with PostgreSQL. This could be avoided if we were having PostgreSQL unit tests running by default as we've had for SVN.
I have filed so far (should there be dependency? I don't think so)
https://bugzilla.wikimedia.org/show_bug.cgi?id=36759 WikiPageTest::testDoDeleteArticle fails on PostgreSQL
https://bugzilla.wikimedia.org/show_bug.cgi?id=37600
WikiPageTest::testDoDeleteUpdates fails on PostgreSQL
https://bugzilla.wikimedia.org/show_bug.cgi?id=37601
Tests introduced in tests/phpunit/includes/db/TestORMRowTest.php fail on PostgreSQL
--------------------------
**Version**: unspecified
**Severity**: enhancement
`maintenance/update.php` script was run, but the tests fail nethertheless on PostgreSQL:
```
$ sh -x /usr/home/saper/bin/runphpunit.sh /usr/home/saper/public_html/pg/w/tests/phpunit/includes/db/TestORMRowTest.php
+ php -c /usr/home/saper/php.ini tests/phpunit/phpunit.php --configuration tests/phpunit/suite.xml --exclude-group Broken,Stub,Dump,ParserFuzz --log-junit /usr/home/saper/tests/log/postgres-log.xml /usr/home/saper/public_html/pg/w/tests/phpunit/includes/db/TestORMRowTest.php
PHPUnit 3.6.10 by Sebastian Bergmann.
Configuration read from /usr/home/saper/public_html/pg/w/tests/phpunit/suite.xml
EFF
Time: 1 second, Memory: 31.25Mb
There was 1 error:
1) TestORMRowTest::testConstructor with data set #0 (array('Foobar', 42, 9000.1, true, array(13, 11, 7, 5, 3, 2), stdClass), true)
DBQueryError: A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script
Query: CREATE TABLE IF NOT EXISTS "unittest_orm_test"(
test_id INT unsigned NOT NULL auto_increment PRIMARY KEY,
test_name VARCHAR(255) NOT NULL,
test_age TINYINT unsigned NOT NULL,
test_height FLOAT NOT NULL,
test_awesome TINYINT unsigned NOT NULL,
test_stuff BLOB NOT NULL,
test_moarstuff BLOB NOT NULL,
test_time varbinary(14) NOT NULL
);
Function: DatabaseBase::safeQuery
Error: 42601 ERROR: syntax error at or near "unsigned"
LINE 2: test_id INT unsigned NOT NULL ...
^
/usr/home/saper/public_html/pg/w/includes/db/Database.php:953
/usr/home/saper/public_html/pg/w/includes/db/DatabasePostgres.php:394
/usr/home/saper/public_html/pg/w/includes/db/Database.php:920
/usr/home/saper/public_html/pg/w/includes/db/Database.php:1006
/usr/home/saper/public_html/pg/w/includes/db/Database.php:1031
/usr/home/saper/public_html/pg/w/tests/phpunit/includes/db/TestORMRowTest.php:82
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiTestCase.php:75
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiPHPUnitCommand.php:45
/usr/home/saper/public_html/pg/w/tests/phpunit/phpunit.php:103
--
There were 2 failures:
1) TestORMRowTest::testSave with data set #0 (array('Foobar', 42, 9000.1, true, array(13, 11, 7, 5, 3, 2), stdClass), true)
Failed asserting that false is true.
/usr/home/saper/public_html/pg/w/tests/phpunit/includes/db/ORMRowTest.php:102
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiTestCase.php:75
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiPHPUnitCommand.php:45
/usr/home/saper/public_html/pg/w/tests/phpunit/phpunit.php:103
2) TestORMRowTest::testRemove with data set #0 (array('Foobar', 42, 9000.1, true, array(13, 11, 7, 5, 3, 2), stdClass), true)
Failed asserting that false is true.
/usr/home/saper/public_html/pg/w/tests/phpunit/includes/db/ORMRowTest.php:117
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiTestCase.php:75
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiPHPUnitCommand.php:45
/usr/home/saper/public_html/pg/w/tests/phpunit/phpunit.php:103
FAILURES!
Tests: 3, Assertions: 6, Failures: 2, Errors: 1.
+ exit
```
--------------------------
**Version**: 1.20.x
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43475 T45475
+++ This bug was initially created as a clone of T38759 +++
`WikiPageTest::testDoDeleteUpdates` re-introduced [[https://gerrit.wikimedia.org/r/#q,I12a49d5ca3ccb6bb9cbb63dde436bcf2a7d8a985,n,z|gerrit change 7967]], fails:
```
$ sh -x /usr/home/saper/bin/runphpunit.sh /usr/home/saper/public_html/pg/w/tests/phpunit/includes/WikiPageTest.php
+ php -c /usr/home/saper/php.ini tests/phpunit/phpunit.php --configuration tests/phpunit/suite.xml --exclude-group Broken,Stub,Dump,ParserFuzz --log-junit /usr/home/saper/tests/log/postgres-log.xml /usr/home/saper/public_html/pg/w/tests/phpunit/includes/WikiPageTest.php
PHPUnit 3.6.10 by Sebastian Bergmann.
Configuration read from /usr/home/saper/public_html/pg/w/tests/phpunit/suite.xml
..FF................................................
Time: 4 seconds, Memory: 48.75Mb
There were 2 failures:
1) WikiPageTest::testDoDeleteArticle
pagelinks should contain no more links from the page
Failed asserting that 1 matches expected 0.
/usr/home/saper/public_html/pg/w/tests/phpunit/includes/WikiPageTest.php:144
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiTestCase.php:75
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiPHPUnitCommand.php:45
/usr/home/saper/public_html/pg/w/tests/phpunit/phpunit.php:103
2) WikiPageTest::testDoDeleteUpdates
pagelinks should contain no more links from the page
Failed asserting that 1 matches expected 0.
/usr/home/saper/public_html/pg/w/tests/phpunit/includes/WikiPageTest.php:159
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiTestCase.php:75
/usr/home/saper/public_html/pg/w/tests/phpunit/MediaWikiPHPUnitCommand.php:45
/usr/home/saper/public_html/pg/w/tests/phpunit/phpunit.php:103
FAILURES!
Tests: 52, Assertions: 91, Failures: 2.
```
--------------------------
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=57724