[10:27:34] hi, i want to use the pyAutoWikiBrowser bot for my MediaWiki and wanted to ask if someone can help me [10:28:46] just a quick question (i've read various pages but i'm not quite sure what to do here) - i want to modify the text on pages such as the 'code editing page' to be a bit friendlier on my own installation of mediawiki. for example this phrase: "Please note that all contributions to Demo Wiki may be edited, altered, or removed by other contributors. If [10:28:47] you do not want your writing to be edited mercilessly, then do not submit it here.". should i be making a copy of the existing English translation, editing it, and applying it as a new translation, or should I be editing the file directly? is there another way I should go about this, for example through environment variables? [10:30:11] it's pretty important for the context i'd like to use this wiki in that i remove the part about "mercilessly" editing and replace it with some other phrase [10:32:20] duck-duck-raptor: One sec, I'm spinning up my docker instance to test this [10:34:14] thanks so much mjt! [10:34:48] duck-duck-raptor: If you go to Special:AllMessages you will see a list of the interface text which an interface admin can change. [10:35:04] The relevant text seems t obe MediaWiki:Copyrightwarning2 [10:35:21] See https://www.mediawiki.org/wiki/Help:System_message [10:35:40] OK. Thanks! [10:35:56] That's much simpler than messing with translation files, so sounds good to me [10:36:48] Guest19: looks like that project hasn't been maintained in ages [10:37:04] its a fresh project lol [10:37:32] is that an ancient py bot? its the first one i found after googling for appropriate bots [10:38:26] err well pyAutoWikiBrowser seems to be an attempt to reimplement AutoWikiBrowser in Python and was last updated on sourceforge in 2012. [10:38:44] yeah, i noticed that as well. [10:38:49] Fairly sure there's better Python MediaWiki bots out there..... [10:38:52] but if it does its job i dont mind [10:38:59] im open to suggestions [10:39:16] https://www.mediawiki.org/wiki/Manual:Pywikibot [10:39:45] thx [10:39:52] methinks you'll want to use this one, which also has a support channel here (#pywikibot) [14:55:53] Hi. I want to ask a question. Can I use this channel to get technical help about the MediaWiki? [14:56:24] yes, please ask your question (https://dontasktoask.com/) [15:05:56] I want to set up to my own MediaWiki on my localhost. However, AppServ compatible with PHP 7.3.10. This means, I have to install to the old MediaWiki release. So I did, but I received this error in my localhost: [15:05:56] You are missing a required extension to PHP that MediaWiki requires to run. Please install: [15:05:57] fileinfo (more information) [15:08:00] >Release Date : 2019-09-29 [15:08:12] Wouldn't it make more sense to use something that is actually up to date and being maintained? [15:09:36] Definitely, but I don't know how I should do it. [15:09:45] well, i imagine you'd have the same error with the latest mediawiki [15:10:00] Are you on Windows? [15:10:22] Yes. [15:10:54] XAMPP is probably better then [15:10:55] https://www.apachefriends.org/download.html [15:11:13] I'd suggest downloading "7.4.25 / PHP 7.4.25" rather than "8.0.12 / PHP 8.0.12" [15:20:10] Alright. I'll do that. I've only used XAMPP to share 700.000 photos of my teacher on Instagram in 2019. [15:22:00] Victor_Trevor: if you want to keep using your current distribution then you'll need to figure out how to enable the "fileinfo" PHP extension in it, but it seems no one here has used it, so we can't help with that [15:24:13] Thank you for interest. I hope I can install the software smoothly. [19:14:52] Hi. I installed the MediaWiki software, however deleted my authorized account. I created the same account again, but I don't know how to get all the permissions. [19:15:46] Actually, I don't know where to edit in MySQL. [19:15:50] !createandpromote [19:15:50] To recreate the admin user, run "php maintenance/createAndPromote.php" on the command line. [19:23:08] Well, I don't understand. [19:27:18] https://www.mediawiki.org/wiki/Manual:CreateAndPromote.php [19:28:00] lol [20:40:16] is it possible to run two different versions of mediawiki on the same server under linux? if so, is there any documentation i can read? [20:42:01] You can, yeah [20:42:07] There won't really be any documentation for it though [20:42:24] The specific way that Wikimedia does it is documented to some extent at https://wikitech.wikimedia.org/wiki/Heterogeneous_deployment [20:42:50] bd808: thanks for link [20:42:55] although that is a pretty "fancy" way of having a mixed version system [20:42:57] (that page probably won't be helpful for you, but it proves it can be done) [20:43:54] fundamentally MediaWiki is a directory on disk and a database, so you could easily have multiples in varying versions [20:44:13] the simplest way is to have two different installation paths [20:45:00] bd808: eeeh, I'd maybe drop the "easily" :) it can be done but depending on the complexity of the existing system etc. it may or may not be so easy! [20:45:49] https://www.mediawiki.org/wiki/Manual:Wiki_family might also have some helpful information [20:45:54] "easily" is always a loaded term. "simply" is maybe better in that it is technically simple, but possibly logically complecated [20:46:59] my goal is to implement upgrade with the possibility of fallback. i have considered containerization, but the technology scares me at present [20:47:06] The technically simple solution is what ACN said, two deployments [20:47:13] Are you going to have two copies of the database? [20:47:20] Or try and run them both against the same version... [20:47:34] Reedy: what could possibly go wrong? ;) [20:47:43] ashley: Depends which MW versions... :P [20:47:44] if possible, i'd like one mariadb with two databases [20:47:47] database will be the issue for blue/green upgrades for sure [20:48:02] You can definitely have many databases on one mariadb install, that's fine [20:48:17] It's more two different versions of MW talking to the same specific database [20:49:08] Reedy: i don't want to do that. two MW versions with separate databases running on one mariadb is what i'm asking about [20:49:18] That's fine [20:49:21] Sure, but just checking, because some people do [20:49:40] I can tell you from experience that 2 mediawiki versions on the same DB is not what you want [20:49:42] keep in mind that rolling back updates may result in data loss in that case [20:49:54] otherwise should have no issues [20:50:01] If you stay read only during then not [20:50:13] But ye data drifts would be an issue [20:51:06] my application (haskellwiki) doesn't have many writes, so i'm less concerned about that. [20:52:00] You can certainly mark the wiki as readonly too [20:52:19] I would suggest setting $wgReadOnly until you have some level of confidence [20:53:06] * RhinosF1 made a script that screams at him if he has forgot to set it [20:53:50] RhinosF1: is your script available for study? [20:54:30] hgolden: https://github.com/miraheze/puppet/blob/master/modules/mediawiki/files/bin/mwupgradetool.py [20:54:40] It's pretty Miraheze specfic [20:54:56] hgolden: Is your wiki massively customised or anything? [20:55:16] Because for most cases... Take a backup (files and db), replace files, run update script... And you should be good [20:56:38] Reedy: the only customization is: (1) color scheme; (2) a ... tag used historically. [20:57:11] I'm not saying it will work 100% afterwards without some tweaking... But I can't see too many major issues [20:57:21] What version are you upgrading from too? Obviously that will influence it a bit [20:57:47] this gives me a (somewhat) warm fuzzy feeling. :-) [20:58:02] Reedy: i want 1.36.2 [20:58:13] from: 1.27.4 [20:58:23] Shouldn't be too bad [20:58:33] I suspect your custom haskell tag might need some work updating... [20:59:15] any reason you're going to 1.36 and not to 1.37? [20:59:24] I guess 1.37 was literally just released... [20:59:30] And they've been planning this for a little bit ;) [20:59:35] Unless it's an extension maintained elsewhere, and you just might be able to update [20:59:39] no reason except 1.37 is so new [21:01:12] 1.36 is only supported until May 2022... So depending on if you want to upgrade again soon (to 1.37)... 1.35 might be enough for now, as htat's supported till Spetember 2023 [21:01:28] 1.35 might be better [21:01:38] If you don't want often upgrades [21:01:55] Reedy: i tried 1.35 and had a problem with the converted db. i only tried it once. [21:02:08] 1.36 is likely to be no better [21:02:10] HOWEVER [21:02:14] depending on the actual issue [21:02:46] https://github.com/wikimedia/mediawiki/commit/321c8d23c7384f766d44403c48ad31b8e8bd8059 (which is in the 1.35 branch, but not released yet) might help [21:04:03] Reedy: that may fix the problem i encountered with 1.35 [21:04:19] A similar patch is in 1.36, but again, not formally released yet [21:04:24] I had a stalled patch to get working without patches.. [21:05:22] https://gerrit.wikimedia.org/r/#/c/333798 [21:05:41] >This feature was inspired by the HaskellWiki creating an alias [21:05:45] heh :) [21:06:40] legoktm[m], Reedy: the 1.27.4 code for was easy for me to upgrade to 1.35 or 1.36 [21:07:20] Probably. legoktm[m] was trying to make it mostly work out of the box :) [21:07:30] Yeah, those parts haven't really changed. [21:07:54] since haskell is sweeping the universe, that's a good idea! [21:11:24] thank you, all, for your help! [21:12:51] Np [21:24:25] haskell wiki, eh? didn't I once tweak a haskell wiki skin... [21:24:54] ah, I did: https://github.com/mary-kate/hawiki [21:26:30] ashley: I was telling Reedy that I roped you in last time they upgraded their wiki ;) [21:27:14] always happy to help out with skinning stuff ;) (especially if I can rope some of y'all into upgrading this one super duper old wiki some day. . .)