Skin talk:Medik

Currently I don't think there is any way of knowing at a glance whether the Discussion page has content. The link is the same colour for both (not, for example, blue for content and red for empty). Is there any way of changing this? Thanks.

Hello We are in the process of building a wiki about the history of our community. I'm using the great Medik skin, but I can't find a solution for the text flow around images for viewing on mobile devices. I want the text flow on mobile devices to stop at the top of the image and continue at the bottom after the image. That's how it should be: For me it looks like this, as the image is inserted on the right, the text is squeezed in on the left. This is how the image is with me: How can I correct this?

Mediawiki 1.40.0, Medik 5.1.3

Translation updates from translatewiki.net are possible on GitHub, too. The current setup on translatewiki.net needs to be changed from Bitbucket to GitHub. For GitHub, it would look like, e.g. https://gerrit.wikimedia.org/r/c/translatewiki/+/595471/

Hi Everyone,

We updated our Ubuntu 20.04.6 fully patched machine running Mediawiki 1.38.5. Our MW installation includes Skins from GitHub (and not the static zip files). It is easier to use GitHub because we only need to checkout the REL1_38 branch to get the latest version of the skin.

We are stuck at MediaWiki 1.38 at the moment. MW 1.39 requires Composer 2, but Ubuntu 20.04 does not provide it. We are waiting for our web host to offer Ubuntu 22.04. Composer 2 will be available with Ubuntu 22.04, and then we can upgrade to MW 1.39.

Restarting Apache results in:

``` Fatal error: Uncaught ExtensionDependencyError: Medik is not compatible with the current MediaWiki core (version 1.38.5), it requires: >= 1.39.0. in /var/www/html/w/includes/registration/ExtensionRegistry.php:432 Stack trace: #0 /var/www/html/w/includes/registration/ExtensionRegistry.php(255): ExtensionRegistry->readFromQueue() #1 /var/www/html/w/includes/Setup.php(252): ExtensionRegistry->loadFromQueue() #2 /var/www/html/w/includes/WebStart.php(93): require_once('/var/www/html/w...') #3 /var/www/html/w/index.php(44): require('/var/www/html/w...') #4 {main} thrown in /var/www/html/w/includes/registration/ExtensionRegistry.php on line 432 ```

Based on the output of our update script, it looks like Medik lacks Mediawiki's standard branches. Below, it looks like `REL1_38` is missing.

``` Updating skin medik Entering /var/www/html/w/skins/medik REL1_38 branch not found remote: Enumerating objects: 23, done. remote: Counting objects: 100% (23/23), done. remote: Compressing objects: 100% (16/16), done. remote: Total 18 (delta 13), reused 3 (delta 2), pack-reused 0 Unpacking objects: 100% (18/18), 2.14 KiB | 168.00 KiB/s, done. From https://bitbucket.org/wikiskripta/medik

  5046528..3c42a90  master     -> origin/master

HEAD is now at 3c42a90 Merged in mw39 (pull request #8) Branch master ```

Yes, the skin is on Bitbucket and does not have branches. The issue with the master branch for 1.38 is expected. Master brought more or less full support for 1.39. Version v3.2.7 should still support 1.38. Given the time constraints of the programmers involved, doing some backward-compatible shim appeared not feasible.

Anyhow, I think it is best to clone the code into your own repo on GitHub and fetch the desired code from there. At least, this is what I do when encountering issues like that.

@Noloader Yes, @Kghbln is correct; Medik v4.0.0 is intended for MW 1.39+, however you can use "git checkout v3.2.7" to go back to version that supports MW 1.38.

tagged

Wouldn't it make sense to tag this commit as v4.0.3 for users that want to get a cleaned up version but not yet move to v5.0.0?

Asking since I cannot upgrade right now since I am using BootstrapComponents, which does not yet support Bootstrap 5.

Ah, sure, done. :-)

Cool. Thanks a bunch!

Hi. I've noticed while on our wiki today that a substantial whitespace is now appearing below the footer of shorter pages. IDK what's going on, but I've determined it's not our custom stylesheets because the problem was still apparent when I tried safemode. Currently assuming it's a bug with the skin itself. Example page: https://avid.miraheze.org/wiki/File:AVID_Favicon_-_High_Quality.png

Hi, thanks for reporting this. I'm not sure it's a Medik bug: Monobook does the same on your wiki. Maybe some incompatibility of CSS's or ads? But I'll explore it further certainly.

Hi. A member of our Discord managed to crack the problem. He was able to fix it using "firstHeading::before {position:fixed;}"

I found that "firstHeading::before {display:none;}" also solved it.

Tracked on bitbucket.org with issue 25.

Some of the articles on my wiki are very long, and I'm not using the MobileFrontend extension. So I made a gadget on my wiki to make the H2 headers collapsible, and start in a default collapsed state, when the user has a screen width of under 768px. This makes it easier to read long articles. The user can open the section they want without scrolling through unwanted information. I think it compliments nicely with this skin because the contents box is disabled on Medik. I got the idea from https://inclusive-components.design/collapsible-sections/ but had to downgrade the javascript from ES6

To install

1. copy the code from User:InnerCitadel/Gadget-collapsibleH2.js to your wiki in a page called MediaWiki:Gadget-collapsibleH2.js
2. Go to MediaWiki:Gadgets-definition and add the line "*collapsibleH2[ResourceLoader|default]|collapsibleH2.js"
3. Go to MediaWiki:Gadget-collapsibleH2 and add a description like Collapsible H2: in long articles on mobile, make the headers collapsible, with a default collapsed state
4. Add some CSS to MediaWiki:Common.css eg this CSS
5. If you want to display the edit button then add into MediaWiki:Common.css the following code .mw-editsection{display:block;}

It will only make the headers in longer articles collapse. You can change this behaviour by changing the length variable in line 11 of the script.

Is it possible to replicate this in PHP through the skin directly?

Wow, what a nice idea! Many thanks, @InnerCitadel, I'll certainly try it in the next week and let you know.

Hi Jeremy, we still discuss that in our team (maybe I'll create some configuration option for this), so stay tuned and don't worry, I'll definitely make this done. :-) Created a proposal issue for myself not to forget - https://bitbucket.org/wikiskripta/medik/issues/25/collapsible-headers.

Thanks a lot again, this is really a nice idea.

I think this is a valid feature request. Having a configuration parameter will be nice.

Not able to do that

I'm looking to customize the "flex row" at the top of the page. The one with the "Page", "Discussions", "Actions", and "Tools" buttons.

For my wiki, I do not use talk pages, but I'm always editing the page. I'd like to stick "Discussion" into the Actions dropdown, and pull out Edit and Edit Source. Is this something that could be configured?

However, more generally, I'd like to be able to somehow tag the items in the dropdowns to appear on the main bar, unless the screen has been shrunk down to a smaller size, and then have those items return to the dropdown.

Hello @Nick2253, thank you for using my skin! Unfortunately, this is way too complex proposal for me, I'm not able to implement this. If you are able to do this or know someone who is fluent in MediaWiki programming, just point them to the source code repository: https://bitbucket.org/wikiskripta/medik/. I'm open to pull requests! Thank you.

Not yet

instead of using the 135x155px logo, is it possible to use the new logo style with icon, wordmark and tagline instead?

Hi @NutchapolSal, unfortunately, not yet... sorry.

Tracked with issue 37 and resolved by @Morne Alberts.

We just upgraded from Mediawiki 1.36 to 1.38. Medik is having trouble with 1.38:

Deprecated: Use of BaseTemplate::getAfterPortlet was deprecated in MediaWiki 1.35. [Called from MedikTemplate::getPortlet in /var/www/html/w/skins/medik/includes/MedikTemplate.php at line 622] in /var/www/html/w/includes/debug/MWDebug.php on line 377

Noloader (talk) 21:25, 4 July 2022 (UTC)

Thank you for reporting. Tracked with issue 37.