[02:24:16] MW 1.34.2 upgrade to 1.35: Hosting provider tried to update and got following error: 2020-09-26 02:17:55.314738 [NOTICE] [225519] [31.41.218.11:53218] [STDERR] PHP Fatal error: Uncaught Error: Class 'WebRequest' not found in /home/iafstghq/digitalmatrixgroup.com/includes/HeaderCallback.php:63 thrown in [02:24:16] /home/iafstghq/digitalmatrixgroup.com/includes/HeaderCallback.php on line 63 [02:24:51] *Upgrade. [02:26:00] T261260 [02:26:01] T261260: Strange secondary error "Class 'WebRequest' not found" in logs after errors like "extension.json is not a valid JSON file" - https://phabricator.wikimedia.org/T261260 [02:26:23] Previous reports suggest that only seemingly happens after other errors [02:27:08] Is there somewhere I can point them to or do I send them to the link T261260 [02:27:22] Not really. The bug doesn't give much [02:27:32] Other than it would seem there's possibly other errors at the same time [02:28:58] What could I ask them to run to clarify the totality of issues? thx [02:29:09] Nothing to particularly run [02:29:21] More look if there's anything else in the error logs around the same time [02:35:50] I have the ability to roll it back to the 1.34.2. Do you think it would be a good idea to start over? I saw that it is a specific PHP 7.3.19. They only have 7.3 or 7.4 [02:36:05] I saw somewhere that 7.4 won't work. Could this be an issue you think [02:36:31] 7.4 should work fine in most cases [02:37:27] Ok, I think I will have them roll it back and try to manually do it myself. Need to learn some skills anyway ;) [02:40:56] They sent me the whole log. Is that something you folks want to see or ... [11:28:17] Mediawiki 1.34.4 archive extracts fine on Linux using TAR, but truncates some filenames using 7-Zip (64-bit) on Windows 8.1 (64-bit). Truncated files are all in resources/lib/ooui/themes/wikimediaui/images/icons. [11:30:00] Correction: there are truncated files in other folders as well. [11:38:24] Archive for 1.33.3 is fine. [11:41:05] Same problem in the archives for 1.34.3 and 1.35. [11:47:43] boot13: how do you know that they are truncated? [11:49:18] gry: Initially because 7-zip reported duplicate filenames when extracting. When I checked, I could see that the duplicates were because some filenames were being truncated. [11:49:46] maybe you're extracting it in a directory whose name is too long? [11:50:21] say, in C:/Users/gry/Desktop/ is ok, but C:/Users/gry/Desktop/Websites/ComplicatedLongPathHere/ThisIsATest/SomeMoreLongStuff/ could cause a problem [11:51:08] I don't think so, but I'll test that. On the other hand, I can see the truncations in 7-Zip without even extracting. [11:52:01] It’s a known issue [11:52:34] Basically, don't use 7zip [11:52:51] https://phabricator.wikimedia.org/T257102 [11:53:41] @Reedy: Okay, thanks. Note: the Mediawiki download page recommends 7-Zip for Windows. [11:53:50] I was just looking at that [11:54:01] I thought we'd put a warning elsewere [11:57:22] Fixed that one.. [11:58:13] Tried latest 7-Zip alpha version: same problem. [11:59:28] Yeah, they haven't fixed it [11:59:37] https://sourceforge.net/p/sevenzip/bugs/2116/ [11:59:42] https://sourceforge.net/p/sevenzip/discussion/45797/thread/f58b3570/ [11:59:55] PeaZip: same problem (it uses 7-Zip apparently). [12:00:52] winrar works... [12:00:56] but not obviously free [12:05:47] WinZip works, but also not free. [12:10:21] Ugh. WinZip is even worse than I remember. [12:10:59] haha [12:22:30] I added a comment to 7-zip bug 2116, pointing out that MediaWiki is now recommending avoiding 7-zip. Maybe that will get the 7-zip dev's attention. [12:25:32] Maybe... [12:25:40] I think there's various projects in a similar situation with the same notes [12:25:45] It's annoying for sure [12:25:57] install cygwin to use its tar command, or something? seems a bit ugly [12:27:40] gry: I've started using TAR on my Linux box and copying to Windows, but Cygwin should work too. [12:29:24] Could use WSL too [12:30:12] @Reedy: still on Win8.1. [12:51:16] hmm [12:51:57] ConfirmAccount (for 1.35, obtained from ExtensionDistributor) breaks update.php for me, wonder if it is something wrong with my set-up [12:52:29] Can you give more information? [12:52:34] Breaks how? [12:52:35] include(...extensions/ConfirmAccount/frontend/language/ConfirmAccount.alias.php): failed to open stream: No such file or directory in ...w/includes/cache/localisation/LocalisationCache.php on line 556 [12:52:53] naturally there is no ConfirmAccount/frontend [12:53:25] ConfirmAccount.alias.php itself is straight in the main subdirectory of the extension [12:53:34] https://github.com/wikimedia/mediawiki-extensions-ConfirmAccount/blob/REL1_35/extension.json#L34-L36 [12:53:44] Did you already have it installed? [12:53:56] yes, in all previous versions [12:54:06] And if you look at extension.json, is the path right? [12:54:09] upgrade was done by copying LocalSettings.php [12:54:39] yes [12:54:54] Sounds like something is being cached somewhere then [12:55:11] OH [12:55:11] no [12:55:15] You're still using the PHP entry point [12:55:25] Which I apparently didn't update [12:55:26] $wgExtensionMessagesFiles['ConfirmAccountAliases'] = [12:55:26] __DIR__ . '/frontend/language/ConfirmAccount.alias.php'; [12:55:27] * Reedy fixes [12:55:28] lemme try restarting php-fpm [12:55:47] as above, use wfLoadExtension, rather than require-ing the PHP file [12:56:14] oh. sorry [12:56:29] I'll fix the PHP file, cause it's wrong [12:56:35] this is a really old instance of MW [12:58:03] it works perfectly now, thank you [12:58:25] I absolutely forgot about the wfLoadExtension() switch for ConfirmAccount, it used to lag behind [12:59:01] Yeah, it was updated in the 1.35 cycle it seems [12:59:15] https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmAccount/+/630234 will prevent other people falling over the same issue though [13:01:15] (…oh and now it is time to enable query logging, I guess) [13:15:28] Reedy: should I file a bug for this: https://paste.ee/p/Qtljd ? [13:18:45] I guess starting the upgrades with one of the least-used wikis was extremely correct [13:21:32] hmm this is weird though, the code has not been updated for a long while [13:38:28] Did we screw up the conversion? [13:38:33] Let me check m [13:40:14] Reedy: I added a tiny bit of debug to that method and "[2020-09-26T22:38:19.531745+09:00] ConfirmAccount.ERROR: Type merge_strategy is not an integer" says my if(!is_int($type)) [13:40:46] the string merge_strategy is only present in extension.json and I have no idea how it got into request types [13:44:32] Reedy: ConfirmAccount.DEBUG: Account request types is: array{"0":["authors","user",null],"merge_strategy":"array_plus"} [13:45:35] this might affect MySQL users as well [13:45:36] lol [13:45:42] merge_strategy isn't supposed to be inside value [13:46:14] this is where I go "you don't say" :D [13:46:34] * Reedy glares at ashley [13:46:39] Though, I think I did the CR [13:46:43] * Reedy whistles [13:47:55] >Note: this has been tested. [13:47:57] HAS IT NOW [13:49:22] well I can assure you I just tested it and it failed [13:49:42] I'm not saying you're wrong [13:49:46] The code is clearly wrong [13:50:22] https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ConfirmAccount/+/630236 [13:50:45] it was a joke, I was commenting on "has been tested" since it definitely has been, just now, with a resounding failure [13:54:25] Remilia: merged [13:54:37] thank you [13:58:44] Reedy: works fine now! [13:58:48] yay [13:59:09] 2 minutes ago extensiondistributor still gave the old commit though [13:59:26] I think it caches stuff for a little while [14:34:59] Hi. Just tried to upgrade MW from 1.34.2 to 1.35 by simply unpacking and running update.php... Did not work :( [14:36:09] Same thing happened to me last night. A veritable nightmare. Part deals with PHP I can tell you that [14:36:39] I am still experimenting ... even the hosting provider couldn't nail it. [14:37:07] https://paste.tnonline.net/files/VVaeus6LHa4f_Screenshot_20200926-163629_Opera.jpg weird error [14:37:42] Should I simply start fresh and move back uploaded data/images etc? [14:37:49] I have just updated two installs of 1.32 and 1.33 to 1.35 without issues [14:37:50] I did disable all plugins [14:38:46] though I did not "unpack and run", instead doing the usual renaming the old wiki directory and extracting to a clean location, then downloading all extensions etc. again [14:38:50] and moving images [14:39:11] I'm going to have to try this [14:39:15] (and of course LocalSettings.php) [14:42:01] @Remilla I am running a few things like Cargo, Page Forms, and a lot of heavy Lua Modules (had to use composer). Are there other files besides the normal images, localsettings I need to move? thanx! [14:42:24] *@Remilia [14:43:51] you would need to copy over composer configuration files and run composer update, probably [14:44:04] not an expert whatsoever [14:44:27] Thanks! Didn't even think of it. [14:44:32] also Cargo is the scariest part of the upgrade I am saving for last [14:45:38] Ah, so you are doing it incrementally? Like all the basic extensions and then when you get to the larger ones, id'ing the files dependent and moving old folders into the new wiki? [14:46:03] no [14:46:19] I have 5 wikis hosted and only one of them uses Cargo [14:46:58] Ah ... braver man than I ;) One wiki is enough of a playground for me [14:47:47] in my case it is not a playground but community wikis hosted for free [14:48:47] my most persistent issue is that PostgreSQL is a second class citizen in MediaWiki and nearly every time an update comes out I get to file bugs [14:52:19] Might wait for next point release instead. I tried to read what's new. Seems the big thing is the new editor? [14:53:26] it is old [14:53:49] the difference is that it no longer requires a Node.js Parsoid instance [14:55:29] I do not like nodejs so that's a foot thing [14:55:36] Good thing [15:13:24] Hi, could anyone tell me if the new ldap stack supports modifying values in ldap? Like the old ldap extension does? [15:13:35] (for example changing password/real name) [16:29:06] Managed to update MW :) had to start with a fresh installation and then move pack images and extensions [16:38:25] Hey, just upgraded to 1.35.0 from 1.31.9, not sure why I am getting this error: https://gist.github.com/tyteen4a03/0806b33dc960191416714f8133d89740 [16:45:45] tyteen4a03: some extensions not available? [16:49:37] Forza: I tried disabling all extensions that are not bundled [16:50:05] I had to start fresh and not do an in place upgrade :/ [16:50:52] that's annoying [16:51:54] I'm stuck with enabling visual editor. It gives me a browser warning failed to connect to parsoid [17:00:09] Any idea how to enable it? [17:04:50] Seems I need to set up Parsoid. It should be bundled but I can't find any docs on how to activate/config it [17:12:04] Hm OK. It seems it is possible to create new pages with visual editor, but not edit old pages. [17:23:21] More testing with the VisualEditor. Seems only subpages do not work. So creating and editing PAGE works but not PAGE/Subpage [17:23:33] Seems very similar to this issue: https://www.mediawiki.org/wiki/Topic:Sytfaoetamabdt2i [17:40:34] Found the problem! I need to add "AllowEncodedSlashes NoDecode" in apache vhosts [18:01:00] did resourceloader stuff change hmm [18:04:47] oh it did [18:13:02] Hey guys, just a super simple question for you! I heard there is a discussion about a new mediawiki/wikipedia default skin. Can you please give me a link to it, as I'd love to see a preview of the new skin? Thanks in advance1 [18:22:04] MW 1.34.2 upgrade to 1.35: Without old localsettings file in place I can go straight to the mw-config and install. With it in place triggers 500 error [18:23:02] do i simply enter all my database info into the requested fields from my old localsettings file? thx [18:24:19] foreclosurepedia: are you getting similar errors like https://gist.github.com/tyteen4a03/0806b33dc960191416714f8133d89740 [18:24:50] No errors yet. it says i have an existing db and do i want to update it. presume yes [18:24:53] Please? :D [18:26:45] Reedy: I think the installation instructions at https://www.mediawiki.org/wiki/Extension:ConfirmAccount need an update to include `$wgGroupPermissions['*']['createaccount'] = false;` for LocalSettings.php? or am I wrong [18:27:14] So, it said all was well and to add my localsettings file. When I did it kicked a 500 error [18:27:20] after upgrading to 1.35 with the same settings spammers immediately managed to register with the standard CreateAccount page despite ConfirmAccount being enabled [18:34:25] Forza: I ended up regenerating my LocalSettings.php [18:35:51] I regenerated localsettings as well and still 500 error. HeaderCallback line 63 ... PHP Fatal Error Web Request [18:36:38] thrown in /home/iafstghq/digitalmatrixgroup.com/includes/HeaderCallback.php on line 632020-09-26 18:34:22.123181 [NOTICE] [1899852] [99.203.202.237:1548:HTTP2-41] [STDERR] PHP Fatal error: Uncaught Error: Class 'WebRequest' not found in /home/iafstghq/digitalmatrixgroup.com/includes/HeaderCallback.php:63 [18:42:25] Debugging says: Uncaught UnexpectedValueException: callback 'MapsRegistration::onRegistration' is not callable ... includes/registration/ExtensionRegistry.php [18:42:51] It's long didn't want to clog up stuff but viewable here: https://digitalmatrixgroup.com/index.php [18:43:37] I did at it would be an error in other code ;) [18:43:44] Did say [18:44:18] is regenerating LocalSettings.php every major update recommended? [18:44:27] No [18:44:28] Should I perhaps comment out all the extensions and go one by one and download v1.35 for each? [18:44:44] or do i need to perhaps do something to push the composer again? [18:44:59] If you update MW core, you should be updating all extensions at the same time [18:45:50] very good. i'll go start to do that. I have shared hosting but have snowflake on ubuntu 20.04. Is there a way to update them all at once or is it one off? thx [18:46:06] Snowflake is my SSH [18:46:27] there is a tool for that mentioned @ https://www.mediawiki.org/wiki/Manual:Upgrading [18:46:38] in the section that tells you to update your extensions [18:47:13] thx going there now and should be understood I appreciate everyone for taking the time to help out! [18:48:00] Reedy: the issue I mentioned above re: CreateAccount being available with ConfirmAccount enabled and without an explicit * createaccount = false manifested on two other wikis [18:48:06] Reedy: ok, well I just had to do it to solve an exception [18:48:21] my LocalConfig goes back to 1.18 and wow I'm liking the new format [18:48:24] If you had a really really old version of MW... It could be worth regeneraing.. [18:48:33] Some stuff was moved out to make it simpler etc [18:48:39] And that definitely happened between 1.18 and 1.35 [18:48:49] But in most cases, it shouldn't be needed every release [18:51:08] Remilia: in theory, it shouldn't be needed [18:51:19] from extension.jso [18:51:21] "GroupPermissions": { [18:51:21] "*": { [18:51:21] "createaccount": false [18:51:21] }, [18:51:22] "user": { [18:51:22] "createaccount": false [18:51:22] Reedy: in practice I got spam :( [18:51:26] }, [18:51:31] You'd have to check the effective permissions on the wiki [18:51:36] Special:UserGroupRights [18:51:56] It might be the override in extension.json doesn't work quite as desired... as happens with handling of various complex arrays [18:52:24] lemme try commenting it out again [18:52:53] We have issues with this in other places [18:53:06] I imagine this example of extensions overriding core group permissions isn't well tested [18:53:10] (all) Create new user accounts (createaccount) [18:53:30] after I commented out the explicit persimmon removal [18:53:48] this might be a very nasty surprise to some administrators :\ [18:54:51] Can you file a bug about it? I'm not really in a position to fix it atm\ [18:55:00] sure [18:55:06] But it's good to get it documented that there are issues [18:55:09] for ConfirmAccount? [18:55:13] yeah [18:55:20] And certainly feel free to edit the mw.o and put a note/caveat about that too [18:56:14] So, it appears that php mwExtUpgrader.phar updates the extensions is this correct and I would simply execute the command in the main folder of where the wiki is? thx [18:56:20] Remilia: Also, as an FYI... pg support for schema changes should be improving in the next few releases (due to abstract schema work) [18:56:26] \o/ [18:56:29] great [18:56:55] I already noticed there not being any in your face issues with it in 1.35 [18:57:59] Reedy: what is mw.o if you do not mind me asking [18:58:47] mediawiki.org [18:59:49] tyteen4a03: fwiw, we got a similar report on https://phabricator.wikimedia.org/T263911 [19:00:53] tyteen4a03: Do you still have a copy of the old LocalSettings? [19:09:01] Would be helpful in identifying what might be the problematic code... [19:10:16] As there was some boilerplate code removed from it a few versions ago, I just can't remember what/where offhand [19:12:24] added to Installation section here https://www.mediawiki.org/wiki/Extension:ConfirmAccount [19:12:43] oooops [19:12:59] what happened [19:13:04] Reedy: I can send it to you yes [19:13:20] fixed [19:13:30] tyteen4a03: Thanks, would be appreciated [19:14:05] except formatting is borked because I am an idiot :\ [19:14:11] hopefully someone fixes it [19:14:28] translate is hard :) [19:14:54] Reedy: here you go https://gist.github.com/tyteen4a03/c3f0e1b244118c64a2e52405a18b7598 [19:15:37] Thanks. Will have a look later [19:18:53] I managed to fix it myself somehow [19:19:09] 1.31.9 worked [19:19:12] that was 3 more edits than was actually needed and I am ashamed [19:31:50] Reedy: well last I checked PG support wasn't that bad for even social tools support PG these days ;-) but of course having *even better* PG support is very nice! [19:42:49] speaking of social tools [19:43:00] is the discussion thinger still incompatible with PostgreSQL [19:43:33] I really wanted that to be a thing on the wikis I host because otherwise everything happens on *Discord* and please just no [19:46:22] Comments? it should be PGSQL-compatible, like everything else in the social tools family (but as a disclaimer: I haven't tested PGSQL compat for a few months, and there are probably still some weird edge case issues, but I *am* willing to be bold enough to say that most functionality works just as intended, whether you use MySQL/MariaDB, PG or SQLite; should something not work, please file a bug (and preferably cc me on it, even though I do [19:46:23] stalk the #social-tools tag on Phabricator)!); agreed, let's just say a firm NO to Discord :) [20:07:38] tyteen4a03: if you want to post your new one too... :) [20:18:01] Remilia: hi :) welcome :) [20:24:53] excuse me? [20:33:17] hmm how do I force mediawiki to update the transclusion statistics [20:33:47] it thinks a template is used on 420 pages (sic) but editing and immediately saving a page on that list drops the count down by 1 [20:35:26] oh cool [20:35:43] Error 22007: ERROR: invalid input syntax for type timestamp with time zone: "" [20:36:00] MediaWiki + PostgreSQL = love [20:36:27] Function: RefreshLinks::refreshCategory / Query: SELECT page_id,cl_timestamp FROM "page","categorylinks" WHERE (page_id=cl_from) AND cl_to = 'Candidates_for_deletion' AND ((cl_timestamp > '' OR (cl_timestamp = '' AND cl_from > 0))) ORDER BY cl_timestamp,cl_from LIMIT 100 [20:39:04] does not happen if I do not specify a category, instead it gets upset at some other issue [20:44:39] Hi. In the new 1.35, in mobile view, I have a new "language" icon that wasn't there before. https://paste.tnonline.net/files/luSNgHBU6ZWX_20200926_224404.jpg [20:45:04] Is it possible to disable it or configure it somehow? [21:19:05] the audio files' previews are weird [21:19:38] they have a background-image that is 220px wide while the bounding box for a preview is 150px [21:20:14] https://i.koumakan.jp/2020-09-27/1601155204.png [22:04:48] oooh I found a new PostgreSQL-related bug in Cargo [22:04:50] nice [22:15:48] MW 1.34.2 upgrade to 1.35: Anyone help me figure out how to fix this problem during upgrade located here with debug: https://digitalmatrixgroup.com/index.php [22:17:36] It's probably some issue due to the autoloading [22:18:28] cursed be that day I let myself get talked into adding Cargo [22:18:54] https://maps.extension.wiki/wiki/Installation#Installation [22:19:29] @Reedy so reinstall via composer? [22:19:41] * Reedy shrugs [22:19:54] Remilia Suggest to uninstall Cargo? [22:20:09] That's the way they're listing to install it [22:20:52] @Reedy so it was installed on the 1.34 so do i need to reinstall or update via composer perhaps? thx [22:20:59] foreclosurepedia: you are fine if you use mysql; it is only borderline problematic there (if we forget about inability to use XML export) [22:21:04] probably an update [22:21:17] I am on mysql Maria db [22:21:42] Ah, ok. I just follow samesaid instructions and push again via composer? thx [22:26:11] Possibly [22:26:19] It's not as supported as they make ut [22:26:24] >Maps is installed using Composer with MediaWiki's built-in support for Composer. [22:26:27] Read https://www.mediawiki.org/wiki/Composer [22:26:33] Composer is a dependency manager for PHP libraries. [22:26:42] An extension is not a php library [22:29:55] Didn't change much but got this in composer in SSH: Problem 1 - Installation request for wikibase/data-model-services ^3.15.0 -> satisfiable by wikibase/data-model-services[3.15.0]. - wikibase/data-model-services 3.15.0 requires wikimedia/assert ~0.2.2|~0.3.0|~0.4.0 -> satisfiable by wikimedia/assert[v0.2.2, v0.3.0, v0.4.0] but these [22:29:55] conflict with your requirements or minimum-stability. [22:40:30] Even trying to update all via Composer triggers the same Maps BS: MapsRegistration::onRegistration' is not callable [22:43:01] it's not an extension we maintain... You're probably best posting at https://github.com/JeroenDeDauw/Maps/issues for it [22:43:47] maybe they did not update it for 1.35 yet? [22:44:25] oh no I spent an hour debugging Cargo :| better go sleep [22:44:36] good luck to everyone upgrading :D [22:44:51] also [22:45:27] everyone writing extensions should get their act together and use structured logging already :\ [22:45:46] Remilia safe sailing thanks for the help tonight! [22:45:52] Cargo's DB errors never get logged at all, for example [22:46:14] Is there a way just to nix Maps to simply see if the wiki works at all? thx [22:47:16] thinking out loud, is there a way to even, if necessary, to back cargo out and still retain MW Page Forms and go forward? [22:51:00] Pushed the error. He is part of the Semantic MW team right? [23:13:40] Final question for the night. Presume that the database was upgraded so no going back to 1.34? Meaning I should sort this out and just hang in there? [23:15:37] It might be ok... only one field was actually dropped [23:15:51] Generally, just disable all extensions and enable one at a time etc