Page MenuHomePhabricator
Search Advanced Search
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    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}
    • Task
    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 ]]
    • Task
    • ·Closed
    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) .... ````
    • Task
    • ·Closed
    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.
    • Task
    • ·Closed
    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).
    • Task
    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 ````
    • Task
    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?
    • Task
    • ·Closed
    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? ````
    • Task
    • ·Closed
    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 ```
    • Task
    • ·Closed
    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.
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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 ```` ````
    • Task
    • ·Closed
    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.
    • Task
    • ·Closed
    After T120216 we should prepare a nice composer.json and add the extension as `mediawiki/hitcounters` to packagist.org
    • Task
    • ·Closed
    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! ````
    • Task
    • ·Closed
    (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.
    • Task
    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)
    • Task
    • ·Closed
    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&section=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
    • Task
    • ·Closed
    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)
    • Task
    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.
    • Task
    • ·Closed
    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.
    • Task
    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.
    • Task
    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}
    • Task
    • ·Closed
    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.
    • Task
    • ·Closed
    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} ```
    • Task
    • ·Closed
    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.
    • Task
    • ·Closed
    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.
    • Task
    • ·Closed
    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 ````
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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.
    • Task
    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.
    • Task
    • ·Closed
    If `$wgFeed` is false we generate links to feeds that cause `feed-unavailable` error.
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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> ````
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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.
    • Task
    • ·Closed
    == 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
    • Task
    • ·Closed
    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.
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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 ```
    • Task
    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.
    • Task
    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.
    • Task
    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?)
    • Task
    • ·Closed
    `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?...)
    • Task
    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.
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    -------------------------- **Version**: 1.25-git **Severity**: normal
    • Task
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    OAuth uploads get logged under the toolserver IP address, impacting (among others) CheckUser -------------------------- **Version**: unspecified **Severity**: critical
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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}
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    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?
    • Task
    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.
    • Task
    All bugs related to effects with 127.0.0.1 IP address being used for various automated tasks. -------------------------- **Version**: 1.23.0 **Severity**: normal
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    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&amp;action=edit&amp;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&amp;action=edit&amp;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&amp;action=edit&amp;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 &quot;<a href="/trunk/w/index.php?title=User:Test1&amp;act ion=edit&amp;redlink=1" class="new" title="User:Test1 (page does not exist)">Test1</a>&quot;. The reason given for Test1&#039;s block is &quot;&#039;&#039;testing autoblock message&#039;&#039;&quot;</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
    • Task
    • ·Closed
    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.
    • Task
    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}
    • Task
    • ·Closed
    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
    • Task
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    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}
    • Task
    • ·Closed
    ```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}
    • Task
    • ·Closed
    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
    • Task
    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
    • Task
    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
    • Task
    • ·Closed
    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
    • Task
    (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
    • Task
    • ·Closed
    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
    • Task
    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
    • Task
    • ·Closed
    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
    • Task
    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
    • Task
    • ·Closed
    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}
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    "Cite this page" link is not present for standard/chick/cologneblue/simple/nostalgia skins. -------------------------- **Version**: unspecified **Severity**: normal
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    +++ 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
    • Task
    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
    • Task
    • ·Closed
    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
    • Task
    • ·Closed
    `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
    • Task
    • ·Closed
    +++ 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
    • Task
    Original 458 x 153 JPEG image For a file uploaded as https://commons.wikimedia.org/wiki/File:%C5%81RST_logo_kolor_new.jpg both thumbnails (120 px wide) and rescaled (300px) versions seem to be truncated (the image has a desired size but right side of the image is blank). -------------------------- **Version**: 1.19.0 **Severity**: normal **Attached**: {F9293}
    • Task
    • ·Closed
    Reported on plwiki when accessing https://pl.wikipedia.org/wiki/Grzegorz_IX (not reproducible): „SqlBagOStuff::set”. Baza danych zgłosiła błąd „1637: Too many active concurrent transactions (10.0.6.50)” Related to bug 27283 and bug 35357 ? -------------------------- **Version**: 1.20.x **Severity**: major