[14:20:24] Hi - I just upgraded a wiki to the very latest MediaWiki code (with "git pull origin master"), and now I seem to be in a world of problems. The biggest one of which is that running update.php does nothing - execute() is not being called, and it has no access to global variables, so it thinks $wgAllowSchemaUpdates is false (well, blank, really). [14:21:40] What branch was it on before? [14:21:49] 1.36. [14:22:18] 1.36 via the master branch? Or the REL1_36 branch? [14:22:21] This is probably a silly question, but do I need to call something besides just "git pull origin master"? Some "composer update" thing? [14:22:43] I'm... not sure now, but I'm pretty sure it's the former. [14:23:09] Cause if it was the latter.. You could have a messy git clone now [14:23:58] What do you mean by update.php does nothing? Is there no output at all? [14:24:07] Well, maybe that's it. When I call "git branch -a", it doesn't list anything after 1.36. [14:24:36] Yes, no output - because execute() isn't getting called. If I add in a call to execute(), I see the other problems there with global variables, etc. [14:24:56] But I'm guessing that this is all just due to incorrect Git and/or Composer handling on my part. [14:25:45] what does `git checkout master` do? [14:26:06] (or `git fetch --all` then checkout some release branch) [14:26:24] Nothing - it says, "Already on 'master' \n Your branch is up to date with 'origin/master'." [14:26:57] I'm running "git fetch --all" now. [14:28:30] (It's taking a while.) [14:29:50] @Reedy - okay, it ran. update.php is still not working, but at least now I see all the recent branches as well. [14:30:42] Should I switch to REL1_39? Or run something with Composer? Or do something else? [14:31:04] I'd try REL1_39 to begin with [14:32:19] Almost certainly after updating/changing branch you'll need to run composer... but that should fail more gracefully than just no output from update.php [14:33:49] Okay, I switched to REL1_39. update.php is still returning no output - execute() is simply not getting run. [14:35:19] It feels something specific in your environment... [14:38:35] Maybe it is... it's strange that no one else has seen this error. Though update.php was working fine before on this wiki, I think. [14:38:51] Is there any chance that doing the Composer update would fix this problem? [14:39:14] Probably not [14:39:18] But it shouldn't break anything either [14:39:33] But if you're changing branches, or doing updates after long periods, running composer is going to be needed [14:40:42] Okay - another silly question, but how do I do that - just run "composer update"? [14:41:10] if composer is in $PATH, yes [14:44:20] Reedy: hey, "composer update" worked - and now update.php is running normally! [14:44:37] Well, I feel like we just learned something. And thank you very much! [14:44:47] Sounds like something was fatal-ing... silently? [14:44:52] a PHP fatal error may cause the script to be aborted and depending on your php error_reporting and display_errors settings, you may not get any error message, the script simply "ends" [14:46:00] Maybe that's it - I should have looked into the error display settings. [18:21:56] Is there a maximum size for scripts in MediaWiki:Common.js ? [18:22:11] I'm getting an error which doesn't make sense: [18:22:17] presumably whatever $wgMaxArticleSize is [18:22:28] "JavaScript parse error (scripts need to be valid ECMAScript 5): Parse error: Unexpected token; token ; expected in file 'MediaWiki:Common.js' on line 164" [18:22:57] that's a parse/lint error, not a size issue [18:24:29] the code has proper ';' characters and runs in another (test) HTML page [18:24:51] is it valid ES5? [18:25:21] worth noting that "Unexpected token" errors in particular are often caused by some unrelated syntax error [18:25:54] based on https://phabricator.wikimedia.org/T75714 I wonder if you're using ES6 syntax and not realizing it [18:26:32] the rest of the script is. inserting the last 10 lines triggers the error. [18:27:22] can you take a quick look at https://wiki.gnuradio.org/index.php?title=MediaWiki:Common.js ? [18:28:25] paste that code in https://jshint.com/ and voila [18:28:37] > 164: 'let' is available in ES6 (use 'esversion: 6') or Mozilla JS extensions (use moz). [18:29:50] you can turn off the validator I believe, $wgResourceLoaderValidateJS [18:30:34] that's the only place I use 'let'; I'll change to a var and see if that works. [18:33:30] success!! Thanks. I was tearing my hair out looking for semicolons [18:40:10] https://www.irccloud.com/pastebin/vkIaj8qr/ [18:44:38] apine: presumably you can pull an updated container or image of sort that uses PHP 7.4? [18:46:23] legoktm: Yes, I think I can just change the base image in the Blubber file. Should the base image in MW core be changed on master, then? [18:46:54] yeah, that makes sense [18:48:03] legoktm: Thank you! [19:05:54] Hmm, changing the base image in the Blubber file didn't help, either. Looks like I should just downgrade to an old version of MW until T246594 is taken care of. [19:05:57] T246594: Prevent use of known buggy versions of PHP (that are greater than the minimum supported PHP version) (7.4.0 – 7.4.8, and 7.3.0 - 7.3.18) - https://phabricator.wikimedia.org/T246594 [19:10:15] apine: or you can comment out the check in core :p [19:10:27] legoktm: Hahahahahaa, good point! [20:35:53] hi [20:36:22] hi [23:22:00] Nextcloud is dropping 32-bit support in the next version: https://github.com/nextcloud/server/issues/34692 [23:32:38] (and PHP 7.4 Soon)