[01:41:05] hi there! i have set up a MediaWiki instance at https://origamiking.wiki. I have set up URL rewriting on the nginx side and configured the article short URL format to /w/$1, however, when I search, it goes to /index.php?search=foo&title=Special:Search. I would like it to be /w/Special:Search?search=foo [01:41:26] It's the same for similar links, such as creating a new page. [01:42:00] However, my user page at the top is a link to /w/User:Admin. How can I make it more consistent? [01:43:13] I can share my nginx config and sections of my LocalSettings.php if needed. [01:52:30] the other thing that happens is that / gets redirected to /w/Main_Page somehow and i'd like it not do that [02:15:02] oho, i figured out how to fix / getting redirected by /w/Main_Page. Instead of rewriting to /w/ I just rewrote to /w/Main_Page. [06:00:21] Hi everyone! I want to know that it is possible to replace _ (underscore) separator to - (hyphen) in URL. Like Main_page to Main-page. [06:19:04] Hi all. I've inherited an existing install of MW 1.28.0 with a custom auth plugin (very slightly modified from https://github.com/Schine/MW-OAuth2Client) and am trying to set up a fresh install of 1.34 with the same setup. The plugin registers and appears to handle the oauth handshake correctly, but when redirected back to the wiki, the user is still not authenticated, though a session cookie [06:19:10] gets created. [06:19:56] I'm not very familiar with the MW codebase, so I'm hoping someone can point me in the right direction to add some log lines or something to help debug this. [06:21:45] (*extension, not plugin, sorry... like I said, MW is not what I usually work with) [06:23:37] I'll be heading to bed soon but appreciate any insights and will reply to any questions in ~8 hours [10:18:16] Zebranky_: T252236 is an option [10:18:16] T252236: Prepare CentralAuth (e.g. login.wikimedia.org) for requirement of SameSite=None cross-site cookies in Chrome - https://phabricator.wikimedia.org/T252236 [10:18:39] (that specific task is about CentralAuth but anything using session cookies could be similarly affected) [10:18:59] that said, I have yet to see any actual SameSite rollout from browsers [10:19:45] in general, debugging login issues can be hard, https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems has some pointers [12:58:33] Hi, I'm wondering whether there are any plans to upgrade the Lua version in Scribuntu (the current version seems to be 5.1.5) [13:12:01] [366150bc3f3ee7a64e8ac3d5] /index.php?title=%E7%94%A8%E6%88%B7:AT Error from line 5 of /home/wwwroot/default/extensions/Flow/includes/Container.php: Class 'Pimple\Container' not foundBacktrace:#0 /home/wwwroot/default/includes/AutoLoader.php(109): require()#1 [internal function]: AutoLoader::autoload(string)#2 [13:12:01] /home/wwwroot/default/extensions/Flow/Hooks.php(712): spl_autoload_call(string)#3 /home/wwwroot/default/includes/Hooks.php(174): FlowHooks::onMissingArticleConditions(array, array)#4 /home/wwwroot/default/includes/Hooks.php(202): Hooks::callHook(string, array, array, NULL)#5 /home/wwwroot/default/includes/page/Article.php(1437): Hooks::run(string, [13:12:02] array)#6 /home/wwwroot/default/includes/page/Article.php(699): Article->showMissingArticle()#7 /home/wwwroot/default/includes/actions/ViewAction.php(63): Article->view()#8 /home/wwwroot/default/includes/MediaWiki.php(511): ViewAction->show()#9 /home/wwwroot/default/includes/MediaWiki.php(302): MediaWiki->performAction(Article, Title)#10 [13:12:02] /home/wwwroot/default/includes/MediaWiki.php(900): MediaWiki->performRequest()#11 /home/wwwroot/default/includes/MediaWiki.php(527): MediaWiki->main()#12 /home/wwwroot/default/index.php(44): MediaWiki->run()#13 {main} [13:17:45] If someone knows anything about Lua version upgrades, I'll be sure to check the chat logs. I have to leave now :) [14:26:11] PHP 7.4.0 to 7.4.2 isnt supported, but in that overview php7.4 is supported. so i m fine using 7.4.8 right? [14:26:54] Hi, I would like to access the mediawiki instance I set up using .onion. So, I would need the localhost:port_number a mediawiki server runs on [16:09:39] smalltimebloke: the port is whatever your webserver uses [16:09:46] Port 80 for HTTP, 443 for HTTPS [16:09:58] KurtmitGurt: Presumably. Where does it say 7.4.0 to 7.4.2 isn't? [16:12:53] don the download page.... [16:13:26] https://www.mediawiki.org/wiki/Download big fat warning a bit down the site [16:15:55] my plan is to use 7.4.8 and mariadb 10.5.4 - but since i will upgrade from a mediawiki 1.16.0 - i want to make sure problems will not be php related... [16:21:08] Yeah, 7.4.8 should be fine [16:21:28] Depending on what version of MW you're using, all the PHP 7.4 bugs might not be resolved [16:28:57] well i ll go for the latest version i guess [16:29:55] 1.34 should be reasonable [16:30:10] But any PHP 7.4 issues on 1.34 is a valid and reasonable bug [16:34:12] uhm i ll have the issues in 7.4.8 like in 7.4.2? [16:34:19] gonna use php7.3 then [16:44:31] No [16:44:36] I didn't say that [16:44:46] PHP 7.4 required various changes to the PHP code in MediaWiki [17:41:43] uhm what is 110n_cache? [17:41:56] language cache? may i delete the contents? [17:43:49] You can [17:44:46] ty [17:45:15] math table got binary content... may i delete that aswell? [17:47:40] i guess that table is from some plugin i had to use in 1.16 to use stuff like: \alpha_i \sim \frac {C_A}{\Lambda} [17:48:05] so that binary stuff might be the pictures for that formular [18:34:05] Reedy Thanks for the information on apache mate! [20:19:38] when going away from mw 1.12 with tons of mods and stuff: could i just use a clean, new LocalSettings.php and ignore the old one? like just enter db data and go? [20:38:24] tgr|away: Thanks for the pointers. In case you're curious, it turned out to be a combination of factors: main problem was that the callback was set to use a short URL, but I hadn't thought to configure those. Also found while debugging that the plugin still used SpecialPage::getTitle instead of getPageTitle, and I needed to switch to PHP 7.3 because 7.4 is incompatible (kind of surprised the [20:38:30] installer allowed that in the first place). [20:38:59] Hope that's the last time I need to debug login issues for a long time. :) [20:39:46] i really hope later 7.4 versions will be supported later on [20:59:11] So, this isn't _directly_ Mediawiki-related, but: does it make sense when building a server that primarily hosts Mediawiki to use a dual processor motherboard so one processor can handle just ImageMagick/gs/etc. and the other is set to deal with actual web server processes? Can you even do that in a Linux setup? [21:00:06] (FWIW my wikis' image load right now is in the ~2TB range and my single processor's load issues are almost exclusively wiki image processing-related.) [21:04:42] more cores will be handled as needed. no matter if one or 2 cpu setup. about assigning: "Search Results [21:17:13] KurtmitGurt: it would generally not work like that [21:17:46] usually every core would pick any kind of work [21:18:19] you could have very expensive web request and no images, etc. [21:18:25] as if it was possible, well, yes [21:18:35] you could play with process affinities [21:19:04] so that your image processing could only be scheduled on certain processor [21:19:34] although I suspect launching them with quite low priority would be preferable [21:19:45] so that other cores could help if not busy, too [23:34:27] i am running 1.31.7 on debian and would like to upgrade to 1.34. I am currently using the debian repositories. How can I migrate+upgrade to the latest tarball? [23:35:16] hold on, gonna reconnect [23:41:07] I'm not sure there's a particular supported/documented migration path [23:41:16] Shouldn't be overly difficult though [23:41:28] I presume removing the debian mw package won't kill the db [23:41:53] So adjust/recreate the apache config, and point it at the same database [23:42:59] Hm [23:43:06] I'll make sure to take a backup of /var/lib/mediawiki [23:44:08] btw i noticed /usr/share/mediawiki has the same content as /var/lib/mediawiki on my debian install, what gives? [23:44:16] neither are symlinks [23:45:02] Based on https://packages.debian.org/buster/all/mediawiki/filelist [23:45:07] The latter would look to be symlinks [23:45:18] oh interesting