[11:51:28] <faceface>	 hello
[11:51:42] <faceface>	 I'm a composer noob... is it possible to use composer to update extensions?
[11:52:51] <faceface>	 Of the 44 directories in my extensions folder, I see 42 with a composer.json file
[11:54:26] <apergos>	 yes you can, that's why the files are there indeed
[11:54:41] <faceface>	 cool, just reading https://www.mediawiki.org/wiki/Composer
[11:54:55] <apergos>	 excellent
[11:54:58] <faceface>	 I have Composer 1.6.3 2018-01-31 16:28:17
[11:58:44] <faceface>	 I've read that page, but not sure how to update my extensions
[11:59:28] <faceface>	 looking at composer.local.json it looks like I've been handling extensions using git rather than composer
[11:59:45] <apergos>	 that's also fine
[12:00:00] <apergos>	 if you use a wmf branch that's expected in fact; the extensions are all submodules
[12:00:09] <faceface>	 I have installed semantic-bundle with composer, so now I have a mix :-/
[12:01:11] <apergos>	 :-D
[12:01:28] <apergos>	 I only work from the wmf branches so it's submodules all the time 
[12:01:53] <faceface>	 So I guess I can ignore the composer.json in the non semantic-bundle extensions and use composer to update semantic bundle?
[12:01:57] <faceface>	 cool
[12:04:05] <faceface>	 This feels dumb.... for f in $(ls -d */.git); do d=${f%/.git}; echo $d; cd $d; git fetch; cd ../; done 
[12:04:33] <faceface>	 next I'll do status, then pull
[12:04:38] <faceface>	 I'm on rel_33
[12:05:32] <faceface>	 Ah, all extensions on origin/REL1_33 are up to date :-)
[12:06:31] <faceface>	 hmm... WebAuthn only has rel1_3[4-6] :-/
[12:09:58] <faceface>	 Long story short, I want Extension:GoogleLogin, not sure if Extension:OATHAuth (and Extension:WebAuthn) will conflict with that..
[12:16:19] <apergos>	 I don't know about that
[12:16:31] <apergos>	 we're on 1.37.0-wmf something around here now :-D
[12:18:43] <faceface>	 cool... so... after performing a code and database backup, do I just git checkout rel_37 && update.php ?
[12:23:31] <Majavah>	 1.35 is the latest public release
[12:23:38] <Majavah>	 s/public/stable
[12:24:01] <apergos>	 oh yeah don't even try 1.37, it's not real yet
[12:24:16] <apergos>	 it's just starting to accumulate first bits of work
[12:24:33] <faceface>	 cool cool
[12:24:43] <apergos>	 and you'll want a stable release unless you're committed to being on the frequent update train (some folks are)
[12:26:15] <faceface>	 I'm stuck configuring GoogleLogin... APIs Auth... waaaa
[12:26:31] <faceface>	 "Go to APIS & AUTH" ... where that?
[12:28:30] <apergos>	 ugh no, I'll stand way away from that and wish you the very best of luck :-D
[12:32:24] <Jhs>	 Hi! I could use some help with running jobs. The case is:
[12:32:57] <Jhs>	 We upgraded our wiki to 1.35, but unbeknownst to be, DynamicPageList (which the wiki depends heavily on) wasn't upgraded for 1.35
[12:33:23] <Jhs>	 So after some fixing, we have switched over to DynamicPageList3, which is 1.35 compatible, and stuff is working
[12:33:48] <Jhs>	 However, in the meantime, DPL caused some jobs to fail, and when we run showJobs.php now, they are listed as "abandoned"
[12:34:04] <Jhs>	 We have ran runJobs.php multiple times, but the abandoned jobs are still… will, abandoned
[12:34:15] <Jhs>	 so my question is: How can we force run the abandoned jobs?
[12:34:46] <Jhs>	 Users are noticing a lot of these side-effects, especially the fact that some pages don't appear in the categories they should be in
[12:34:52] <Jhs>	  There are about 1,000 abandoned jobs
[12:35:26] <Jhs>	 and yes, I've tried null editing and even almost-null editing (adding whitespace etc) to the affected articles, but they still aren't added to the right categories
[12:45:12] <faceface>	 apergos: thanks... I got the ID's in the end, but get a fail none the les
[12:45:19] <faceface>	 Fatal exception of type "Error"
[13:00:28] <Vulpix>	 Jhs: there's a maintenance/manageJobs.php script
[13:00:57] <Vulpix>	 looks like you can pass  an  --action=repush-abandoned parameter
[13:01:28] <Jhs>	 Vulpix, aha! Thanks! The documentation is ... lacking: https://www.mediawiki.org/wiki/Manual:ManageJobs.php
[13:01:33] <Jhs>	 where did you find out about that parameter?
[13:01:56] <Vulpix>	 Looking at the source code
[13:02:10] <Vulpix>	 However, executing it with --help  parameter will also display it
[13:02:20] <Jhs>	 nice
[13:02:26] <Jhs>	 will give it a shot. thanks!
[13:10:57] <Jhs>	 Vulpix, if i understand the code in manageJobs.php correctly, it will put them back in the queue, but not actually perform them? So Iˈd need to do `manageJobs.php --action=repush abandoned` and then `runJobs.php`?
[13:11:59] <faceface>	 Florian is sometimes in here I think?
[13:12:22] <Reedy>	 I've not seen Florian around for a while
[13:13:01] <faceface>	 hi Reedy 
[13:13:10] <faceface>	 How do I create an issue here: https://phabricator.wikimedia.org/project/profile/23/
[13:13:31] <Reedy>	 Same way you create any issue
[13:13:44] <faceface>	 what is an any issue? ;-P
[13:13:45] <Reedy>	 use https://phabricator.wikimedia.org/maniphest/task/edit/form/1/ and tag with GoogleLogin
[13:13:49] <faceface>	 thanks
[13:16:23] <Vulpix>	 Jhs: Yes, apparently. This script manages jobs but doesn't execute them
[13:17:03] <Reedy>	 well, it'll depend on your job queue setup
[13:17:16] <Reedy>	 if you've got some runner in the background... it'll pick them up eventually
[13:17:32] <Reedy>	 if your setup is you need to run runJobs.php manually... well, surprise, you need to run runJobs.php manually
[13:17:44] <Jhs>	 hehe, true
[13:18:27] <Jhs>	 we have $wgJobRunRate set to 1, and it seems to be working as intended
[13:18:48] <Jhs>	 but for the abandoned ones iˈd really like to verify if this actually gets done
[13:18:58] <Jhs>	 and ~1,000 -> 0 would be a pretty good indicator ;-)
[13:34:10] <faceface>	 https://phabricator.wikimedia.org/T280671
[13:34:11] <faceface>	 IDK
[13:34:13] <faceface>	 lost
[13:57:13] <Reedy>	 faceface: fyi, REL1_33 has been unsupported for a while
[13:57:28] <Reedy>	 EOL June 2020
[13:58:02] <Reedy>	 And the error you list looks like you've not run composer
[13:58:08] <Reedy>	 (in/for the extension)
[14:02:39] <faceface>	 Reedy: thanks for this info, I checked it out from Git
[14:03:04] <faceface>	 Reedy: TO update to 35, I copy the files, take a database backup and just git pull / update?
[14:03:10] <Reedy>	 !update
[14:03:10] <wm-bot>	 update.php is a script that updates the database tables. You usually need to run it after upgrading MediaWiki or installing certain extensions. For details, see <http://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script>
[14:03:15] <Reedy>	 !upgrade
[14:03:15] <wm-bot>	 http://www.mediawiki.org/wiki/Manual:Upgrading
[14:03:18] <Reedy>	 gj bo
[14:03:19] <Reedy>	 t
[14:03:29] <faceface>	 yeah... there is just so much on that page
[14:03:40] <faceface>	 wondering if it boils down to the above...
[14:07:19] <absorto>	 faceface: it is basically two steps, 1. get the new codebase 2. run the update.php script that will perform all the changes on your db
[14:07:40] <faceface>	 absorto: cool
[14:08:25] <absorto>	 for step 1 it can either be a simple switch of branches if you rather using git or download and extract the new codebase
[14:09:01] <absorto>	 if you use aditional extensions, you will need to add those also :)
[14:09:26] <faceface>	 'add those'?
[14:09:31] <faceface>	 I have extensions from git
[14:09:36] <faceface>	 also some from composer
[14:09:44] <faceface>	 14:58 <@Reedy> And the error you list looks like you've not run composer
[14:10:03] <faceface>	 ^^ What does 'run composer' mean in this context? I've checked out the extension from Git...
[14:10:14] <Reedy>	 https://www.mediawiki.org/wiki/Extension:GoogleLogin#Installation
[14:10:20] <Reedy>	 >Only when installing from git run Composer to install PHP dependencies, by issuing composer install --no-dev in the extension directory.
[14:10:30] <faceface>	 ah...
[14:10:46] <faceface>	 I thought it was a case of git or composer... not both... I see the point about deps
[14:10:58] <faceface>	 Do I run that within the extension directory?
[14:12:20] <absorto>	 faceface: yepp
[14:12:47] <Reedy>	 it does say "in the extension directory"
[14:14:52] <faceface>	 sorry, thank you
[14:18:23] <faceface>	 Make sure ./wiki/extensions/GoogleLogin/cache is writeable for the Webserver's user ... I guess that is within the mw base directory?
[14:18:39] <faceface>	 ah... wiki probably means 'yourwiki'
[14:20:19] <faceface>	 Hey! WOrking! ... Kinda... The supplied credentials are not associated with any user on this wiki.
[14:35:46] <faceface>	 thanks also for updating the ticket. I've added the new 'error' ... probably due to google changing things around 
[14:36:58] <faceface>	 Somehow every time I update I commit to reading every document, then just give up and swap the files over and hope for the best
[17:39:18] <legoktm>	 https://www.youtube.com/watch?v=b5BZTyzbx_4
[17:39:32] <legoktm>	 the EMWCon panel on Enterprise MediaWiki and Wikimedia is starting now
[22:44:07] <Sazpaimon>	 is it possible to allow uploads of files with no extension?
[22:44:22] <Sazpaimon>	 I want to offer a download, but the file needs to be a specific name with no extension
[22:54:48] <Sazpaimon>	 i just commented out the restriction in UploadBase and it seemed to work
[22:57:43] <Reedy>	 https://www.mediawiki.org/wiki/Manual:$wgStrictFileExtensions
[22:57:51] <Reedy>	 >If set to false, users will be able to upload files with almost any extension
[22:57:57] <Reedy>	 I dunno if that works for "no extension"
[22:58:04] <Sazpaimon>	 yeah, no extension is not one of them
[22:58:39] <Sazpaimon>	 there's a hardcoded restriction in UploadBase: https://github.com/wikimedia/mediawiki/blob/686abd50bf96cde41518db0fe17c156185acfca4/includes/upload/UploadBase.php#L1071-L1075
[23:06:43] <Reedy>	 looks like it's purposely been done that way for 12 years