[00:01:58] Where are you running it from? [00:02:12] a vps 167.71.128.92 [00:02:31] no, sorry [00:02:34] I mean, what directory are you in [00:03:04] oh right, /etc/httpd/conf.d [00:05:50] Is that where your mediawiki install is? [00:05:53] I imagine it's not... [00:05:56] Or rather, shouldn't be [00:07:41] looking [00:10:51] Reedy, okay so mediawiki-1.34.2 is in /root. This is likely incorrect. Does is have to be in my public_html of my domain that's hosting it? Makes sense to me. [00:11:06] That would make more sense [00:11:15] hey! :) [00:11:18] haha [00:11:41] I'm so pumped to get this going. [01:27:03] So when I run, "php maintenance/install.php" I see all the config options, kinda looks like a man page. What do I do know though? Sorry still learning on the fly here. [01:27:29] There's a web installer [01:27:43] Which probably is more useful as it leads you through the process [01:28:31] i saw that, can't though im installing on a vps. I wonder if lynx would work though [01:31:23] your vps isn't running a webserver? [01:31:33] how do you plan on *using* the wiki once it's installed? [01:31:45] webserver is working [01:31:57] right, so point your browser at where the wiki files live on it [01:32:00] and it'll take you to the installer [01:32:17] you don't need to do it from localhost [01:32:39] (better not to, so it can properly detect the domain name you want to use for the wiki) [01:33:57] I don't have a browser, i'm using cli [01:34:42] the browser on your machine at home or whatever [01:35:06] I think you are misunderstanding how webservers work [01:35:47] 1) upload files to server in web-accessible location, 2) open up browser on local computer, 3) point browser at the webserver [01:36:01] it'll show a splash screen saying that MediaWiki isn't installed with a link to the installer [01:36:21] I see [01:37:21] In the same way google isn't running on your local machine [04:15:03] If I have a wiki that uses meta.wikimedia.org OAuth for authentication, I go to the URL https://meta.wikimedia.org/w/index.php?title=Special:OAuth/authenticate&oauth_token=49ee52bb92fde6643b47fd9fd806c57c&oauth_consumer_key=83a56b90dda04cd3b998bc122781cf3f and I get this: [04:15:16] "Application Connection Error: OAuth callback URL not found in cache. This is probably an error in how the application makes requests to the server." [09:49:32] hare: wrong oauth_token parameter in the URL where you send the user to authorize? [14:21:19] Hi, I'm using APIGetAllowedParams hook to change the PARAM_MAX 1 and 2 limits to be able to make bigger queries. I can see on my logs that the limits are being changed, but my queries are still limited to 500 titles [14:22:03] Ah, I'm talking about action=query prop=info queries [14:23:45] I'm pretty sure this is hardcoded in the code, and you're most probably doing it wrong by trying to increase that limit [14:24:52] It might depend what module it actually is [14:24:57] some do stuff like [14:24:57] if ( ++$count > $params['limit'] ) { [14:25:32] I'm doing under a condition that the module must be 'query' [14:26:31] Vulpix: but I understood that the hook was tailored specifically to change those hardcoded limits, not? The docs in this hook are very bare, unfortunatelly [14:27:26] * Get final list of parameters, after hooks have had a chance to [14:27:27] * tweak it as needed. [14:28:32] Most extensions tend to use it to add extra parameters [14:28:39] But in theory, changing limits should work [14:31:31] I see. From the logs I can confirm the change, but the queries are still limited. [14:37:12] What logs? [14:37:15] Which queries? [14:38:43] I'm logging the params from inside the function registered to the hook [14:39:36] the query I'm doing is action=query prop=info with multiple titles separated by pipes from a browser logged on the wiki as sysop [14:40:36] I see now that PARAM_MAX1 and 2 can not be used with PARAM_ISMULTI [14:45:53] uhm, I think I was looking at the wrong constant. The one I need to tweak with is LIMIT_BIG1. [14:50:57] lol [14:50:59] probably [14:51:28] Let me insist you're probably doing it wrong if you want to parse/query more than 500 titles in one single query [14:53:35] Vulpix: thanx for insisting and being straightforward :) Its just for testing purposes. [16:04:26] Hi. What is the message to edit the block reasons? [16:20:56] Esteban16: MediaWiki:Ipbreason-dropdown is one [16:21:09] the only one? [17:42:58] Hi, everyone! I uploaded a new version of a file to a server running mediawiki, and all the new info (e.g. dimensions) showed up fine in the new version, but the actual image it showed was still the old version. I reverted the change, and suddenly could see the new image in the history; but when I reverted to that version, while I could still see the new image in the history, the old image was the one [17:43:04] that showed up in the new reverted version. Can anyone help me figure out what's going on? I'm happy to link to the image page on my server if that would help. (I'd tell you what version of mediawiki I'm using, but I can't find it on the web interface, and I've been carrying LocalSettings.php over, with slight modifications, from version to version, so its header still says it was automatically [17:43:10] generated by v. 1.18) [17:46:31] Shmo: not about the actual problem you are facing, but concerning wiki version, you could always check the version by going to url/Special:Version on your wiki. [17:47:22] Oh, perfect, thank you! I'm using version 1.27.7 [17:49:13] No problem :) [17:59:47] Tried purging the page? [17:59:48] !purge [17:59:48] To purge a cached page, such as when making changes to the navigation bar, add &action=purge to the end of the page url, or ?action=purge if using Simple URLs. E.g: http://en.wikipedia.org/wiki/Main_Page?action=purge [18:08:07] I just tried that, wm-bot , and the image shown is still the old version. I've also tried loading it at different resolutions, and I see the old image in each of them. (That is a very useful function I didn't know about though, so thank you!) [18:08:08] Hey Shmo, you are welcome! [18:08:48] Oh, Reedy , I should have highlighted you there, not the bot! [19:25:36] Shmo: Are they resolutions of the image that already exist on disk? [19:43:53] addshore: Amir1: simplebago key error is back https://logstash.wikimedia.org/app/kibana#/doc/logstash-*/logstash-deploy-2020.07.15/mediawiki?id=AXNT__UxNoG2jwpwz7WY&_g=h@44136fa [19:44:05] Cache key contains characters that are not allowed: `L:L8885_1110408616_en_label` [19:44:18] (backticks, I think) [19:48:17] Reedy: yes; now that the version when I uploaded it is not the "last" one, it shows the new image. But a revert to it, while it's the "latest" version, still shows the old one. I might as well just link you to it so you can see the issue: http://wiki.chulsky.com/mediawiki/index.php/File:Leizer_Krupitsky_c1900.png [20:10:41] Krinkle: :((((((((( [20:21:42] Krinkle: I let our camper Michael know, they probably fix it soon hopefully [20:23:34] Krinkle: btw. I'm sorry about this spam, it's my fault: https://logstash.wikimedia.org/goto/a7a427d56748e1c4fff8abff8139a837 I will fix it soon [20:23:45] T258065 [20:23:46] T258065: wikibase.Site RL module can not be registered twice - https://phabricator.wikimedia.org/T258065 [21:05:56] I'm sorry, I got kicked off! Is there any place where I can look at channel logs to see if my question was addressed while I was gone? [21:10:43] Shmo: https://wm-bot.wmflabs.org/logs/%23mediawiki/20200715.txt [21:10:57] i think no one replied, unfortunately [21:33:34] Shmo: what's exactly the problem? [21:33:39] which image should be showing? [21:33:52] note you may need to bypass your browser's cache [22:04:18] That's a common problem with images. You either configure your webserver to send them always with cache-control: must revalidate, or use an extension like this (requires adding rewrite rules) to have versioned URLs for files https://github.com/ciencia/mediawiki-extensions-WikiDexFileRepository [23:35:09] Thank you, MatmaRex ! [23:40:45] Platonides: I tried bypassing the browser cache almost immediately when the problem came up, and was pretty surprised when that wasn't the issue. The image I want showing is http://wiki.chulsky.com/mediawiki/images/archive/2/26/20200715172659%21Leizer_Krupitsky_c1900.png , but it only shows in old versions; if I revert an old version with the image I want to make it the current version, it still shows up [23:40:51] as http://wiki.chulsky.com/mediawiki/images/2/26/Leizer_Krupitsky_c1900.png , even though the dimensions in the table indicate the image I want [23:50:10] Wow, I am SO sorry, everybody! You were all right and I was wrong. I was just absolutely sure that Ctrl-Shift-R was enough to bypass the browser cache, and apparently, it wasn't. Mediawiki was working perfectly. I just kept refreshing, thinking I was bypassing the cache, and scratching my head, sure that wasn't the issue. I'm sorry again, and thank you for instantly identifying the correct issue [23:50:16] despite my resistance! [23:52:35] Shmo: i think this is actually a somewhat common problem… we have this bug about it: https://phabricator.wikimedia.org/T38380 [23:53:03] mediawiki could be cooperating with the browser caches better than it does [23:53:32] (sorry, i have not actually read your messages until now :D) [23:56:33] Oh, wow, yeah, that's exactly the issue! FWIW, I don't see it as a problem with mediawiki; I didn't realize browser caches are quite so persistent, and to me, that's the problem [23:57:38] Vulpix nailed it with the cache-control header too