[01:04:27] yo, my Special:Wantedpages is empty despite updateSpecialpages, rebuildall [01:04:36] what do [01:21:52] is it broken for SQLite or something? [01:25:01] do you have any wanted pages to appear on the report? [01:25:29] p858snake: yes. some with >2 links [01:26:08] e.g. https://nanoha.noyu.me/wiki/Special:WhatLinksHere/TSAB [03:03:50] hi! anyone knows how can i combine HTMLForms with file uploads ? [03:04:10] type => file doesnt seem to be an option in HTMLForms [03:04:15] maybe there is a workaround? [03:06:32] interestingly enough, this just recently came up on mediawiki-l [03:07:41] the answer is basically - there's a hacky way that works with non-OOUI forms. [03:08:07] I'm not sure if its officially supported or not. And there is no way to do it with an OOUI htmlform, except by making your own HTMLFormField subclass [03:09:19] thx bawolff [03:09:20] Sophivorus: see also discussion at https://lists.wikimedia.org/pipermail/wikitech-l/2018-April/089790.html [03:09:36] double thx [06:41:13] Hi guys. I have a mediawiki farm and sometimes when I go to http://somewiki.mysite.com/wiki/Main_Page it displays a page from http://anotherwiki.mysite.com/wiki/Main_Page. If I press "edit" it displays correct code from somewiki main page. Any ideas what could cause that? Googling doesn't help. [06:43:14] b7: Check $wgServer in your LocalSettings.php [06:48:39] bawolff: Checked. I recently changed them to protocol-relative URLs, like: $wgServer = "//somewiki.mysite.com"; $wgCanonicalServer = "https://somewiki.mysite.com"; Did I do wrong? [06:48:51] No, that looks correct [06:49:50] Maybe some sort of cache pollution issue [06:50:11] Do the two wikis have different database names? [06:50:35] Are you using varnish/squid cache? [06:52:37] (I ask about the database name, because db name combined with db prefix is used to form wfWikiId(), which is used in the caching code to separate caches for different wikis) [06:54:50] bawolff: maybe. Yes, each wiki has its own db, like pf_somewiki, pf_anotherwiki, etc. I don't use varnish, squid or any other cache. [06:56:27] bawolff: also, it started to happen only after I add https support to mysite and changed $wgServer, although I'm not sure if this was the reason. [06:56:48] Well, as long as they have different db names, then it shouldn't be cache pollution [07:06:31] I put error_log($wgServer) to check it and according to the logs $wgServer is https://anotherwiki.mysite.com while the page displayed is still from somewiki.mysite.com. Strange. [07:14:10] Also dumped pf_anotherwiki database to see if a text from somewiki got there, but there's no text from somewiki in the database dump. [07:16:04] b7: I guess, first thing to do - is it actually displaying contents from somewiki on anotherwiki, or is it redirecting to somewiki [07:17:41] If its not a redirect, and actually displaying contents from the wrong domain, I guess what I'd do is make the site chrome be very different (e.g. Change the skin on one wiki) to see if mediawiki is fetching the wrong page contents, or if like apache is sending to the wrong virtual host [07:18:16] It doesn't seem to redirect. When I add error_log($wgServer) and refresh the page I can see only "https://anotherwiki.mysite.com" in logs while displayed page content is still from somewiki.mysite.com. [07:19:49] I guess that would point to it being a mediawiki issue [07:19:52] its very odd [07:20:41] Is this wiki public by any chance? [07:22:11] bawolff: yes, gwak.ru. [07:28:18] b7: Ok, i think it may be a cache pollution thing [07:28:36] It seems like all the wikis have the same database name "my_wiki" [07:29:40] Which may mean that login cookies might interfere with one another [07:29:59] and if using APC, memcached, etc, that the wiki might use caches from other wiki sites [07:30:25] b7: So the easiest fix would be to rename the database name, so that each wiki has a unique db name [07:31:22] ugh, renaming db's seems unnesarily hard in mysql ( https://stackoverflow.com/questions/67093/how-do-i-quickly-rename-a-mysql-database-change-schema-name ) [07:33:59] b7: As a quick fix, you can try setting $wgCachePrefix to a custom value (has to be different for every wiki). This will probably fix your current problem, but there's probably other things that will still be broken (Like logging into one wiki might log you out of a different one) [07:34:50] MediaWiki generally assumes that the function wfWikiId() will return something different for every wiki in your cluster [07:36:04] b7: Err, wait, that's odd [07:36:42] bawolff: each wiki has its own db but there is a common database for users table to make common login for all wiki. I also set $wgCookieDomain = ".gwak.ru"; to make it work. [07:36:50] $wgDBname is showing separate db names for all your wikis, but the cache key in the html source comment is showing things like "Saved in parser cache with key my_wiki:pcache:idhash:1-0!*!*!*!*!*!* and timestamp 20180421072228 and revision id 6" [07:37:06] the "my_wiki" part of the cache key would normally be the database name [07:37:27] b7: ok, that should work fine [07:39:13] b7: The parser cache key is weird. Maybe you have $wgCachePrefix set to "my_wiki" for some reason? [07:40:03] I'm not sure what else could cause the parser cache key to be different from wfWikiId() [07:41:09] bawolff: $wgCachePrefix isn't set anywhere in configs. But it's definitely a cache issue; when I add ?action=purge the pages displays correctly after purge. [07:41:30] bawolff: how do you see the cache settings, by the way? [07:42:09] If you enable $wgDebugToolbar, i think it gives a summary of some of the cache settings [07:42:30] I'm getting the parser cache key by looking at the html source of the page [07:42:40] bawolff: oh, I see. [07:42:42] as mediawiki puts some info into an html comment [07:45:25] bawolff: my_wiki was the wiki name when I first installed it. Then I used it as a template and wrote a script to clone it on request. Guess I did something wrong, this my_wiki value might remain in template database somewhere and cause the problem. [07:46:01] It should really only cause a problem if its somewhere in LocalSettings.php [07:47:19] And its still being used in newly cached pages (after doing ?action=purge), so its not just old db entries [07:49:45] As a debugging step, you could do something like $wgExtensionFunctions[] = function() { global $wgCachePrefix; error_log( "wgCachePrefix = $wgCachePrefix ; wikiid=" . wfWikiId() ); }; [07:49:57] in LocalSettings.php, to ensure those values are what you think they are [07:50:28] I just did a search in the webserver root directory and got the following result: https://dpaste.de/V5cu [07:51:16] So my_wiki is just a default value for $wgDBname [07:52:14] b7: yes, but that should definitely be overrided in LocalSettings.php (And if it isn't, your wiki wouldn't work at all since it would try to access the wrong db) [07:52:43] Unless i guess you were using some complex LoadBalancer stuff [07:53:13] But if it wasnt overridden, then mw.config.get( 'wgDBname' ) would be wrong in javascript [07:53:33] which it isn't [07:54:52] I'm not sure. Its very weird [07:56:02] bawolff: I add the function and the log says $wgCachePrefix is always empty: wgCachePrefix = ; wikiid=gw_survivio, referer: http://survivio.gwak.ru/wiki/ [07:56:23] err, unless the parser_options key was pointing to a my_wiki key, but it itself was properly using the right db in its own key name. Which would be super weird [07:56:33] b7: huh, well that's what it should be [07:58:44] b7: Another thing to check is if you set the keyspace option to any of the caching setup (This would be a very obscure option that almost nobody uses) [08:01:50] bawolff: I don't even know what it is. As I said, there is no any special caching setups or load balancers or stuff like that. [08:03:46] I guess maybe something like this could happen if various caching stuff was setup before the dbName was configured, but I can't think of a reason how that would happen either [08:10:13] bawolff: neither can I. Anyway, thank you very much for your help, you gave me the clue about where the problem can be. [08:10:41] b7: Another debugging thing you could try is $wgExtensionFunctions[] = function() { error_log(print_r( $parserMemc, true )); }; and look for the keyspace value in the output (output will be several lines) [08:11:21] Which would be able to tell if indeed the parser cache has the wrong keyspace [08:13:40] Err, actually on 1.28, it would be $wgExtensionFunctions[] = function() { error_log(print_r( ObjectCache::getLocalClusterInstance(), true )); }; [08:18:46] bawolff: now I got this: https://dpaste.de/VLz0 [08:19:35] b7: Ok, so the keyspace is definitely set to "my_wiki", so at least that's on the right track for where the problem could be [08:21:01] Maybe $wgDBname is being set too late in LocalSettings.php, you could try setting nearer the beginning of the file (That's kind of grasping at straws though) [08:23:37] Another debugging thing to potentially do (still kind of grasping at straws) is to add: error_log( wfBacktrace( true ) ); as the first line of __construct() method in includes/lib/objectcache/APCObjectCache.php , which will tell you which code is initializing the object cache (presumably too early) [12:12:33] hi [13:56:51] sveta2, hi [17:22:30] hi [17:22:47] Someone has a example with user script to edit a page section? [18:21:43] https://www.mediawiki.org/wiki/API:Edit [18:37:43] how can i develop a script that will automatically create links when it encounters a word that has been inputted by a mod in a dictionary [19:22:32] mbielas_: You let a bot run over those edits, I'd say [19:22:43] Ah meh, I'm too late