[00:15:41] I enabled the logging into a file and can see the server does received the API request, I pasted log here: https://pastebin.pl/view/57723574 [00:16:10] see the last line it has the "readapidenied": "[DBQuery] LCStoreDB::get [0s] 127.0.0.1: SELECT  lc_value  FROM `mwdd_l10n_cache`    WHERE lc_lang = 'en' AND lc_key = 'messages:apierror-readapidenied'  LIMIT 1  " [00:17:08] any idea what the problem is? tgr_ Reedy [00:17:34] that's just doing a cache lookup for a message string [00:17:48] [DBQuery] is the log channel [00:17:54] look for OAuth or session there [00:18:29] or you can configure it so those go to separate files [00:38:36] a lot of stuff there if just search for oauth.. [00:38:44] any particular string i can look for? [01:16:39] also I just upgraded mysql to 5.7 for another wiki instance, and run update.php again, it seem successful this time, but still getting this error when trying to create a oauth 2 record [01:17:44] https://pasteboard.co/iCgL9QAEnqYL.png [01:19:40] paulx: does OAuth require a file somewhere ? [01:19:56] it looks like so [01:20:30] I did find a disucssion here about same issue: https://www.mediawiki.org/wiki/Talk:OAuth/Owner-only_consumers [01:20:43] but after trying the fix, it still doesn't work [01:20:44] sounds like you are not setting $wgOAuth2PrivateKey / $wgOAuth2PublicKey [01:21:09] would be less hassle to just not use RSA-based apps, though [01:21:30] how to not use RSA-based apps? [01:21:41] I did not want to if possible :) [01:22:09] I didn't check the checbox to use keys when creating the oauth 2 record [01:22:18] Just leave the RSA field empty when you are registering your consumer. [01:22:23] you the variable description is that it is used to sign JWT tokens [01:22:48] I guess it would be nicer if the extension disallowed that field in the first place if the variables are not set. [01:23:16] hm right, the OAuth 2 implementation does that [01:23:37] tgr_ interestingly i just looked it again, it seems the RSA field is no longer there after the upgrade... [01:24:01] we only support it for OAuth 1 I think. [01:24:26] Anyway sounds like you will need to provide those keyfiles then. [01:25:00] ok, I did generated the key files by following the suggestions here: https://www.mediawiki.org/wiki/Talk:OAuth/Owner-only_consumers [01:25:29] but which folder should I put them to? it seems no matter where I put them, it keeps saying cannot find the key file [01:26:40] Up to you, just make sure it is readable to PHP and the config variables point there. [01:27:37] in the wgOAuth2PrivateKey and wgOAuth2PublicKey, should I use absolute path? [01:28:03] or relative path? if relative any idea relative to which folder? [01:28:10] (And that they aren't accessible from the internet. From a security POV, the private key file will be equivalent to your user passwords database more or less.) [01:28:43] ok [01:28:47] Absolute, sure. Relative to the MW installation would probably work if you really need to use a relative one. [01:29:22] sounds like ideally i should put it to somewhere outside of the public_html folder? [01:30:53] should I create a new folder for them at same level as "usr" or "var"? [01:37:24] Up to you really. Could put it under something like /etc/mediawiki, or /var/mediawiki, or just some top-level folder. Just make sure PHP can see the files in both web and CLI mode and that they aren't easily accessible by a malicious user. [01:38:29] here is what i just did: created a folder called "oauth" at same level as "usr" or "var" "etc" and ftped the two key files there, basically the very root folder on the server, the chmod them to 600 for the folder as well as the files, then I tried to create an oauth2, getting this error : "Could not retrieve access token: Key path [01:38:29] "file:///oauth/oauth.key" does not exist or is not readable" [01:39:10] stupid question, how do i make sure php can see the files? [01:39:13] Yeah, the user MediaWiki has access to is probably something like www-data [01:40:23] it really depends on your setup - you might need to chown the files to that user, or do per-user or group-based access management, or worst case just make them world-readable [01:44:58] just make sure I understand, you mean the user name who needs to read the key files is "MediaWiki"? [01:45:58] no [01:46:41] since it is saying "Key path "file:///oauth/oauth.key" does not exist or is not readable", if it is not path issue, how do I make sure it is readable to the wiki? [01:51:29] the answer will differ depending on what kind of server you use, what kind of access you have to it, what your web server is... [01:52:44] typically the web user will be called 'www-data', and then the CLI user will be either that or 'php'. But it might be anything, depends on how the server is set up. You could check who owns the files created by MediaWiki (e.g. in its uploads directory). [02:56:04] tgr_ it is a vps server and I have root access, web server is apache [03:16:00] That's not really enough info. Apache will use different shell user depending on how you installed it [03:16:19] but there is probably an 85% chance the user is named www-data [03:18:34] So there is an 85% chance you want to run a command like: chown www-data /oauth/oauth.key [03:29:32] thank you, let me try it [03:30:31] says "chown: invalid user: `www-data'" [03:33:07] Then its probably some other user [03:33:14] Other common choices are apache or apache2 [03:34:23] The command ps ax -o cmd,euser | grep apache [03:34:28] might also help you figure it out [03:35:05] You could also look in you /etc/passwd file to see if there is a username that sounds web server-ish [03:36:18] I just went into the "OAuth" extension folder and did this to a file "ls -l gitinfo.json", and it shows this "-rw-r--r-- 1 servidz servidz 282 Jan 28 22:26 gitinfo.json" [03:36:36] servidz is my admin account, so does that mean the user should be "servidz"? [03:36:45] Usually the web server would run as a different user than what your user would be [03:37:11] ok [03:37:18] Web server can access that file because its marked world readable so all users can [03:37:46] if you wanted you could make the oauth key also world readable, although typically people don't do that as they want key files to stay secret [03:38:06] well, let me make it world readable [03:38:15] for now, just to rule out other possible issues [03:39:11] you can do that with chmod 644 /oauth/oauth.key [03:39:27] If it still doesn't work, it might be due to permissions on the directory it is contained in [03:40:30] just chmod 644 for the files as well as the folders, still saying "Could not retrieve access token: Key path "file:///oauth/oauth.key" does not exist or is not readable" [03:41:03] these two files are at the one of the root folder "oauth" [03:42:05] paulx: For directories you usually want 755 not 644 [03:42:35] because the execute bit has a different meaning for a directory, and its important that its set on directories (but you don't want it set on files) [03:43:24] "Your OAuth 2.0 client has been created. ", BEAUTIFUL and FINALLY! [03:43:57] Thank you! bawolff, and tgr_ and Reedy for helping me troubleshoot! [03:47:22] and Postman is also able to make the call now! [03:48:46] just curious, the oauth 2 token doesn't need to be refreshed and I can use it for every API call? [03:49:05] If you’re chowning on Apache you need to do “www-data:www-data” iirc? [03:49:58] Owner-only tokens don't expire. Normal tokens expire after a few days by default, I think. [03:50:11] tgr_ got it! [03:50:46] One hour actually. It can be set via $wgOAuth2GrantExpirationInterval [03:51:07] and $wgOAuth2RefreshTokenTTL for refresh tokens [03:51:18] OriginalAuthorit: if you're on a debian based distro that is correct, other distros, maybe, maybe not [03:51:29] it is a owner only token so I think I am good now [03:52:25] CoughUbuntuIsTheGreatestLinuxDistro [03:54:50] now I am wondering is it a big security problem if I keep the keys word open? the folder is a few levels above the public_html folder [03:55:08] *world open [03:57:00] paulx: If it is a shared server, then yes [03:57:19] If you're the only user of the server - its still not great, but its not as big a deal [03:58:24] and honestly, I wouldn't worry too much about it [03:58:49] it is a vps so not sure that is considered shared or private? [04:06:25] that's private [04:46:48] sounds good [04:56:39] Sorry! This site is experiencing technical difficulties. [04:56:40] Try waiting a few minutes and reloading. [04:56:40] (Cannot access the database: Cannot access the database: No database connection (localhost)) [04:57:00] Sounds like mediawiki cannot access the database! [04:57:09] I ma getting this error what should I do [04:57:23] is this your own wiki or just one you are visiting? [04:57:45] ya my wiki running with docker [04:58:07] Most likely the database server is not running [04:58:28] I don't know anything specific about docker, but if mysql is in a separate container make sure its on [04:59:00] ok Ill try Is there any video for local setup [04:59:07] if you are use the dev docker setup, normally that uses sqlite which wouldn't have a db server [04:59:19] in which case the error message is very weird [04:59:28] would maybe indicate a config error or something [04:59:52] I'm not aware of any videos. I was actually thinking about making some, i think it would be good [05:00:23] * bawolff is not familiar with the docker image, so my advice is kind of generic, maybe someone else who knows more about that specificly can help you [05:00:58] ya okay [05:01:13] Hi [05:14:07] The environment has been checked. You can install MediaWiki. [05:14:08] A LocalSettings.php file has been detected. To upgrade this installation, please run update.php instead [05:14:30] I am getting this error with docker what should I do [05:14:56] The environment has been checked. You can install MediaWiki. [05:14:56] A LocalSettings.php file has been detected. To upgrade this installation, please run update.php instead [05:16:31] I am working on this issue : https://phabricator.wikimedia.org/T326905 [05:16:31] I am unable to find the file I need to start working on [05:16:32] I have reproduce the issue locally in my machine [05:16:32] Can anyone help me with this [05:17:00] Also is it right place to ask issue related doubts [05:18:19] Ayush: That doesn't sound like an error [05:18:37] Ayush: you are browsing to the wrong spot probably [05:18:52] I am trying to setup locally [05:19:14] Ayush: The message you got means it is already setup [05:19:40] what url should i visit [05:19:47] Ayush: you probably need to remove /mw-config from the url [05:20:43] wow, T326905, perhaps this is inappropriate to say, but how the hell is "page doesn't work with unicode characters" a "good first task" and not an "unbreak now" issue [05:20:43] T326905: NearbyPages no longer works for articles with non-ASCII letters - https://phabricator.wikimedia.org/T326905 [05:20:47] I am tryin localhost:8080 its not coming up [05:22:17] Hi, I would like to know if there is any script to mass promote users? like createAndPromote.php [05:22:42] !e ImportUsers [05:22:42] https://www.mediawiki.org/wiki/Extension:ImportUsers [05:23:28] huh, marked not maintained, but there's patches to fix it that are pending [05:23:37] so i guess that's a bad link [05:23:55] Guest21: Suppose you are stuck using a shell script or something, sorry :( [05:25:03] Nikhil61: Do you know where the mediawiki files are in general? [05:26:00] In will probably be in something like extensions/NearbyPages/resources [05:26:01] no it is my first issue on media wiki and I am still trying to be familiar to codebase [05:27:45] yup in resources directory there is ext.nearby.scripts. I think I should start from here [05:28:18] Yeah, based on the task description, it is probably something javascript related [05:28:26] so it will probably be something in there [05:28:41] okk thanks a lot [05:29:13] @wm-bot  thank you. Will this work for users already registered? [05:29:13] Hey Guest21, you are welcome! [05:29:36] Ai apocalpyse is upon us ;) [05:30:05] Guest21: Umm, i think there was an option for changing user groups of already registered users, although i haven't tried it [05:31:00] bawolff thank you for replying. I'll check. [05:31:54] Is it in the same extension? [05:32:20] Guest21: yeah, there was like an extra checkbox or something to override existing users [05:32:27] although it might also change their password too [05:32:30] I'm not sure [05:32:56] you honestly might be better off with a shell script and createAndPromote.php [05:34:00] I'm aware of createAndPromote.php and it works well but have no idea about the shell script. [05:36:29] Guest21: if you have some file with a list of users, one per line (any spaces in name replaced with underscore), you can do something like: [05:36:43] Guest21: for user in `cat listOfUsers.txt`; do php createAndPromote.php --sysop --force "$user"; done [05:51:49] okie guys I run into another problem, now I am able to create the oauth 2 record, but the postman still getting error "You need read permission to use this module."... earlier I thought it worked but I just realized that on that test instance I did't lock down the wiki, so it is public, no wonder the API worked... [05:52:20] the production wiki is a private one and we use "$wgGroupPermissions['*']['read'] = false;" to disable visitor from viewing contents [05:52:33] I feel this is what is causing the problem? [05:57:38] If you're logged in with oauth, that should give you read rights [05:57:49] it could indicate that the oauth handshake didn't work maybe [05:58:01] or maybe the oauth bot was not "granted" read rights in its config [05:58:13] * bawolff not that familiar with oauth2, so treat those as guesses [05:58:39] If the OAuth header is not completely broken and the handshake isn't working, you should get an OAuth-specific error. [05:59:03] (Not completely broken: There is at least an Authorization header with 'Bearer' as the type) [05:59:38] either the user doesn't have read rights or the app/consumer does not have the basic rights grant [06:00:50] I don't know if we ever tested OAuth on a private wiki but I'd be surprised if it didn't work, the way it's hooked into the system doesn't have much to do with permissions [06:01:27] I tried to add this "$wgGroupPermissions['bot']['read'] = true;" in Localsettings.php but it didnt change anything, i also thought the API call is considered a bot operation? bawolff [06:01:55] No, bot is a user-right applied to accounts. it doesn't matter if the access is via api [06:02:19] I just commented out this "$wgGroupPermissions['*']['read'] = false;" and Postman is able to get response successfully, so clearly that is what is causing the problem [06:02:28] ok [06:03:30] since when I comment out this this "$wgGroupPermissions['*']['read'] = false;"  the API works, I guess that can rule out the oauth handshake issue? tgr_ [06:05:07] when creating the oauth2 consumer i have made my admin user as the owner and also make sure the Basic rights checkbox was checked [06:11:07] I have to hard refresh the whole page when i edit files to see the changes [06:11:08] I have docker setup for mediawiki [06:11:08] is there something similar to hot reload in mediawiki ?? [06:12:23] usually its browser cache that is the biggest issue [06:12:30] sometimes editing LocalSettings.php helps [06:13:09] for example in nearby pages i changed description of card to my name but to see this changes i have to reopen the page in another browser [06:13:27] bawolff okk i will try it [06:13:29] Opening up the specific JS page, and hard refreshing that can help [06:13:40] * bawolff mostly a php backend person, so there might be other tricks i don't know [06:14:07] Also, adding ?debug=1 to the url changes how things are loaded, but it changes like a billion things so it might have other effects [06:18:12] on a site note of the oauth issue, I found the categories turns into a red URL when in Editing mode, after upgrading to 1.39, any idea what is causing this? here is the screenshot: https://pasteboard.co/bi0PjfnAQCvC.png [06:19:05] paulx: Weird with the url parts. Are they like that on normal (non-edit) view? [06:19:43] no on normal view it is look good: https://pasteboard.co/EgRDHAKZP4gT.png [06:19:55] paulx: There's a part of the upgrade script that is flakey if you are upgrading from 1.34 or earlier that can cause pages to dissappear, but i don't think it looks like what you are posting [06:20:24] paulx: As a guess, i would say something wrong with VisualEditor extension, maybe try upgrading it to see if that helps [06:20:28] bawolff thanks again hard refreshing the page works [06:20:29] i just have to press ctrl + f5 [06:20:32] I upgraded from 1.35 [06:20:49] But I've definitely never seen anything like your screenshot before [06:20:59] let me try ugprading the VE [06:21:14] I guess it could be some weird config issue with $wgArticlePath and friends that is somehow only affecting VE [06:25:28] let me see if using the latest VE will fix it [06:26:08] meanwhile any thoughts on the oauth issue? wondering what options I have? [06:28:23] any other way to disable visitors from viewing pages other than using $wgGroupPermissions['*']['read'] = false ? [06:31:58] I would suggest maybe doing a query like api.php?action=query&meta=userinfo&uiprop=rights as the bot to find out what rights it actually has [06:35:51] hmm let me try that [06:36:25] when you say "as the bot" is there anything else I need to add in the API call? [06:37:58] I just mean, do it via oauth so you can see what your bot would see [06:38:11] If you did it as a normal user, you would just see what it would be for your own user [06:38:32] got it [06:38:44] * bawolff going to bed. Best of luck [06:39:44] thank you very much! good night! [06:39:56] hit the rest.php/oauth2/resource/profile endpoint, that should fail if OAuth is not working [06:44:54] tried this and got this: [06:44:55] api.php?action=query&meta=userinfo&uiprop=rights [06:45:02] sorry, got this: [06:45:03] "userinfo": { [06:45:04]             "id": 0, [06:45:04]             "name": "71.249.96.7", [06:45:05]             "anon": "", [06:45:05]             "rights": [ [06:45:06]                 "read", [06:45:06]                 "createpage", [06:45:07]                 "createtalk", [06:45:07]                 "writeapi", [06:45:08]                 "viewmywatchlist", [06:45:08]                 "editmywatchlist", [06:45:09]                 "viewmyprivateinfo", [06:45:09]                 "editmyprivateinfo", [06:45:10]                 "editmyoptions" [06:45:10]             ] [06:45:11]         } [06:46:26] tgr_ should the full end point be this? https:///w/rest.php/oauth2/resource/profile? [06:47:11] depends on your configuration, but usually yes [06:47:19] <[1997kB]> paulx: could you please stop direct copy paste and use pastebin? [06:47:41] sure, sorry for that [06:47:53] in any case the other API response indicates that you are not actually using OAuth [06:48:14] how do you tell that? [06:50:24] tgr_ this is the response when trying the oauth2/resource/profile endpoint: https://pastebin.com/Vdj99r1b [06:51:01] ugh why are we returning a HTML response for that [06:52:28] MediaWiki has been installed. [06:52:40] that looks like your wiki's main page, not an API response [06:53:36] tried again, see this one: https://pastebin.com/QkHm6SKK [06:53:53] used this end point: https:///rest.php/oauth2/resource/profile [09:49:15] why /wiki/London not working in local setup [09:49:15] something similar to https://wikipedia.org/wiki/London [09:49:16] does I need to install extension for it in mediawiki?? [09:57:53] What does this mean exactly [09:58:26] !shorturl | Anonynomous [09:58:27] Anonynomous: To create simple URLs (such as the /wiki/PAGENAME style URLs on Wikimedia sites), follow the instructions at or try the new beta tool at . There are instructions for most different webserver setups. If you have problems getting the rewrite rules to work, see !rewriteproblem [09:58:48] Do you mean [[Manual:Short URL]] maybe [09:59:41] Oof [09:59:41] Link: [09:59:42] https://m.mediawiki.org/wiki/Manual:Short_URL [10:00:12] * Link: https://m.mediawiki.org/wiki/Manual:Short_URL [10:04:20] I do not want to create my own urls I just wanted to know like when i google search London [10:04:21] in the same way how can i serach about London in local setup of mediawiki [10:12:48] Have you tried the search bar [10:16:54] i think i am confuse little bit [10:16:54] thanks for replying [10:39:06] Izno: Found it [10:39:21] `[style*="background" i] { background: inherit; }` and `[style*="color" i] { color: inherit; }` [10:40:46] Fascinating... I have NEVER used these before [11:00:25] Would anyone help me how mediawiki deals with URL decoding? this is related to issue https://phabricator.wikimedia.org/T326905 [11:54:06] Ignore the last message [11:54:06] I have resolved this issue. I have worked with git and GitHub but new to phabricator [11:54:07] How to submit patches for the issue?? [12:07:57] @Nikhil61 Wikimedia uses gerrit (a review system also used by Google Chrome for instance). Its a little bit different than github/gitlab. [12:08:02] There is a full tutorial here: https://www.mediawiki.org/wiki/Gerrit/Tutorial [12:09:13] then phabricator is used for what?? [12:09:13] The issue that I solve is on phabricator [12:11:47] TheDJ1626[m] [12:17:44] Phabricator is for task tracking, Gerrit is for code review [12:18:03] okk thanks a lot [14:11:47] tgr_ good morning, still trying to figure out the oauth2 issue, tried API call to rest.php/oauth2/resource/profile and got this response: https://pastebin.com/QkHm6SKK [14:12:08] does that mean the oauth authentication actually fialed? [14:14:26] I dont quite understand why it says ""message": "Header value can not be an empty array.", the header clearly has value, see this screenshot: https://pasteboard.co/pChTL4qDeF4m.png [15:25:11] MatmaRex: are you ok with my changes to https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalUserPage/+/883650 ? if so, I'll +2 [15:41:29] legoktm: yes, thanks [15:41:52] thank you!! [15:45:39] it looks like no matter what I try, the "Authorization" header value is not passed to the wiki... I tried both postman and in python, and then looked the log on the wiki, in the log it shows the GET request header has "ACCEPT: */*", "ACCEPT-ENCODING: gzip, deflate", "CONNECTION: keep-alive", etc, but just no "Authorization: Bearer [15:45:40] eyJ0eXAiOiJKV1QiLC....", anyone has idea what is going on? [15:46:58] but on Postman side under console, it clearly has passed the token "Authorization: Bearer eyJ0eXAiOi..." in headers... [15:48:18] and it doesnt matter whether I comment this out or not "$wgGroupPermissions['*']['read'] = false;", so it seems nothing to do with user roles or permission, it is just some how the wiki refuse to read the Authorization header??? so strange.... [15:49:12] any one know what else I can try..? [15:53:46] could you have some middle proxy stripping it out? [16:00:04] Nothing I am aware of... [16:00:24] you mean the home router can do something like that? [16:03:27] I was thinking more like apache or nginx on the server [16:04:53] ok, i don't think I have ever did anything close to that on the server.. [16:11:55] probably not then [16:12:39] I'd consider trying to see if you have the same problem with CLI `curl`, double check you copy pasted the token correctly (I know), just to eliminate each possible point of failure [16:21:26] just tried curl, getting same error "{"error":{"code":"readapidenied","info":"You need read permission to use this module.","*":..." [16:26:43] and also doubled check to make sure the copy paste are good. [16:29:24] this is the log that showing no Authorization value in the header using curl: https://pasteboard.co/FtYkWo84ZpDi.png [16:31:07] is this a bug? can someone let me know how to report this? [16:52:01] ok I just created a bug for this oauth issue, https://phabricator.wikimedia.org/T328336, I really hope it is not a bug, and it is still likely is not, but I have tried all I can I am going no where and can not sleep well now, lol... Hope someone can help to look into it soon! Thank you everyone! [17:23:32] bawolff -> good first task/UBN -> A non-essential service that only 2% of our users even know about, at most. 🙂 Doesn't really defend anything on the point, but that's probably why it's not UBN. [17:25:34] Seddon, yeah, not exactly recommended since they're "slow" selectors, but could maybe be a solution. [19:48:35] paulx: that sounds like an issue with your web server, which MediaWiki has no control over. Some debugging steps I'd try: curl in verbose mode (-v), both from the outside and from within the VPS box; setting up a debug entry point with just phpinfo() in it and checking the headers via that; maybe the --trace-ascii curl option. [19:55:13] "`[style*="background" i] { backg..." <- What is that supposed to accomplish? You can't override inline styles from a stylesheet. [19:55:41] Without using !important, anyway, but that creates all kinds of messes. [20:01:54] tgr: dark mode [20:02:20] it was an idea and I said originally that I have no idea if it works [20:02:38] you can add !important if you want to each of those statements [20:02:56] to, er, make it work [20:03:31] (it was assumed that one could add specificity arbitrarily if one wanted) [20:13:43] Seddon and I have been having a discussion in wp-en-admins that really probably should have been in here :^) [20:17:16] If it actually does work, that is kind of an impressive hack [20:20:45] `!important` is weak, use js to apply styles :kappawiki: [20:22:31] lynx has a built-in dark mode support for wikipedia [20:29:25] Izno: layering overrides specificity for CSS selectors: inline always wins regardless of specificity, except for !important where inline always loses regardless of specificity. [20:30:47] !important reverses order/layer rules (e.g. user styles beat website styles, but !important website styles beat !important user styles), which is not how people tend to think of it and can be very confusing. It's best to not use it when possible. [20:30:47] !important is a keyword in CSS to override conflicting styles [20:31:31] (shouldn't the bot command be !!important?) [20:31:43] ⬆️ [20:32:13] There's also inline `!important` [20:39:25] tgr: I think it's fine to use "specificity" as inclusive of !important in casual speech. I'm quite cognizant of what it does. [20:42:14] The point is, you cannot override inline rules without using !important and you probably should not use !important. So that inherit hack doesn't seem like a good idea in practice. [20:44:16] I didn't say it was a good idea. It was decidedly in the realm of terrible, and I said as much to begin with. [20:44:40] I don't think dark mode is ever going to work without overriding styles [20:45:28] And if the concern is "inline styles are as much a sin when it comes to dark mode" (which it explicitly is), then let's be inventive and look at what we can do in CSS. [20:46:10] Since the desire is explicitly "override rules that may be set where we can't do anything about them systematically". [20:48:15] Ideally they would be moved to template styles but I suppose that's not very realistic for the entire wiki. [20:48:54] Yes, there are many ad hoc styles that can't be as well. [20:49:38] The existence of {{color}} is my favorite to trot out. [21:00:08] Hi :) is there a way to serve precompressed files with mw? Things like CSS and js. [21:00:54] https://www.mediawiki.org/wiki/ResourceLoader [21:01:01] does minimization [21:01:07] but not compression [21:01:40] if by compression you mean 'replacing sanely named variables with 'a', 'b', and so forth'. [21:05:22] I mean, you can implement a RL custom class module to do so, if you wanted [21:05:38] I'm assuming by compression you mean gzip or brotilli, etc [21:10:13] Yea. Sidecar or cached somehow. So that webserver can send it directly instead of going through PHP, or if going through PHP, don't have to compress on the fly. [21:10:56] So, if you don't want it to go through php, then you have to go outsie the mediawiki layer into something like varnish [21:11:34] inside mediawiki, the only thing sort of like that is file cache, which is kind of a bad version of varnish implemented in mediawiki [21:12:52] Forza: https://www.mediawiki.org/wiki/Manual:Varnish_caching might be helpful info [21:14:14] Hm. Thanks. Adding another layer seems a little overkill at the moment, but I'll look into it. Thanks. Going to bed now :) [22:53:43] ` [22:53:43] Deprecated: Caller from MessageCache::loadFromDB(en)-big ignored an error originally raised from User::loadFromDatabase: [1146] Table 'mediawiki.user' doesn't exist in /var/www/html/includes/debug/MWDebug.php on line 381 [22:53:43] Deprecated: Caller from LCStoreDB::get ignored an error originally raised from MessageCache::loadFromDB(en)-big: [1146] Table 'mediawiki.page' doesn't exist in /var/www/html/includes/debug/MWDebug.php on line 381 [22:53:43] [ebea971c724d0602787c65f6] 2023-01-30 22:52:50: Fatal exception of type Wikimedia\Rdbms\DBQueryError` [22:54:13] What does this mean? [22:54:14] * Deprecated: Caller from MessageCache::loadFromDB(en)-big ignored an error originally raised from User::loadFromDatabase: [1146] Table 'mediawiki.user' doesn't exist in /var/www/html/includes/debug/MWDebug.php on line 381 [22:54:14] Deprecated: Caller from LCStoreDB::get ignored an error originally raised from MessageCache::loadFromDB(en)-big: [1146] Table 'mediawiki.page' doesn't exist in /var/www/html/includes/debug/MWDebug.php on line 381 [22:54:14] [ebea971c724d0602787c65f6] 2023-01-30 22:52:50: Fatal exception of type Wikimedia\Rdbms\DBQueryError\ [22:54:14] Trying to run in Docker. [22:54:15] Well that would happen if you don't have a page table [22:54:33] It probably means something is misconfigured [22:54:42] Or your database is very broken [22:54:59] But if the database was that broken i doubt you would get far enough into running mediawiki to encounter this error [22:55:05] so i would guess misconfiguration [22:56:02] I had it running, but hadn't done anything with it. [22:56:11] Then updated the db and mediawiki containers [22:56:16] That's probably why. [23:00:44] Hello, I'm having performance issues with the mobilefrontend extension. I'm using opcache, and apcu for object cache. There's a large page on the wiki that takes about 470ms to first byte on desktop skin, however the mobile version of the page takes 2.4s to the first byte. Are there any common configuration issues that could cause this, or [23:00:44] otherwise any suggested debugging steps I could do to figure it out? [23:02:45] you're probably better off using a skin that's responsive instead of using MobileFrontend unless you need some of its specific features [23:04:10] "Then updated the db and mediawik..." <- Probably the db container, you think? I'll label it so it doesn't get auto updated. [23:06:35] xyz`: are you using a recent version? there was a bad performance issue fixed a couple months ago affecting pages with many headings or many images [23:07:25] (https://phabricator.wikimedia.org/T317070) [23:16:17] How can I make a custom infobox? [23:16:19] MatmaRex: using mediawiki 1.35 with the latest MobileFrontend. however I've just ended up deleting it as per suggestion from legoktm & enabled wgVectorResponsive, and it's working a lot better this way [23:17:01] ha, nice [23:20:28] Helmet[m]: When I try to make an infobox, it just gives me a red link to Template:Infobox [23:20:48] "Infobox" is just a template using tables, images and other wiki markup that is being transcluded on a page [23:20:48] [[Help:Templates]] [23:20:48] [[Help:Infobox]] [23:21:04] https://m.mediawiki.org/wiki/Help:Templates [23:21:13] https://en.m.wikipedia.org/wiki/Help:Infobox [23:21:22] s/m.// [23:21:40] s/m.// [23:21:42] * "Infobox" is just a template using tables, images and other wiki markup that is being transcluded on a page [23:21:56] ~~I keep forgetting the bot doesn't work here~~ [23:23:05] We used to have a bot for that here [23:25:42] There's another bot here but idk how it works [23:25:57] !help Infobox | Archimedes1560[m [23:25:58] Archimedes1560[m: There are a lot of topics you could be asking about. Besides, this bot is mostly for experienced users to quickly answer common questions. Please just ask your question and wait patiently, as the best person to answer your question may be away for a few minutes or longer. If you're looking for help pages, we moved that to !helpfor. [23:26:05] well i tried [23:26:20] !mw help:Infobox [23:26:20] https://www.mediawiki.org/wiki/help:Infobox [23:26:20] :kappawiki: [23:27:16] My wiki doesn't have an import page? [23:27:49] I'm following this https://www.mediawiki.org/wiki/Manual:Importing_Wikipedia_infoboxes_tutorial [23:27:54] Helmet[m]: When you go to the page named Special:Import what happens? [23:28:55] bawolff: Okay, there it is. I was trying to go by the URL manually [23:31:08] Okay. Now it's telling me I don't have Scribunto. [23:31:55] And you do? [23:34:10] Archimedes1560[m: Nah. I'll have to get it and install it [23:40:31] Just follow the tutorial then I guess