[02:38:04] can I branch on a $_GET parameter in VectorTemplate.php? [06:42:02] i like this custom table of contents template: https://en.wikipedia.org/wiki/Template:List_TOC_Letters [06:42:14] i tried to copy it just now, and noticed that it probably includes some CSS hacks, additional templates, etc [06:42:40] is there some kind of package for this? do i need to reverse engineer this to get it into my wiki [12:40:56] khalella: The latter. "Packages" do not exist [13:13:23] thanks andre__ [17:16:12] So I want my skin to show/hide ui elements based on an HTTP GET parameter... what's the best way to do that? [17:18:34] mwasteland: Its going to depend on the UI element in question and what you are doing [17:18:48] But I would say the initPage method of the Skin template [17:18:53] * bawolff not a skin expert [17:19:35] The OutputPage object can get url parameters via $out->getRequest()->getVal( 'name of param', 'default' ); [17:20:09] or maybe in prepareTemplate [17:20:14] * bawolff really doesn't know much about skins [17:20:39] it probably doesn't matter that much where you do it, as long as its somewhere that isn't in parser cache (which is most of skin) [17:26:31] I want to show/hide mediawiki generated nav elements like search bar, user info, sidebar, etc. [17:31:04] Can I just call $_GET from within VectorTemplate execute method? [17:32:09] It'd probably be more proper to override buildSidebar() method and friends [17:33:26] :) k [17:33:37] However, it would probably work to just do it in execute [17:34:01] Although, more proper mediawiki way would be $this->getRequest()->getVal() instead of calling $_GET directly [17:41:49] thanks bawolff [21:20:14] I have a rather weird error during an install/upgrade. MW is now placed in an empty directory, and I get this message about missing dependencies and nothing more. [21:20:20] http://kunsthistorie.com/w/ [21:21:38] The ISP claims they have a working install of MW 1.31.1 on their test domain, but I can't get this to work. [21:22:51] I suspects the test domain isn't configured the same way as their production domain, but as I don't have a link to the test domain I can't check it out. [21:23:14] Any idea how I might get some additional info on whats failing? [21:25:35] This is really an upgrade from MW 1.18, but the present w-dir is a clean install, but with the old LocalSettings.php. I can remove that and call /w/mw-config/ but I get the same result. [21:26:51] jeblad: you have a vendor folder? [21:29:56] This is the console-less webhotel variety of ISPs. And I did not have a vendor folder from before. [21:30:44] Nope, no vendor folder [21:31:00] how did you install MW 1.31.1 ? [21:31:20] the tar you download *does* include a vendor folder [21:31:53] used the tar ball, downloaded locally, repackaged to a zip-file [21:31:59] (alternatively, you could populate it using composer, but this suggests you didn't install it properly) [21:32:10] can you provide the url for that tarball? [21:33:44] Got it from https://www.mediawiki.org/wiki/Download [21:34:02] I can double check the content of the tar ball [21:34:34] https://releases.wikimedia.org/mediawiki/1.31/mediawiki-1.31.1.tar.gz does contain a vendor folder [21:35:07] so, if there's any wrong link/tarball floating around we will want to fix it [21:35:30] you are not the first one facing this, btw [21:36:43] Checking the tar ball it contains a vendor folder, but checking my upload there is no vendor folder there… WTF if I may… [21:37:43] I'll try to retrace my steps and see whats happen. [21:40:25] that's... funny [21:40:29] who stole the vendor folder? xD [21:46:30] I'll blame the cat… He is always up to something! [21:46:45] :) [21:48:23] It seems like they disappeared when I recreated the zip-archive [21:49:46] The strange thing is, I packaged two wersions and the same thing happen with both of them [21:50:05] a faulty archiver? [21:50:11] 1.30 and 1.31 in the same zip-archive [21:50:24] it seems weird that it dislikes folders named vendor, but.. [21:50:38] which software are you using? [21:51:48] This is on a Ubu 18.04.1, with the ordinary archive software [21:51:58] the gui thingy [21:52:13] brb [21:52:38] that would be file-roller I think [21:53:00] probably, there is no about-entry anymore [21:55:49] OMG! Its up! O_O [21:56:53] :) [21:57:36] The vendor folder is in the tar ball, it is in the unpacked hierarchy, it is gone in the new zip-archive [21:58:36] I just tested and was able to put the mediawiki-1.31.1 folder into a zip file with file-roller [21:58:38] jeblad: My sisters cats have decided to chew on my macbook charger and break it [21:58:48] including the vendor folder [21:59:29] the vendor folder is the last one alphabetically [21:59:49] maybe you selected "everything" and missed that? :S [22:00:24] * Platonides wonders why we need 13k files [22:00:30] I selected the root folder [22:03:03] I wonder, there are a lot of files in the vendor folder and my disk was almost full (98% -ish). Perhaps it maxed out on inodes… [22:03:40] $ find mediawiki-1.31.1 -type f | wc -l [22:03:41] 13842 [22:03:52] $ find mediawiki-1.31.1/vendor/ -type f | wc -l [22:03:52] 760 [22:04:31] if it's in the extracted files, I don't think it would matter [22:04:49] archiving should read all those files and put them into a single inode [22:05:01] perhaps 2-3 if using some temporary files for that [22:07:53] Reedy: that's because they wanted to be powerful [22:08:37] I guess it would be hard to figure out what happen, and we don't have any obvious place to keep notes about upstream bugs [22:09:26] But it is strange the same thing happen with *two* folders inside the same zip-archive [22:09:56] I'd love to understand what happened [22:12:39] ying and yang collided, and we need a black diamond and a witch to understand why [22:13:13] 12 [22:13:23] …or simply put Reedy on the problem. [22:13:32] well, maybe that's too complex then [22:13:41] (putting witches on the problem, not Reedy)