[02:04:39] Currently trying to figure out what the best practice would be to retrieve database info related to users and their edits within an extension. It seems like using static methods from Revision has been deprecated in favor of RevisionStore, but the only documentation I can find on that is within the autodocs. I basically want to do something similar to the EditCount extension, except within specific timeframes. Looking at the source of [02:04:39] EditCount for 1.35 (which is the version we're currently on), they use the ActorMigration class, which, from my understanding, should be deprecated by now, since the migrations should be completed. [02:05:03] hey there folks! i'm upgrading my 1.28.4 to 1.29.2. git upgrade and composer update went fine, but update.php is telling me "Some of your configuration settings caused a warning: [02:05:03] * TrackingCategories is deprecated: since 1.25 ..." i cannot find any reference to TrackingCategories or related variables in my LocalConfig, and am wondering if anyone has insight into the situation [02:06:22] this is an old wiki (launched 2008) that has gone through a great many upgrades, and i may well have cruft somewhere [02:07:30] excuse me, 1.29.3, not 1.29.2 [02:09:27] no, i did mean 1.29.2, ugh [02:09:37] well, neither revision is supported :) [02:10:29] fair enough =] i hope my questions do not suggest that i expect an answer or anyone's time [02:10:39] apologies if so [02:10:57] it seems to be the case that you have something calling $wgTrackingCategories [02:11:06] so it would be in your extension code [02:11:16] not your settings [02:12:11] good lord i meant 1.39.2 [02:12:14] not 1.29.2 [02:12:18] well that makes much more sense :D [02:12:21] i sound like a madman. my sincerest apologies [02:12:33] and from 1.38.4 I gather? [02:12:59] you grok in fullness [02:13:04] yes [02:14:27] btw this has been serving me well since version 1.12. tremendous thanks to the team [02:14:42] i love my wiki [02:16:01] Either way, you do seem to have an extension of some kind that's using the old style of registering tracking categories. [02:16:14] e.g. https://gerrit.wikimedia.org/g/mediawiki/core/+/8df7889c6ca057f36c6b478f5f9aabbebcd6d391/includes/MainConfigNames.php#3967 [02:16:36] i shall grep extensions/ and find the traitor [02:19:06] WikiArticleFeeds [02:20:36] https://www.mediawiki.org/wiki/Extension:WikiArticleFeeds does not inspire confidence [02:21:10] out of maintenance [02:21:25] i will attempt to bring this extension up to speed. in the meantime, i will disable it. thank you for your assistance! [02:21:39] It does seem to have a 1.39 release, for what it's worth. Not sure if it's actually compatible or maintained, though. [02:21:52] https://phabricator.wikimedia.org/T185837 is unclosed [02:22:03] which I gather is what is necessary to correct it [02:22:22] with the extension disabled, maintenance/update.php completes successfully, and all is bliss [02:22:38] Done in 18 s, huzzah [02:22:40] Ouch, 5 years out of date. Yeah, probably something you'd have to update yourself. [02:23:17] yep! i will look into it. for now it is disabled. alas, remaining four people using RSS/Atom [02:23:32] probably about time i lose that from the config anyway [02:23:47] alright, well thank you, and thank you team for the great work over the past two decades. <3 [02:43:19] Looking further into my database, I can see that we still have the revision_actor_temp table, and our revision table does not have its rev_actor column properly populated (they're all 0s). We're a particularly large wiki that's been in operation for ~16+ years now, and updating to 1.35 a year or two ago was a painful process in and of itself. Just wondering if there's a proper set of steps to take next, since it's hard to find proper [02:43:19] documentation on the actor migration itself. [02:43:25] I'm probably doing something stupid, but I'm loading hCaptcha and ConfirmEdit, via `wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/hCaptcha' ]);`, but its throwing an error that `Class "SimpleCaptcha" not found`; I'm confused because I'm not trying to use SimpleCaptcha? [02:46:31] You're not still doing a require('extensions/ConfirmEdit.php'); or something along those lines, are you? [02:46:37] From an earlier version, maybe? [02:46:40] nope [02:47:02] oh actually I was, fml. [02:47:05] My bad — I'm an idiot. [02:47:07] Thank you! [02:47:11] lol no prob [03:42:36] Submitted the 1.39.2 update for the docker image: https://github.com/docker-library/official-images/pull/14139 [07:36:35] Nikerabbit: I suppose I will wait until https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/889529 is merged before looking into the hooks [08:02:36] buovjaga: you may not want to wait, it's probably not progressing anywhere during the next week or two [13:08:53] Hello and BIG thanks for the MediaWiki [13:10:07] I'm having troubles running 1.39.1 -> 1.39.2 upgrades inplace with my old instructions. [13:11:26] First time I ran 'git pull https://gerrit.wikimedia.org/r/mediawiki/core.git REL1_39' it complained about being unable to unlink images/.htaccess and the 2nd time around it complains about dozens of files that "would be overwritten". The first wiki I tried to upgrade I ended up doing the major revision upgrade route of not-inplace and I got a working 1.39.2 with that method. Any suggestions [13:16:20] Doing the non-inplace will take a bit more time and effort, but I'm totally up for it. I'm just wondering why I cannot upgrade inplace with git anymore like I used to do. Maybe something has changed and I need to adapt my method or there could be something wrong on your end. Probably something on my end, it usually is [14:10:16] Why are you running git pull with the url? [14:11:37] but the images/.htaccess sounds like you already had a .htaccess (with weird permissions?) but 1.39.2 brings in one [14:17:00] Hello every one, does anyone know if a private wiki can benefit from CDN? [14:18:30] Depends what you're storing on the CDN [14:18:38] And how much traffic [14:18:44] not too much traffic [14:19:26] but I do want my users have best experience as they can [14:21:33] Adding a CDN into the mix may not actually increase performance... also cache invalidation concerns etc [14:21:58] I am currently using aws cloudfront, where it currenlty is default to "Cache everything" [14:22:06] Feels a bit like premature optimisation :) [14:22:20] but since the wiki is private, so that setting doesnt make much sense to me... [14:23:01] sounds like I better disable CDN? [14:31:50] CDNs only work if people share resources [14:31:59] That can't happen in a non-public wiki [14:32:04] At best, it might cache some JS [14:32:40] And you definitely don't want to set any setting that ignores mediawiki cache directive (Which might include cache everything), since then the public may be able to see all your private data [14:37:31] I am not familar with the details of CDN, do you mean there is a way to configure CDN for the caching to work while the wiki still remain private? [14:38:01] The short answer: no [14:38:44] The longer answer: Some resources in private wikis are still public, like MW's js files. In theory those can be CDN cached. The benefit will probably be minimal [14:38:55] on the wiki there is no sensitive data or whatsoever on the wiki, it is simply we dont want search engine to get to it... [14:39:19] and dont want people to share the contents to others that we dont know aout [14:39:22] *about [14:39:32] It still doesn't matter. In MediaWiki's architecture, CDN can't apply to logged in content [14:39:40] Even if the wiki was public [14:39:43] I see [14:40:49] Thank you for the info! [16:15:25] Hello I am completely at a loss. VisualEditor is failing with Error contacting the Parsoid/RESTBase server (HTTP 400) [16:15:47] I enabled error logging, all the stuff but all logs remain silent. [16:16:08] I even killed and reinstalled VisualEditor [16:16:21] I am on 1.35.9 using the Timeless skin [16:16:48] Anyhow, my qustion is. How can I get MediaWiki to tell me what exactly is the cause of Error contacting the Parsoid/RESTBase server (HTTP 400) [16:17:15] since this error message basically tells me nothing. [16:23:49] In the access log I get this: "GET /w/rest.php/mywiki.org/v3/page/html/MyPage/69940?redirect=false&stash=true HTTP/1.1" 400 5378 "-" "VisualEditor-MediaWiki/1.35.9" [16:24:01] I already know about the 400. [16:24:39] Have you tried browsing directly to that url [16:24:45] Maybe the error page has something in it [16:26:07] No, but it redirects me to an empty page on the wiki [16:26:46] of title "/w/rest.php... [16:35:01] karsten: That would imply that your short url config is probably the problem [16:35:28] although are you sure you did the correct url, because if you're not getting a 400, that probably means you entered a different url [16:41:44] bawolff: Yeah I was getting a bit frantic and probably entered the incorrect url. [16:42:07] however this was good enough to get me into the direction of finding a solution. [16:42:55] VisualEditor and Apache do not play well without some apache extra config [16:43:03] Found the solution: https://www.mediawiki.org/wiki/Extension:VisualEditor/webserver [16:43:16] This fixed the issue! [16:43:34] Happy now. [19:11:04] hi, how can I write literal "#1" on the beginning of a line - so that it doesn't treat it as an ordered list? [19:15:35] #1 [19:16:30] ah ok [19:16:51] #1 should also work [19:16:57] I think the former is generally more idiomatic [19:24:34] Hello, I sent question about my issue with scp on #wikimedia-dev, but I didn't get any response, so I'd like to ask here. :) [19:25:34] I got a macbook, and I tried to clone mediawiki/core repository from Gerrit. [19:25:47] git clone part went fine, but updating hooks via scp, not really. [19:25:54] This is error which I'm receiving. [19:26:08] subsystem request failed on channscp: Connection closed [19:26:24] Here is whole verbose output: https://pastebin.com/0p5r8zfA [19:29:54] Kizule: try with -O in there as well [19:32:36] moonmoon: Thanks. https://pastebin.com/xW0V9MnG [19:34:40] looks like it succeeded? [19:36:25] moonmoon: Yeah, I don't know what -O does exactly, but looks like it's working with -O. [19:37:32] -O forces it to use scp instead of sftp [19:37:54] seems that port doesn't have sftp enabled, which is why you got the subsystem request failed error [19:40:14] Okay, thank you for your help! [19:42:49] hi there [19:43:35] i'm upgrading from 1.31.6 to 1.35.9 (i know, waaay too late) [19:43:52] and got messages such as: User name "SoftCoder" is usable, cannot create an anonymous actor for it. Run maintenance/cleanupUsersWithNoId.php to fix this situation. [19:43:54] not-supported -> supported? never too late for that [19:44:26] did you take a backup? [19:44:30] you might need it [19:45:01] i've also looked at maintenance/cleanupUsersWithNoId.php --help and https://www.mediawiki.org/wiki/Manual:CleanupUsersWithNoId.php but i'm still not entirely sure what it does, and which --prefix parameter i should provide [19:45:09] sure, got a backup [19:45:34] https://phabricator.wikimedia.org/T224854 might be relevant [19:46:19] actually, that looks mroe relevant than the one I was thinking of [19:47:03] some others to look through in https://phabricator.wikimedia.org/search/query/L1a7LreOC_GJ/#R [19:48:16] hmm, so to be clear, i have not yet run cleanupUsersWithNoId.php, just because i don't know what --prefix should be set to, or what it means really [19:48:47] i also don't yet understand what the actual issue there is that needs to be fixed, or why it could have come into existence [19:49:15] could you explain this? and thanks for helping me out in the first place. [19:49:20] Have you ever imported pages/revisions from another wiki? [19:49:27] no [19:49:52] this is just our own mediawiki installation on docs.megaglest.org [19:50:03] because the underlying error is there are some rows in the DB with usernames, but don't have userids [19:50:42] could this be a result of using some extension to delete users which didn't do its job properly? [19:50:58] we're using BlockAndNuke and i suspect this might match that description [19:51:04] Potentially something like that [19:51:13] You can run the script with any prefix [19:51:49] so: --prefix '*' ? [19:52:19] MW will add a > [19:52:28] I'd probably suggest some actual text... "broken" or something maybe :P [19:52:33] as Foo will become broken>Foo [19:54:07] how about using --assign, too? because some of those users are surely ours [19:54:16] probably all of them are [19:55:19] Shouldn't harm anything... [19:56:01] but i'll have to specify both --prefix and --assign then, right? [19:56:28] If you don't apply a prefix, you'll just end up with >Foo [19:56:30] so the prefix will be assigned to users which are not found in the local installation [20:02:22] so i ran it, but it actually did nothing https://paste.debian.net/plain/1271889 [20:02:54] i guess this means that i need to read https://phabricator.wikimedia.org/T224854 [20:03:48] it updated two block rows [20:04:36] okay, but the upgrade script reorted about 20 or 30 users [20:07:12] https://paste.debian.net/plain/1271891 is the relevant output from the upgrade script [20:08:21] is it safe to just ignore this situation? [20:09:03] What does update.php do if you run it again? [20:12:49] Reedy: https://paste.debian.net/plain/1271893 [20:15:25] i should say i did run removeUnusedAccounts.php after running update.php the first time, and this did delete some 70 users, but those were different ones than update.php had reported. [20:16:23] What error is your wiki actually giving now? https://docs.megaglest.org/ [20:17:27] hmm, i hadn't spotted this [20:20:52] the web server logs have many references to disabled curl_exec, can't seem to find anything about "DBQueryError" [20:21:48] is the log file where php would write errors to the right log file to inspect or does MW write its own? [20:22:48] depends on your config [20:22:50] :) [20:22:52] !debug [20:22:52] For information on debugging (including viewing errors), see https://mediawiki.org/wiki/Manual:How_to_debug . A list of related configuration variables is at https://mediawiki.org/wiki/Manual:Configuration_settings#Debug.2Flogging Also see https://mediawiki.org/wiki/Manual:Errors_and_symptoms [20:23:28] great, thanks [20:23:44] trying to upgrade from 1.35 to 1.39 ... what am i supposed to do if i get SQL errors when running update.php? ( ERROR: index "tl_namespace" does not exist ) ... [20:25:50] @worf mysql ? [20:26:29] TheDJ1626[m]: ah - sorry - no, postgres [20:27:23] hmm ... from reading the whole stuff, it seems like it tries to drop indexes that are not there ... [20:27:25] Reedy: i think it's due to the old version still running there, but accessing the already updated database [20:27:28] ah. thats considerably less tested, so it might be that something was overlooked in a rewrite [20:27:45] tomreyn: helpful ;P [20:27:56] The next question is really "does it work" in practice [20:28:34] Reedy: i'm following the upgrade guide, it says i should run update.php before moving the new versions' files in place [20:28:53] o_0 [20:28:57] I don't think it does [20:29:10] @worf this is what the tables should look like in various versions: https://www.mediawiki.org/wiki/Manual:Templatelinks_table [20:29:46] Its probably trying to go from 1.38 to 1.39 and in the process it is trying to remove the associated index, before it removes the column. But that index was possibly never in place on postgres or something. [20:30:05] Reedy: i'm on step 5 of https://www.mediawiki.org/wiki/Manual:Upgrading#Can_my_wiki_stay_online_while_it_is_upgrading? [20:30:40] I mean, this proves your wiki can't stay online [20:32:03] i guess that's right [20:32:33] @worf i'm assuming its this migration that is failing ? https://github.com/wikimedia/mediawiki/blob/master/maintenance/postgres/archives/patch-templatelinks-drop-tl_title.sql [20:34:25] Upgrading consecutive major versions can keep the wiki online, sometimes if you enable some b/c config options and run some migration scripts after using the new version. However, this isn't always true when upgrading from LTS versions, or sometimes you need to take extra care to do this [20:35:45] When upgrading a wiki from 1.32 to 1.35 I had to comment out some database scripts executed during the upgrade to prevent the site from completely breaking while the webserver was still in 1.32 [20:36:16] Because they were removing tables or columns in use in 1.32 [20:37:10] yeah, theres been a lot of db rewrites and sometimes an add + remove since the last LTS is overlooked. Those should be reported in phabricator, so that they can be fixed for LTS upgrades [20:37:37] so... 1.35 had no tl_namespace index: https://github.com/wikimedia/mediawiki/blob/REL1_35/maintenance/postgres/tables.sql#L301 [20:37:52] 1.38 did: https://github.com/wikimedia/mediawiki/blob/REL1_38/maintenance/postgres/tables-generated.sql#L194 [20:37:56] and then in 1.39 it got dropped. [20:42:40] Reedy: so, in essence, this upgrade probably failed dur to the site remaining online, and i should redo it? [20:43:08] i'm trying to understand what my options are, and how to give you more insight into my situation [20:43:12] so ... i managed to get the upgrade script finish by removing the thwo indexes ... and now hell breaks loose trying to get ldap auth working ... [20:43:30] I doubt you had so many users "created" in the time you were upgrading [20:44:15] Reedy: so you're saying the site was already broken beforehand? [20:44:29] "broken" [20:44:42] It all worked as intended, probably [20:44:54] I'd be tempted at this stage to just update the webserver files, and see how well the wiki works [20:46:08] @worf i have filed a ticket for this as db change problem: https://phabricator.wikimedia.org/T330439 [20:46:43] TheDJ1626[m]: great! [20:46:43] @worf you mean settings wise, or also wrt a db upgrade ? [20:48:38] TheDJ1626[m]: neither. finding compatible versions-wise. this needs PluggableAuth, LDAPProvider and LDAPAuthentication2 - and depending on what version i try, i get all kinds of errors ... [20:48:48] oh god. [20:49:01] that is quite a combo indeed [20:51:11] For example - if i just let composer pick the "default" version, i get a "The supplied credentials could not be authenticated." where the login form should actually be. (like, before actually entering credentials) ... [20:53:19] unfortunately i don't know much about the ldap plugins, as i've not used MW much in business settings, where these plugins are more commonly used. [20:53:28] Reedy: does MW store its absolute installation path in the database somewhere or in a configuration file? i#m trying to point the site to the new installation (by updating a symlink) but it keeps accessing the old installation [20:53:44] i.e. https://docs.megaglest.org/ [20:54:27] You could've hardcoded something in LocalSettings potentially [20:58:45] not so, but i guess it may have been some form of caching, it's found the new directory now and i have a new fatal error (for the right directory) [20:58:51] with PluggableAuth dev-REL1_37 i seem to at least get to a login screen ... [21:00:30] tomreyn: Simplest "fix" for that for the moment may just be disable SyntaxHighlight temporarily [21:01:30] then fix your cache folder permissions :D [21:04:16] Reedy: thanks. there was another issue before that, fixing permissions was the easy one :) [21:04:33] got it running, for all i can tell - thanks so much! [21:04:46] well, more or less [21:05:22] I'm not going to say everything is fine... But it does look like it's not completely broken :P [21:07:24] ok, a few permutations later, i seem to have almost success ... now i'm getting "ERROR: null value in column "user_real_name" of relation "user" violates not-null constraint" on login. Which ... with lots of luck ... may be fixable [21:11:13] right. thanks again R33dy + 1zno (trying not to highlight unneccessarily) [21:26:35] tomreyn, I accept thanks pings, I expect Reedy does also ;P. though I like that you said it was deliberate, I'm pretty sure I've had not deliberate spellings of that one [21:29:46] :) [21:36:38] omg.. the upload checks of the installer are... incredibly naive. [21:50:08] ... what a mess ... finally got the wiki working again ... but at a cost ... [21:51:54] To get LDAP working, i had to hand pick specific git branches, and disable one failing function call, that is supposed to update user info ... [21:52:15] that's not usually a good idea :') [21:52:58] well, i will see how badly things fail, once some user info of some user changes in ldap ... [21:53:08] testing in production is the way to go [21:53:22] 100% [21:54:18] it's what enwiki is for [21:54:37] Reedy, :') [21:55:09] basically the whole history is a nightmare. I had a working setup for years, tested upgrades before i rolled them out, everything was fine ... [21:55:59] ... then i switched from ldap to oauth2, because i assumed it would be a good idea ... like users would not need to type passwords all the time ... [21:57:09] ... worked nicely for months, and then suddenly some change somewhere (which i couldn't identify), caused the users to get logged out of mediawiki all the time ... and after failing to fix that, i wanted to enable LDAP again ... [21:58:06] ... but that has descended into it's own hell since ... [22:00:44] if it was not for some extensions, i would have switched to something totally different by now. [23:19:00] Worf: this info may be way too late to help with your project, but I have found that $wgObjectCacheSessionExpiry is the magic setting for fixing short session issues in my test wiki that is using WSOAuth. -- https://www.mediawiki.org/wiki/Manual:$wgObjectCacheSessionExpiry [23:55:37] bd808: no, not too late ... actually very important ... now that i think of it: i'm not sure if i get the whole picture tough. But it explains a lot ...