[02:35:40] Heku: In [[Template:Infobox person]] check for two different lines both with |data63=... [02:57:06] There's also a "DuplicatePage" extension. [02:57:08] Or there used to be. [03:01:16] Ursula: maybe https://www.mediawiki.org/wiki/Extension:Duplicator ? [03:02:24] Yeah, that. [03:02:37] That's kinda like forking. [03:03:18] no error-free way to merge back into the main page though [03:03:25] Yeah. [03:03:30] there's [[Special:MergeHistory]] but that's not a great tool [03:03:55] Duplicator was also weird. [03:03:59] Since it like duplicated all the revisions? [03:04:09] that's what it looks like [03:04:10] I think, it's been a long time. [03:04:10] Forking and merging is really something that could use a good ext [03:04:27] bawolff: Git!!!!!!!! [03:04:53] we do live in a github world...people expect it now [03:05:21] most of the machinery already exists in mediawiki too [03:05:28] edit conflict resolution could be used as the basis for the merge [03:05:53] as well as the base UI to use when an automatic merge fails [03:06:00] Our edit conflict resolution could use love tbh [03:06:04] most of the UI work would need to go into how to represent history pages [03:06:11] this is also true [03:06:26] the db side of things is drop-dead simple [03:06:35] just make a new table to hold 2nd parent revid [03:06:52] (since altering a core table to add a new column in an ext seems like a bad idea) [03:07:32] The edit conflict resolution is crappy af. [03:07:38] It doesn't even try. [03:08:07] It tries. It just gives up very easily [03:08:26] And gives you both text areas and is just like "whatever, figure it out." [03:08:30] Which is shitty. [03:08:47] Even conflict markers would be better [03:09:16] well if we can get conflict markers we can display an intelligent UI for processing them [03:09:40] just make sure to test it on an article that features conflict markers [03:10:06] We don't need to use literal ">>>" or whatever. [03:10:56] https://phabricator.wikimedia.org/T108664 [03:11:01] We basically already have them...we just throw them away [03:11:26] we're shelling out to diff3 already which can generate them [03:11:55] https://phabricator.wikimedia.org/T120462 is quite something. [03:14:09] https://phabricator.wikimedia.org/T6745 [03:14:17] 2006, man. [04:42:04] is anyone here familiar with scribunto? [04:42:41] i'm curious about mw.loadData(), and why, if it can offer such a large improvement over evaluating on each {{#invoke:}}, it's not available as a more general-purpose thing [04:43:21] like why not have a way to mark an entire module as 'load once' [04:47:02] okdana: that doesn't make sense [04:47:09] each invoke is a separate execution context [04:47:24] loadData is for static data (as opposed to code) so it can be known to be constant in between executions [04:47:35] but code modules can have state, and state should not be shared between executions [04:48:44] can or must? [04:51:16] from the docs: "Each {{#invoke:}} call runs in a separate environment. Variables defined in one {{#invoke:}} will not be available from another. This restriction was necessary to maintain flexibility in the wikitext parser implementation. " [04:56:28] sharing variables between invocations isn't the desire [04:56:41] but since lua functions are closures i guess that's unavoidable isn't it [04:57:07] maybe i see the problem [08:35:22] I'm trying to get the MediaWiki:Common.css page through the api, but it's giving me a little html around the css (I can remove it in code, but I'm wondering what the right api way would be) Special:ApiSandbox#action=parse&format=json&page=MediaWiki%3ACommon.css [10:40:56] hello, when i trying to delete a page it shown me internal error "[W1mkIApAAEMAAAlVSH0AAACT] 2018-07-26 10:36:17: Fatal exception of type "MWException" " [10:41:40] on mediawiki.org [10:46:37] cronolio: #wikimedia-tech [10:46:49] as your topic is about a Wikimedia website [11:23:46] andre__: don't see any difference between channels :) [11:24:27] cronolio: This channel is about MediaWiki itself. [13:36:48] I'm looking for a way to add in the sidebar a link to https://domain/currentpage?action=purge (this is a private wiki, no webcrawlers that can start purging all pages when they follow the link) [13:36:55] is there a way I could do this? [13:37:47] That sort of link are usually put up at the top [13:39:14] I don't care where it is really, the reason I asked about the sidebar is because it's easy to add something through the frontend, no php edits means easy upgrade. But if you think it can be done at the top, I appreciate that too. [13:41:06] (I see an extention exists for it, so no easier method will be available https://www.mediawiki.org/wiki/Extension:Purge ) [13:41:19] There is [13:41:22] You can add it to site js [13:41:34] I have a really old example... But must be a better one [13:42:13] ah, find the id (or whatever you can grab on to) and create a button through js. Ok, can do! :) [13:42:25] https://en.wikibooks.org/wiki/MediaWiki_Developer%27s_Handbook/Add_JavaScript/Adding_a_purge_tab [13:42:42] Don't really need the comments [13:43:07] Thank you. [13:43:19] But that's ancient code too [13:44:18] I shall see if it's bitrotten, else I can do something myself. (I already do something simular) [13:44:46] https://ace.wikipedia.org/wiki/MediaWiki:Gadget-Purge.js [13:44:52] That looks a lot nicer ;) [13:45:13] Don't even need to do it as a gadget [13:45:28] finalbeta: Can drop that on MediaWiki:Common.js [14:07:28] Reedy, thank you, I ended up with : https://justpaste.it/5ujub [14:40:47] Hi. I'm trying to get https://www.mediawiki.org/wiki/Extension:Auth_remoteuser working for a wiki with an external login. Once logged in via Special:UserLogin how can I retrieve the username from the mediawiki session data from a function in LocalSettings.php to make sure the user stays logged in on other pages that are not behind the external auth and therefore do not have REMOTE_USER forwarded? [14:41:35] once a user logs in with the ext, a normal mediawiki session cookie is set which handles their logged-in session for future visits [14:41:43] there's nothing else you need to add to LocalSettings.php for this to wor [14:41:46] *to work [14:44:44] malex: LocalSettings.php is run very early on in the mediawiki request cycle, so you're very limited as to what kinds of code you can put into there. At the time it's run, the user's session is not yet established nor is any user object set up [14:44:58] so, it's not a great spot to do different things depending on logged-in status [14:45:03] Skizzerz: Unfortunately, Auth_remoteuser requires setting of wgAuthRemoteuserUserName either straight from REMOTE_USER or from a php closure. So, it overrides whatever mechanism mediawiki has for keeping a user logged in with whatever I put into that closure. I am just trying to find out how I can retrieve the username from the mediawiki session. A pointer to the docs would be great. [14:46:45] E.g. here's the closure I use, which works great for private wikis as every page there is behind SSO, which provides REMOTE_USER and REMOTE_USER_DATA, but breaks on public wikis: https://gist.github.com/moskalenko/7856722a352ed23f445991dd378c6047 [14:47:45] Skizzerz: I'd be happy to modify the extension itself, just not sure how I retrieve the username from mediawiki session data after a login. [14:49:25] hmm [14:49:46] I'm not super familiar with that extension; is it not setting the normal mediawiki session cookies on initial auth? [14:49:48] Skizzerz: Since LocalSettings.php runs on every request and I already logged in I should be able to query the session, shouldn't I? [14:50:01] LocalSettings is executed before any of that stuff is loaded or works [14:50:06] It's setting the cookies. I see them and the correct username. I just need to 'get that info'. [14:51:02] is there a session id cookie as well? [14:51:24] something like $user->getId() to get the username from the session cookie. [14:51:28] (don't use the username cookie as your source of record for logged-in username, it's prone to spoofing) [14:51:32] Yes, there is 'name_session' cookie [14:51:52] with what looks like an encoded value [14:51:54] hmm so the default session handler should be establishing that session then based on those cookies [14:51:56] is that not the case? [14:52:55] I think I'm overriding it with that closure in LocalSettings.php as that makes Auth_remoteuser to _only_ use the REMOTE_USER_DATA. I need to add a line or two of code there to make the user id value from the session the first choice. I just have no idea how to retrieve the userid from the session. [14:53:42] It's probably very simple for someone who knows how to query mw session data. I just don't know how it's done in post 1.26+ mw. [14:53:55] ah [14:54:05] maybe when you don't see the remote user, try setting null instead of empty string [14:54:13] in your closure [14:54:24] (no idea if that'll work or not, but something to try) [14:54:43] i.e. return $username ? $username : null; [14:55:47] I just did it, but I still see the 'Log in' instead of the logged in user the moment I navigate away from the SSO protected page. [14:57:51] I think the 'return $username ? $username : null;' should be something like 'return $session->userid ? $session->userid : $username;', but I don't know what the right way to get $session->userid from the session is. [15:01:15] ok I looked through the code, looks like it's set up so that you do need to provide that info on every request (which is a bit silly imo) [15:04:18] there's one other thing to try; add $wgSessionName = 'mywiki_session'; in your LocalSettings.php [15:04:26] (replace mywiki_ with whatever) [15:08:16] I tried $wgSessionName = 'wikidb_main_session'; which corresponds to the cookie name. It didn't help. [15:08:31] that will force the session cookie that Auth_remoteuser sets to be the same name as the session cookie that default mw session handling is trying to read, which means (in theory) that the default session handler will pick that cookie up and set up the user if you don't have anthing set up with Auth_remoteuser [15:08:39] ah, dang :( [15:09:04] in that case, you've reached the limits of my knowledge with this extension :( [15:09:13] hopefully someone else knows a bit more [15:15:15] Thanks for checking into it! [15:16:41] out of curiousity, what remote system are you using for auth? [15:17:44] shibboleth for auth with a 2nd stage tied into an internal DB. The result is still just the REMOTE_USER and REMOTE_USER_DATA variables. [15:42:11] malex: I would try something along the lines of if ( isset( $_SERVER['REMOTE_USER'] ) && !$wgUser->isAnon() ) { $session = SessionManager::getGlobalSession(); if ( !$session->isPersistent() ) { $session->persist(); } } [15:42:30] probably better handled inside the extension though [15:51:13] tgr: will that work in LocalSettings? I thought $wgUser was still a stub at that point in time [15:53:32] Skizzerz: not in LocalSettings, no. $wgExtensionFunctions or something like that [16:21:57] I can't submit a bug report/question for the extension authors, yet, waiting for some sort of admin review of the account request on phabricator. [16:22:28] andre__: poke and ^ [16:23:54] malex, what's your account name? [16:24:06] malex, ah found it [16:24:09] Please try again :) [16:24:39] andre__: Thanks! [16:27:43] Interestingly the extension page states that they just read the closures from LocalSettings.php, but use them inside the extension as needed. [16:30:34] loans: if mediawiki doesn't think the email is confirmed, it won't send them anything. If they select to re-send a confirmation email, does that go through? [16:35:33] loans: https://phabricator.wikimedia.org/T182337 seems tangentially related (in that it's the feature request so that the initial confirmation mail sets their email as confirmed) [16:35:40] but I don't see anything describing the issue you're seeing [16:36:05] have you verified that the server is simply not sending any of those emails at all? (the 2nd confirmation email, etc) [16:38:08] the resetUserEmail.php maintenance script can be used to mark an email as confirmed -- https://www.mediawiki.org/wiki/Manual:ResetUserEmail.php [16:39:03] yeah that's super hacky [16:39:16] are you able to check logs on the email server itself to see if it's been getting anything? [16:40:33] mind sharing the email-related settings of your LocalSettings.php? (remove any passwords/secret keys first, and redact hostnames) [16:44:04] no other settings besides those 2 for emails? [16:45:06] look for the word Enotif [16:45:37] also any sender addresses [16:46:10] like I see you have $wgNoReplyAddress = $wgEmergencyContact; but are you defining $wgEmergencyContact anywhere above that? [16:47:15] you may want to configure both $wgEmergencyContact and $wgPasswordSender to have valid email addresses which end in your domain or server name [16:47:28] in case the remote smtp server is rejecting them for invalid addresses [16:47:29] k [16:47:44] ok all of that looks right then [16:52:18] if a user changes their email to a different value after their account is confirmed, does it then send them emails again? [16:53:29] oh, huh [16:53:29] yes [16:53:50] i got an email changed notification and an address confirmation [16:53:58] weird [16:54:03] so weird [16:54:10] probably means it's a bug in ConfirmAccount then that's not setting their email up properly [16:54:22] that's been my suspicion [16:58:05] hm [16:58:08] but i'm not getting other emails [16:58:15] i.e. 'email this user' or watchlist changes [16:58:37] did you enable those email types in your Preferences? [16:58:41] I believe they're off by default [16:58:43] oh, no, they're just slow [16:58:49] they're coming through [17:04:59] so the 'change email address' form is smart enough not to let you change it to the same address [17:06:03] but you can remove your email address and re-set it [17:10:41] i guess i should file a bug with confirmaccount, huh [17:12:09] I submitted T200451 on phabricator. [17:12:09] T200451: username only handled on protected pages - https://phabricator.wikimedia.org/T200451 [17:36:40] hello [17:37:08] we are trying to make our wiki so you must be registered and logged in, in order to view any pages [17:37:33] we did that with these 2 lines: [17:37:44] $wgGroupPermissions['*']['read'] = false; [17:37:44] $wgGroupPermissions['*']['edit'] = false; [17:38:18] which worked. However, now, nobody can register because they need to be logged in in order to register....lol [17:41:28] stiv2k: add $wgWhitelistRead = [ 'Special:CreateAccount' ]; to your LocalSettings.php [17:41:44] oh [17:41:55] i was looking thru the docs and i just saw this one [17:42:15] $wgGroupPermissions['*']['createaccount'] = true; [17:42:31] they have that by default [17:42:35] which one is better? [17:42:44] the ability to create an account doesn't grant the ability to view the page that lets them create an account [17:42:47] use mine [17:42:52] i see [17:43:43] $wgGroupPermissions['*']['createaccount'] = true; is a default setting, so you don't need to explicitly set it (it's already set to that) [17:51:12] Skizzerz: thanks! [17:53:18] when i go to Special:ActiveUsers i get a database error [17:53:24] A database query error has occurred. This may indicate a bug in the software. [18:35:13] any ideas why? [19:02:45] !debug | stiv2k [19:02:45] stiv2k: 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 [19:03:33] is it possible to delete an account? my coworker accidentally registered twice [20:04:21] in the upgrade guide it says: However, please note that when you update from old versions, chances that you will encounter PHP errors are bigger than when you upgrade from the version directly previous to the new version. You would have received these errors anyway, also if you had not skipped versions, but if you had each time done each single update. Only will you - when you skipped versions - get [20:04:27] them all at the same time. This will make the upgrade more difficult, but do not forget that you did not have the trouble updating to the intermediate versions, which you skipped! [20:04:33] what php errors is it referring to? [20:05:56] any number of things [20:07:07] I tend to only update mediawiki whenever I remember to, but I haven't had much in the way of problems. On the other hand, I have a massive script to update from git and then update all the plugins and skins. [20:07:58] Platonides: Banbot no me quiere en #mediawiki-es :'( [20:08:08] i'm going to be upgrading from 1.13 (yikes) to latest [20:08:24] the guide seems to suggest that should be fine, but the part about php errors is confusing if nothing else [20:08:35] error suggests a problem [20:09:12] Very old versions to the latest will probably encounter issues [20:09:26] It's just how the development cycle works [20:09:48] okdana: I think it's mostly a warning that in case something does happen, don't freak out, it's somewhat expected [20:10:13] fair [20:10:14] It's not like they're expecting people to be that far behind [20:10:17] guess i'll see what happens [20:10:57] theoretically the upgrade process is designed to work from any old version to the current stable, but in reality it may not work as prettily [20:11:12] i can imagine so [20:12:55] I've an instance that I am upgrading to 1.31.0 and the only two lines I see when running php maintenance/update.php are 'Your composer.lock file is up to date with current dependencies!' and '⧼config-mysql-old⧽'. I am pretty sure the DB upgrade has not happened since I get an error about a missing column, yet there is no verbose or debug mode for update.php. Any hints on troubleshooting the updater? [20:14:08] ah hm [20:14:37] malex: your MySQL version is too old [20:15:07] (but the updater is supposed to tell you that) [20:15:48] malex: you need to have MySQL 5.5.8 or later [20:16:23] (or MariaDB) [20:16:29] legoktm: Thanks. That really helps. [20:17:04] i wish postgres was the preferred db for mw [20:17:07] mysql is baffling to me somehow [20:17:45] I can upgrade to 5.5.56-MariaDB, should be good I guess. Cool. [20:17:52] Yeah, love postgresql. [20:18:27] i thought really hard about migrating to postgres during this upgrade but then i figured it's best not to risk it [20:18:45] there are known problems with it and i don't think (?) anybody major is using it [20:19:01] We def support mariadb way better than postgres [20:19:12] s/postgres/anything that isn't mariadb/ [20:19:26] I guess sqlite support is good but that doesn't count [20:19:36] im not aware of any specific problems. More that literally nobody tests it [20:19:58] and we are very definitely performance optimized for mariadb [20:20:27] i found a bunch of open issues for pg on phabricator, and comments to the effect of 'this is not a priority for us because we don't use it', &c. [20:20:39] which makes sense [20:20:52] we're always looking for more people to help maintain pgsql support :) [20:26:08] I never quite got the hang of devops on pg, so I try to avoid it. [20:27:05] yay, updater is happy with mariadb-5.5.56. [20:27:23] i love it, it's the only database i've used that i actually find intuitive [20:27:28] sqlite3 is a very distant second [20:28:08] in terms of maintenance and administration, i mean [21:10:46] huh [21:10:52] seems to have upgraded fine [21:10:55] no php errors that i saw [21:11:07] that's pretty cool