[02:22:22] I've created 2 changes to clear it out from ImageMap and Variables. [02:22:22] https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ImageMap/+/856021 [02:22:22] https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Variables/+/856020 [02:23:24] ImageMap is passing the automated testing, but Variables is not, I think due to [02:23:24] `VariablesHooks::onInternalParseBeforeSanitize) was deprecated in MediaWiki 1.35.` [02:29:59] that's a known fail, see [[phab:T276627]] [02:29:59] T276627: InternalParseBeforeSanitize deprecated in MediaWiki 1.35 - https://phabricator.wikimedia.org/T276627 [02:30:59] and T250963 [02:30:59] T250963: Replace use of deprecated hook InternalParseBeforeSanitize - https://phabricator.wikimedia.org/T250963 [02:35:41] looks like I need to get someone to +2 override it [02:37:03] thnx for the links [02:38:04] np [04:57:17] Not sure who runs the ooui demo site, but the php version isn't working: [04:57:17] https://doc.wikimedia.org/oojs-ui/master/demos/demos.php?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop [04:57:18] > Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 7.4.3". [05:15:05] @Prod[m]: https://phabricator.wikimedia.org/T322357 [05:19:49] lol, great! [06:14:34] Hi, I'm trying to find instructions for importing a MySQL database that has been extended with additional tables. I am installing 1.38 replacing a 1.18 installation. Nothing was output when update.php was run. Are there any hints I could use? Thanks /Jay [06:16:35] Nothing at all? [06:17:04] You couldn't upgrade directly from 1.18 to 1.38... [06:17:36] 1.18 would upgrade to 1.35 fine though [06:17:52] Hi Reedy, you've been such a pillar for a long time.... no it didnt happen! [06:17:53] would/should [06:18:19] Is it fataling or something? [06:18:29] blank null [06:19:05] fwiw bestpracticeswiki.net [06:20:26] after you've run update.php... [06:20:32] what does `echo $?` say? [06:21:15] does wrong psw for a db give that result? [06:21:38] I'd hope you'd at least get a mysql connect error [06:21:46] Not getting anything at all is odd [07:38:28] i encountered some weirdness in diffs. i made the following large edit: https://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_Editor_Retention/Editor_of_the_Week&diff=prev&oldid=1121420415 and right above anna frodesiaks entry is trailing whitespace, which i originally removed in that edit but it made the diff explode, making it look like i changed most of the names, dates and reasons [07:38:30] due to wrong highlighting [11:22:16] Ugh, seems like PHP does not have an interface to call sqlite3_limit(). In particular it would be a great hardening step to set SQLITE_LIMIT_ATTACHED to 0, which would make it so that an SQL injection can't create php files on disk. [11:45:41] huh, use_composer_autoload doesn't seem to work for me [11:45:56] * load_composer_autoload [11:56:12] hmm, but now it does. Weird [11:56:57] Wonder if it was some sort of caching effect [12:33:36] hey, would anyone know if there's an extension that might be able to show if extensions and skins are outdated? [12:34:08] i am trying to simplify the figuring out of checking if an extension needs a redownload [12:34:42] I don't think so, although people talk about making suhc things from time to time [12:36:21] should i turn my mediawiki folders into git repositories? [12:39:26] why nobody has actually put effort in making such things but talked? [12:39:27] Some people do that (As in they clone from the official git repo, so they can easily update) [12:40:03] i should do that but i tried gerrit and it kept getting remotely disconnected [12:40:37] What url did you use? There is also the github mirror which works well as long as you are not planning to commit anything back to upstream [12:41:03] gerrit https .git [12:41:55] I think the big problem is just because someone updates an extension doesn't mean that you neccesarily want to upgrade, usually only security, but right now its difficult to programatically identify which changes are security updates. Combined with different extension authors using different conventions for how branches are used in development [12:42:03] Juesto8050[m]: that doesn't look like a url [12:42:17] im simplifying that [12:42:29] i am on REL1_35 [12:42:46] sorry, i'll find the actual url [12:43:16] right, but some extensions have a REL1_35 branch, others develop everything on master as one version and tell people to use that even for older mediawiki [12:43:47] It tends to get more different once you use extensions that are not developed by mediawiki, and especially ones that are outside gerrit version control [12:45:23] https://gerrit.wikimedia.org/r/mediawiki/core.git [12:45:36] so apparently REL1_35 is a branch, i thought it was a tag [12:45:53] anyways, i tried that and it kept dropping [12:45:57] There would also be a tag for each point release, e.g. 1.35.0 1.35.1 [12:46:22] i'll try again with github, but how frequent are things mirrored from gerrit to github? [12:46:54] The REL1_35 branch contains the inprogress version for the next release of that branch. Given that not much happens in a point release, it is usually very stable to just use the REL branches if you want [12:47:23] Hmm, that does look like correct gerrit url. No idea why its dropping [12:47:26] git normally cant pull tags unless you explicitly do a checkout [12:47:29] Github gets mirrored pretty instantly [12:47:40] im from argentina [12:48:06] it was saying remote host closed the connection in the middle of the checkout after compression [12:48:21] odd. No idea what is with that [12:48:41] is core history too large? [12:48:54] i'll try --single-branch [12:49:10] Its kind of large. You could use --depth 1 if you want [12:49:23] the problem with --depth 1 is updating afterwards [12:49:40] it wont update because there's no commit history [12:50:02] to refer to, you know [12:50:36] uhhh how large? because typically git stores the entire repository locally [12:51:05] guess i'll use git for extensions only, are those equally large or not? [12:51:11] extensions/skins* [12:51:20] I mean, mediawiki core is like a 20 year old project [12:51:48] some extensions/skins are pretty long running as well [12:51:51] My dev checkout is 6 gb, but that includes a bunch of extra extensions as well [12:52:46] oh, can i use the old require_once for skins/extensions that havent been updated? [12:52:49] i've been interested in/trying to port the old mediawiki sample skins to current mw, has someone done that already? [12:52:57] thank you very much for the chat so far by the way :3 [12:53:13] It would have to be a very old extension at this point for require_once [12:53:25] but yes, in theory they should still work if they don't have any other incompatibilities [12:53:55] apparently mobile detect isnt that old and it still uses the old way until a few months ago [12:54:16] talking about mediawiki skins from the time stuff was in core [12:54:39] chick, simplecss, example, etc [12:54:55] lol, chick. I remember that [12:55:08] I feel like that skin never made it beyond the half done stage [12:55:28] has anyone ever ported those example skins? [12:55:58] I don't think so. Nobody liked them very much and the skin system has changed a bunch since then [12:56:16] People did port cologneblue and modern [12:56:22] And i guess Nostalgia [12:56:25] fair enough [12:57:03] i actually weirdly like the simpler skins such as empty and example :D [12:57:18] for testing purposes [13:00:56] huh why is empty offered in skindistributor but its archived [13:02:21] I think skin distributor just looks for REL1_XX branches [13:02:28] maybe archived extensions still get those made [13:02:37] maybe a bug in the distributor [13:02:55] yes [13:03:01] but why its listed [13:03:49] lol those ancient unmaintained skins still get updates through translations or dependency updates [13:04:31] https://gerrit.wikimedia.org/g/mediawiki/skins/Empty [13:04:43] yes old skins still get REL1_* updates [13:05:14] its a shame that distributor removes access to older branches [13:05:24] SO i guess a bug in the bot that makes those branches [13:05:38] perhaps? [13:05:44] I mean, you can still just downlod the old branches from github [13:05:48] but why in first place empty hasn't been removed? [13:05:55] gerrit/github* [13:06:12] github has a "download as zip" option for all branches, which is basically the same (Except no automatic run of composer install) [13:06:29] we still want to be able to access old versions of archived extensions if people want [13:06:35] distributor does run composer install for you? [13:06:40] yes [13:06:48] good to know actually [13:06:57] where is composer located? part of php? [13:07:05] its an external program [13:07:24] i've downloaded some extensions outside of distributor and it worked just fine [13:07:38] TIL [13:07:48] Only a few extensions need composer [13:08:11] I see [13:08:36] if extension.json has a line "load_composer_autoloader": true then it would matter [13:08:41] e.g. AbuseFilter needs it [13:27:25] so far, of the extensions i have in my install, CheckUser, MobileDetect, OATHAuth and TemplateStyles do have the line you say [13:28:09] so, do i have to get composer.phar to check composer update ? [13:34:15] sometimes your OS might already have composer installed (e.g. if you did apt-get install composer or something like that, not sure on exact package name). In which case it might be named composer instead of composer.phar [13:34:19] but generally yes [13:34:24] In Comparer.php line 130: [13:34:24] [ErrorException] [13:34:24] readlink(): readlink failed to read the symbolic link (./README.rst), error [13:34:24] 2) [13:34:27] im on windows [13:34:42] Then yes, you have to download your own copy of composer if you want to use it [13:34:51] you mostly only need it if installing from git [13:35:31] If you install things solely from the zip/tar download, and extension distributor, then composer would be automatically run before the download, and you wouldn't have to worry [13:35:37] looks like i got lock file operations: 121 installs [13:35:57] and it did two installs, 3 updates and two removals [13:36:01] seems good to me [13:36:28] im not sure what im doing sorry x.x [13:39:21] I would't worry too much. If there is something wrong requiring you to run composer, you will get a very big error message so it will be really obvious [13:39:43] on-site? [13:39:54] yes [13:39:57] thank you very much bawolff for the chat and assistance today [13:40:05] no problem [13:40:25] Actually whether its on the site might depend on how early it happens and if you have php error reporting enabled [13:40:34] but in any case, mediawiki wouldn't work [13:41:36] i have php error reporting disabled to help mitigate possible leaks and such [13:42:45] Well you should still have a log file somewhere where errors will go [13:45:52] hmm so i should enable error logging on php.ini and not display it on website? [13:47:16] Depends on how paranoid you want to be [13:47:43] People tend to overstate the risk a bit when it comes to displaying errors on your site. Its really low down on the list of things you need to worry about [13:48:27] But regardless, it is definitely a good idea to enable the log to file option in php.ini so you have a list somewhere of any errors [13:51:24] yeah, im conserving space by not logging to disk 🙂 [13:51:45] You could always just turn leave it off and turn it on if you have a problem [13:52:06] yeah i just do that, leave it off and turn it on on ls.php when i need it [14:17:51] bas_dehaan[m]: window.Morebits.date.prototype.format+'' [15:49:56] huh, what is with the comments on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/176799/ [15:50:05] they're all empty for me [16:22:44] I'm seeing two empty comments by Kaldari and one empty comment by Ori on that patch, but the automated comments by CI bot etc. show up fine [16:24:03] that's what i see too [16:24:11] I'm assuming that they didn't randomly just make empty comments [16:26:31] I can confirm invisibility of same [16:26:32] Firefox mobile 10x over here. [16:29:13] I filed T322964 [16:29:13] T322964: reviewer comments missing on a specific change - https://phabricator.wikimedia.org/T322964