[00:56:20] <rundg[m]>	 biberao: I'm not setup for IRC at the moment. (email is greg.rundlett@gmail.com)
[00:56:31] <biberao>	 ok
[01:01:22] <rundg[m]>	 s/@/ AT /, s/.com//
[01:01:45] <biberao>	 lol
[01:02:31] <rundg[m]>	 Google's spam filters are pretty darn good, but why unleash another million spambots?
[01:03:49] <biberao>	 ya
[01:22:49] <Noisytoot>	 You've already sent the message, and IRC doesn't have message editing
[01:23:34] <biberao>	 ya its sad
[01:23:37] <moonmoon>	 (and this channel is publicly logged on the IRC side)
[01:23:41] <biberao>	 rundg[m]: take a tissue
[03:15:06] <Guest67>	 Hello, I installed a fresh MediaWiki 1.39 but I notice that the login option is not showing anymore is there a bug?
[03:18:35] <Guest67>	 The issue is with Vector-2022
[03:26:59] <Guest67>	 The login button is showing if I switch to old Vector skin but if I switch to Vector-2022 it stop showing.
[03:36:43] <atxatx4928[m]>	 Try to do a clean install of the Vector skin to see if it fixes it
[03:39:10] <Guest67>	 Ok let me try reinstalling the vector skin.
[03:44:49] <Guest67>	 atxatx4928[m] getting the following error after installing vector 1.39
[03:44:50] <Guest67>	 RuntimeException: Could not find template `UserLinks__login` at includes/templates/UserLinks__login.mustache
[03:45:29] <atxatx4928[m]>	 Okay first delete the whole Vector folder from your installation. Then download the 1.39 version of Vector and try again
[03:45:49] <atxatx4928[m]>	 It could be leftover files that are triggering it
[03:45:51] <Guest67>	 That's exactly what I did.
[03:46:37] <atxatx4928[m]>	 Then it could be Mustache cache, though I am not sure how to clear it
[03:46:47] <Guest67>	 Do I need to pull Dependencies?
[03:47:10] <atxatx4928[m]>	 Vector does not have dependencies
[03:47:21] <Guest67>	 Ok
[03:47:55] <Guest67>	 It is working well with 1.38 but after installing 1.39 in a new folder login stop appearing.
[03:50:12] <atxatx4928[m]>	 Yes there are a lot of changes on how the user menu is generated since Vector is being actively developed
[03:51:16] <atxatx4928[m]>	 When you updated to 1.39, did you run composer?
[03:52:46] <Guest67>	 I didn't updated, I installed a fresh wiki on a sub domain.
[03:59:30] <Guest67>	 The error disappeared but login option is still missing.
[04:10:39] <Guest67>	 I'm going ahead reinstalling Mediawiki in a new folder to check if I still face this issue.
[06:39:36] <Guest67>	 Hi, I re-insatlled a fresh version of MediaWiki 1.39 but I'm getting around a few issues:
[06:39:36] <Guest67>	 -- When I create or edit a page in code editor I get "Sorry! We could not process your edit due to a loss of session data" error
[06:39:37] <Guest67>	 -- When I move a page without checking "leave a redirect behind" nothing happen and if I check "leave a redirect behind" the page move successfully.
[06:39:37] <Guest67>	 -- If I try to delete a page nothing happens.
[06:39:37] <Guest67>	 -- If I try to protect a page I see the same lose of session data error
[06:39:38] <Guest67>	 So is there any solution for to make it fully functional?
[06:39:39] <Guest67>	 Thank you
[06:42:37] <Guest67>	 Also, I tried to run "composer update --no-dev" but I'm getting the following error:
[06:42:38] <Guest67>	  [Composer\Downloader\TransportException]
[06:42:38] <Guest67>	   curl error 7 while downloading https://repo.packagist.org/p2/cssjanus/cssjanus.json: Failed to connect to repo.packagist.org por
[06:42:39] <Guest67>	   t 443: Connection refused
[06:49:25] <Guest67>	 The above issue was connected to the main cache setting. I disabled cache and move, delete, protect, edit all working.
[06:49:43] <Guest67>	 But still getting the issue while updating using composer.
[11:17:55] <Nemo_bis>	 Everyone join FOSDEM in February 2023! https://www.mediawiki.org/wiki/Events/FOSDEM/2023
[13:22:16] <nono|sysadminlqd>	 ❓️ -> Hello, does anyone know of a way to completely export a mediawiki to static HTML ( a perfect copy, with files, images, and such )  for archiving purpose ?
[13:22:16] <nono|sysadminlqd>	 Thanks !
[13:23:54] <Reedy>	 Something like https://github.com/openzim/mwoffliner maybe
[13:37:39] <nono|sysadminlqd>	 <Reedy> "Something like https://github...." <- Thanks ! Seems complicated to install but I'll give a try :)
[13:39:20] <Reedy>	 you didn't specify easy ;)
[13:39:29] <Reedy>	 But there's probably not many easy ones
[15:21:42] <nono|sysadminlqd>	 It seems to fail on install because it calls a ssh link to github, sadly :/
[15:21:46] <nono|sysadminlqd>	 Thanks for the tip anyways !
[17:02:04] <biberao>	 hi
[17:03:46] <Reedy>	 nono|sysadminlqd: should be doable with ssh...
[17:03:53] <Reedy>	 and/or easily fixed
[17:07:45] <biberao>	 Is it possible to have a mediawiki new installation with a preloaded Bootstrap extension somewhere?
[17:08:29] <Reedy>	 What do you mean by preloaded Bootstrap extension?
[17:09:45] <biberao>	 Like on the installer lets say you select chameleon and it complains Bootstrap not installed(lets say its not the correct term) but its present on the extensions folder. Is it possible to have a default config or some mechanism to add it to LocalSettings.php?
[17:14:47] <Reedy>	 If you include the extension in the MW dir before you run the installer, it should offer to install/enable it
[17:15:13] <biberao>	 weird
[17:15:19] <biberao>	 let me recheck
[17:15:27] <Reedy>	 however...
[17:15:32] <Reedy>	 https://github.com/ProfessionalWiki/chameleon/blob/master/composer.json#L38
[17:15:50] <biberao>	 thats how i fixed it
[17:15:59] <biberao>	 i added bootstrap to composer
[17:16:09] <Reedy>	 I belive that's their desired install step
[17:16:23] <Reedy>	 If it was available via our extension distributor, it would've bundled it for you
[17:17:09] <biberao>	 it seems our installer
[17:17:12] <biberao>	 or version
[17:17:18] <biberao>	 i guess
[17:17:27] <biberao>	 doesnt have that require on composer.json
[17:18:20] <biberao>	 ah professionalwiki its not official chameleon?
[17:18:38] <Reedy>	 ?
[17:18:39] <biberao>	 or is it?
[17:18:46] <Reedy>	 I thought that was the official/canonical
[17:18:48] <biberao>	 oh it is
[17:18:49] <biberao>	 im sorry
[17:18:59] <biberao>	 Reedy: i didnt remember
[17:19:21] <Reedy>	 it's all good, it gets confusing occasioanlly when stuff moves back and forth
[17:19:57] <biberao>	 the version we got the composer.json doesnt have mediawiki/bootstrap
[17:20:36] <biberao>	 question btw is it normal after a new install to run composer to update?
[17:20:39] <Reedy>	 how old of a version have you got? :P
[17:20:40] <Reedy>	 https://github.com/ProfessionalWiki/chameleon/commit/6756fec029aa23d9ed7fedbb33a8ed4cf3e48d38
[17:20:58] <Reedy>	 It all depends on how you're installing MW, and what extensions you install too
[17:21:10] <biberao>	 1.35.9
[17:21:15] <biberao>	 nopw the commit let me see
[17:22:17] <biberao>	 oh
[17:22:20] <biberao>	 im sorry
[17:22:21] <biberao>	 im going blind
[17:23:01] <biberao>	 after all we have a working version with mediawiki/bootstrap
[17:23:09] <biberao>	 and a working composer.json
[17:23:34] <biberao>	 bootstrap just isnt loaded by the mediawiki install
[17:24:14] <biberao>	 only after a manual install with composer and add wfLoadExtension( 'ExtensionName' ); thingy
[17:24:55] <Reedy>	 considering bootstrap is a MW extension, installed via composer... it's not really supported
[17:26:48] <Reedy>	 So not a complete surprise that the installer doesn't behave great
[17:27:40] <biberao>	 so the skins are all enabled automatically
[17:27:46] <biberao>	 not the extensions
[17:28:45] <Reedy>	 https://phabricator.wikimedia.org/T250406 etc
[17:30:39] <biberao>	 i see thanks
[19:11:16] <atxatx4928[m]>	 In that case with T249573, should extensions and skins be published to packagist/composer nowadays?
[19:11:17] <stashbot>	 T249573: RFC: Remove ability to install extensions and skins with Composer - https://phabricator.wikimedia.org/T249573
[19:12:27] <Reedy>	 We've never advised/suggested people do that
[19:35:10] <rundg[m]>	 atxatx#4928: It is not necessary to publish extensions or skins to make them manageable with composer.  All you need have is a 'valid' composer.json file in your extension/skin repo. T311321 
[19:35:10] <stashbot>	 T311321: In many extensions, composer.json doesn't validate to spec - https://phabricator.wikimedia.org/T311321
[19:38:22] <atxatx4928[m]>	 It seems that non-Gerrit extensions and skins need to be requested to published under the MediaWiki vendor right?
[19:39:01] <rundg[m]>	 rephrase?
[19:42:04] <atxatx4928[m]>	 On top of having a valid composer.json, non-gerrit extensions/skin need to be published to packagist manually. I see a pattern of extensions and skins publishing under the mediawiki vendor namespace (both WMF and third party), which is restricted
[19:42:55] <atxatx4928[m]>	 Since Reedy is one of the owners of the said vendor namespace, I'm just wondering what the current best practice is
[19:44:04] <atxatx4928[m]>	 I have seen conflicting statement/opinion on whether people use composer for extensions/skins and whether developers should publish them on Packagist
[19:45:46] <rundg[m]>	 It is not required to publish a package to make it manageable via Composer. Publishing only makes it easier to discover.
[19:46:18] <rundg[m]>	 Packagist is searched by default, so publishing there does make it easier to discover.
[19:54:05] <rundg[m]>	 Putting code on Gerrit, GitHub, or GitLab with a full composer.json file is sufficient because your composer.local.json only needs two extra lines
[19:54:05] <rundg[m]>	 For package discovery, all you need to do normally (without Packagist nor any official package registry) is add a two line entry in the **repositories** section of composer.local.json - providing the package name and GitHub url for example.
[19:57:57] <rundg[m]>	 I honestly do not know what the policy or procedure is for getting a package (ie. skin or extension) officially listed in Packagist under the 'mediawiki' vendor namespace. I do know it's common practice (as it should be IMHO) to use that vendor namespace for any skin or extension for MediaWiki.
[19:58:40] <rundg[m]>	 I think it would be bad practice for every developer to use their name, or pet name, or company name for the vendor namespace in their composer.json
[20:01:10] <rundg[m]>	 Unless they also clearly offer support, perhaps have their own registry, do all testing and packaging of their extensions coordinated with every release of MediaWiki...
[20:11:05] <rundg[m]>	 Look at HalloWelt for example: They do offer support, have their own registry, do all the testing and packaging of their extensions coordinated with every release of MediaWiki, and still honor the 'official' vendor namespace for all the packages that you will find publicly otherwise: https://packages.bluespice.com/#mediawiki%2F They only use the 'bluespice' vendor for packages that might only be compatible with the BlueSpice foundation
[20:11:05] <rundg[m]>	 distribution. And, they're moving away from that toward making all their extensions compatible with 'vanilla' MediaWiki.
[23:56:44] <Charly[m]>	 Vendor namespace it should be imho.