Jdlrobson

Previous discussion was archived at User talk:Jdlrobson/Archive 1 on 2015-12-18.

The good and bad examples you've added to Recommendations for night mode compatibility on Wikimedia wikis#Target night mode using standard CSS class on HTML element AND media query are completely the same. Please try again.

Hello, nobody has programming experience on s:nl|the Netherlands wikisource . There are about 4 persons who try to keep that site alive. Whatever help you may give us, is thankfully accepted. The introduction of the proofread-projet, as late as 2016, has never completely done. Maybe you can help to add a working ''header=1'' functionality to the tag ''pages index=''. Also several gadgets never have been installed. Thanks a lot for any adjustment you make.

Hi. Can you please remove me as a subscriber from this task here: https://phabricator.wikimedia.org/T328719 It seems like I can not do this by myself and I can not help with this task. Best Regards --KleinerKorrektor (talk) 19:15, 24 February 2023 (UTC)

Thank you! --KleinerKorrektor (talk) 22:06, 25 February 2023 (UTC)

Hi Jon!

I was reading your post about the impact of removing srcset from mobile pageviews, and I was impressed by the amount that it reduced the image bandwidth. Do you think the reduction in 2G load time is due to devices that are running on 2G that were previously requesting the 2x version of the image, but now are forced to request the 1x version? Or is there some other explanation? I know that at least back in 2015-16 there were some bugs in browser engines that would request both the "src" image and also one of the "srcset" entries as well, although I think those have generally been fixed.

I'm also curious whether those graphs might have overestimated the effect, due to the issue Brion brought up on T134115#2257578 (sorry, AbuseFilter is blocking me from making that into a link!) which would have caused the non-srcset versions of pages to sometimes display to desktop users as well. It's a bit weird though because I think then (and even now) the majority of "retina" displays were mobile.

Also wondering whether most of those gains would have been eaten up by Reading/Web/Lazy loading of images on all wikis anyway, but that's probably harder to answer after-the-fact.

I'm mainly asking because naively, it seems like this change (plus Brion's addition to the parser cache key) roughly doubles the number of parser cache misses, because now mobile and desktop pages need to use entirely separate cache entries. Am I missing something that makes it not that way, or makes that less of a problem than I (not being associated with WMF at all) would think?

Thanks!

Hey CookMePlox, thanks for reading through and reaching out.

My knowledge is a little hazy here, but as I recall, the fully load time was the time to load all assets in the page, and that included images, so by reducing the payload of most of the images from 2x to 1x, there was less to load, and it could be loaded quicker.

My hope had been that reducing the payload of the HTTP requests there would be less competition and faster loaded resources on the critical path, but we never managed to prove that one way or the other.

Yes there was a bug a while back that loaded both srcset and src - I remember that one, and yes those should be fixed now.

I believe the Brion bug in phab:T134115#2257578 meant that depending on what got cached first, we were either stripping srcset from desktop articles, or including them on mobile. The data in those graphs is mobile only, so I think that would have underestimated impact if anything. Reading back the phab ticket, this problem got identified quickly and fixed May 2nd 2016 with a purge, so I don't think it would have impacted those graphs for the days that followed.

Yes to the cache misses problem. The mobile and desktop cache differently. It would probably be a good project at this point to explore adding native lazy loading to desktop phab:T148047 and revising the mobile site to use it, so that the two can share a cache. Assuming nothing else varies the cache, that would have quite the impact.

Lazy loading of images on all wikis had a more significant impact than the srcset removal. Not sure if you read this blog post, but that has a write up: https://diff.wikimedia.org/2016/09/19/mobile-web-improvements/

I might have deleted and recreated the 1.0.17 tag, and now the newer release of the skin is no longer deployed on it. Could you help me fix it? Thanks!

Hi Jdlrobson,

I just saw that you marked the Skin:MediaWikiBootstrap as Unstable. I know it does not work even in 1.36.

I found this issue a few weeks back and tried to search the related docs to update the skin. We also talked a few months back about upgrading the skin. I am kind of frustrated that Mediawiki is updating the skin system and there is no related doc at all. If any skin developer have to discover the list of methods from the codebase, that is the other way of saying, "Do not use MediaWiki" at all!

Can you please let me know where can I find the docs and help to build a skin which works. ~~~~

I'm not sure what docs you are looking for, but the skin is not working for some time due to usage of a function deprecated a long time ago.

https://github.com/nasirkhan/mediawiki-bootstrap/pull/15 should be all that's needed to fix it. Provided you are subscribed to deprecation notices (and the deprecation notices that should appear in your server logs and in your browser), all you should need to upgrade your skin is to follow the Release notes.

If you are building a skin from scratch against current master, Manual:How to make a MediaWiki skin documents exactly what you need to do. If you have an existing skin I'm not sure what documentation you are looking for so it would help if you were more specific with your queries so I can help you.

thank you for you help.

I do not regularly follow the mediawiki releases and did not updated the skin for a long time. So, even though I know that Release notes are the best place to look into while updating the skin. You updated one method which was deprecated in 1.36 and there might be other method calls while may deprecate on 1.37 or the next release. And structurally MediaWikiBootstrap and Example/SkinLabsSkin is different.

In summary I want to update the skin to Mustache but the skin will look similar.

If I read the Manual:Skinning Part 2 and Manual:Skinning Part 3 I would be able to built a PHP based skin. But if I want to build a Mustache based skin there is not equivalent amount of doc available.

I have a number of queries, those might look silly but as I do not building the skin system I do not have much info about those. Like I installed 1.37 and installed Example skin. After that I found that the logo is not visible, but there is a file on the LocalSettings logo path. What should i do now? How to set the Favicon? how can I show the language links? will I have to do anything for RTL language wiki? how to control the footer links? what are the steps to format the categories area? I also need to add Google Fonts, Icon fonts. how to show/hide the navigation menu items, how to format those? styling the search box, add an extra class/id with that, formatting the search box results. None of these questions have answers to that Manual:How to make a MediaWiki skin doc.

If you can answer to my queries, I also can write docs and update that single page as well.

Okay lots to digest here. I think a good starting point might be a migration guide of how to migrate a SkinTemplate skin to SkinMustache. I'll commit to writing one of those as that seems like it would be useful to others.

In terms of your questions, I would say these are good questions and thanks for asking them. I've raised the ones I've understood on the Manual_talk:How_to_make_a_MediaWiki_skin and will get to them when I can.

It would be helpful to expand on your other questions with time, to understand them better.

> "what are the steps to format the categories area? I also need to add Google Fonts, Icon fonts. how to show/hide the navigation menu items, how to format those? styling the search box, add an extra class/id with that, formatting the search box results."

I'm not 100% sure what's being asked here. Provided you've setup a CSS/LESS file you can put anything you want in there, including paths to resources such as downloaded fonts or Google Font URLs. You are also free to include libraries such as Icon fonts in the declarations. ResourceLoader/Developing_with_ResourceLoader has information on how that works if that's what's needed here. You are also free in your skin to add any HTML markup you need for styling things like the search box.

Some pages that may help you with your immediate questions around languages and icons:

• Logo: Manual:$wgLogos
• Favicon: Manual:FAQ#How do I change the icon in the browser.27s address line .28favicon.29.3F
• Language links: Manual:Interwiki

It would be really helpful if you can write a migration guide. When it will be ready it will be easier to prepare a doc to building a skin from scratch.

I can write my questions in details, but got confused about where to ask those! I did not asked those to Manual_talk:How_to_make_a_MediaWiki_skin as the questions are not specific to that page. Rather about those which are not included there. I asked to Project:Support desk, Discord and wikitech mailing list ( Topic:Wb1kvracyubak7se, Topic:Wb1rvgucmqffnsws, Topic:Wazztppvnjh62mo7, https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/HVS7OBF5YQEMY7MFAYRSQZNEMHJGA5VS/). Not no one have the time or knowledge to help, except you.

So first help I need is, a place where I can ask questions and get answers about MediaWiki. Should I ask everything to you, or if there is any group/ forum available?

Historically there has not been much interest in skin development for mediawiki (IMO) and a lot of the skin development does seem to happen in private. In 1.36 we began to challenge that by trying to simplify the creation process and poke existing skins to see it they were still being actively developed.

Manual_talk:How_to_make_a_MediaWiki_skin is probably the best place to ask questions as it's linked to the main page and the small group of us that does exist is at least aware of it.

I will ask questions to the Manual_talk:How_to_make_a_MediaWiki_skin page then. I hope I will be able to build a skin soon with intended customization.

I think you are not right that, people do not have interest on the skins. From my experience and issues I am facing so far, I can confidently say that people were demotivated and discouraged in a a number ways to build new skins and even using MediaWiki. This is done by the core community/staff members of MediaWiki. I asked a number of questions about some common customization needs like, logo, navigation, footer and so on. There is no answer available for those, without those answer how can someone new to the platform can build a skin?

You are the only person who is replying with some helpful information. But you are not the only one who is building and using the entire skin system. Where are others and which platform they are active in? You can check Topic:Wb1rvgucmqffnsws as a reference. The person trying to help may have the least info about the skin system. But I asked the question in the Support desk and there are a group of volunteers claim to be active there!

Wordpress is the most popular CMS and a major reason is their are docs and community member helping others and their theme/skin is easy to build/customize. So far the Wordpress websites I visit every day I probably not seen any site with the default theme, where as a big number of mediawiki sites are using default skin. It can not be the lack of interest to developing new skins.

There is no team at the Wikimedia Foundation supporting skins and no skin community site (wordpress on the other hand does that).

I am not questioning that people want to build skins and are put off from doing so, I am saying we do not have a community in the same way. The skins that are built are seldom shared as there is nowhere obvious to share them. Https://skins.wmflabs.org is an experiment in seeing what happens when skins are showcased, but this is being done by me in a volunteer capacity.

I have begun your migration guide. Questions at this early stage are welcomed Manual:How to make a MediaWiki skin/Migrating SkinTemplate based skins to SkinMustache

thanks for starting the migration guide. I will add my questions to Manual_talk:How_to_make_a_MediaWiki_skin and you can pick which you want to add in the migration guide.

I know there is no separate team to support skin, but my point was a skin in a part of MediaWiki not some outside thing. I support MediaWiki means, I support MediaWiki and all the core components including extension & skin systems.

The Wikimedia Foundation Board of Trustees is organizing a call for feedback about community selection processes between February 1 and March 14. While the Wikimedia Foundation and the movement have grown about five times in the past ten years, the Board’s structure and processes have remained basically the same. As the Board is designed today, we have a problem of capacity, performance, and lack of representation of the movement’s diversity. Our current processes to select individual volunteer and affiliate seats have some limitations. Direct elections tend to favor candidates from the leading language communities, regardless of how relevant their skills and experience might be in serving as a Board member, or contributing to the ability of the Board to perform its specific responsibilities. It is also a fact that the current processes have favored volunteers from North America and Western Europe. In the upcoming months, we need to renew three community seats and appoint three more community members in the new seats. This call for feedback is to see what processes can we all collaboratively design to promote and choose candidates that represent our movement and are prepared with the experience, skills, and insight to perform as trustees?

In this regard, two rounds of feedback meetings are being hosted to collect feedback from the technical communities in Wikimedia. Two rounds are being hosted with the same agenda, to accomodate people from various time zones across the globe. We will be discussing ideas proposed by the Board and the community to address the above mentioned problems. Please sign-up according to whatever is most comfortable to you. You are welcome to participate in both as well!

• Round 1 - Feb 25, 4:00 pm UTC
• Round 2 - Mar 4, 4:00 am UTC
• Sign-up and meeting details: Wikimedia Foundation Board of Trustees/Call for feedback: Community Board seats/Conversations/MediaWiki and Wikitech

Also, please share this with other volunteers who might be interested in this. Let me know if you have any questions. KCVelaga (WMF), 14:37, 21 February 2021 (UTC)

Hi, I have something like this:

• resources
  • css
  • images
    • de
      • Donate_Button.gif
    • en
      • Donate_Button.gif
    • es
      • Donate_Button.gif
    • fr
      • Donate_Button.gif

How can I prove, that "it/Donate_Button.gif" does not exist? --WikiForMen (talk) 13:49, 14 January 2021 (UTC)

I try to do stuff with hooks, but there are still issues unsolved:

• Extension:AgeClassification (Seems to work)
• Extension:WimaAdvertising (Still has issues)

--WikiForMen (talk) 20:14, 1 January 2021 (UTC)

Are the styling issues only in certain skins? If so, you can add skin specific styles which will be easier to maintain.

it's a bit outdated but Manual:$wgResourceModuleSkinStyles explains how you can do that (feel free to update that page)

and here's an example of it in action in Minerva:

https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/skin.json#L167

For Ad1 and AD2 could you use Manual:Hooks/SkinAfterPortlet to add HTML to an existing menu? I think all the Wikimedia skins should support that, and if not that's a bug.

You'd need to check $portlet parameter to check if its AD1 or AD2

Hook SkinAfterPortlet is to add additional text to the portlet, but NOT to modify the label of the portlet, I guess?

If you are modifying the label, you can only do that in MediaWiki:Sidebar, by a translateable message or by constructing a new portlet to the sidebar using Manual:SidebarBeforeOutput

A few general Q and As can be found here: User :Jdlrobson/Skins for extension developers#Q: I want to add a new "portal" menu to the sidebar.

I see. Now I can explain you, why this will not work. The labels should be translated, if you select an other language in personal settings. Depending on the purpose, the headings should be advertisement, event notice or hint. According to your suggestion, I would now have to change the entry in the navigation bar each time... I would like to avoid precisely this annoying workload.

Hook "SidebarBeforeOutput": If there are two advertising blocks, both should be called Advertisment. How should I differentiate when assigning the HTML snippet? Can this work?

This is the reason why I enter AD1 and AD2 as markers in the sidebar, I then have distinguishable markers to which I can assign an HTML snippet and in the hack of the skin I then bend the markers AD1 and AD2 to the labels, according to the variables $wgSidebarAd1Type and $wgSidebarAd2Type. And it is precisely this that cannot be implemented with all the available hooks.

Nor is it a question of creating a new "portal" SOMEWHERE. The advertising blocks must also be positioned appropriately in the sidebar in the sidebar. But this is precisely the purpose of the AD1 and AD2 markers.

That's why I decided to drill out the skins, because the task cannot be solved with the Mediawiki hooks.

And all "examples" of the hook shit going with the test/href scheme. Actually, it still needs its custom class specifications. I have to use tricks to display the advertising blocks appropriately (background colour, spacing, border if necessary).--WikiForMen (talk) 21:56, 2 January 2021 (UTC)

The documentation is so unsatisfactory that I do not understand what the difference between Manual:Hooks/SidebarBeforeOutput and Manual:Hooks/SkinBuildSidebar is supposed to be. --WikiForMen (talk) 22:26, 2 January 2021 (UTC)

> That's why I decided to drill out the skins, because the task cannot be solved with the Mediawiki hooks.

I'm not sure I completely understand the problem here, but I'm still fairly confident you can achieve what you are doing with hooks and if it's not we should update those hooks to make it possible.

> I would like to avoid precisely this annoying workload.

HTML should be cached for each time it's generated or were you talking about something other than performance here? You can use internal caching methods if what you are doing here is very intensive but it doesn't seem that way.

> The advertising blocks must also be positioned appropriately in the sidebar in the sidebar. But this is precisely the purpose of the AD1 and AD2 markers.

And that's fine. Putting AD1 and AD2 in MediaWiki:Sidebar will create 2 elements with id's #p-AD1 and #p-AD2. These will have headings translateable at `MediaWiki:aD1` and `MediaWiki:aD2`, but can also be replaced with the SidebarBeforeOutput. Using Php array methods you can retain the same positioning with a custom heading by doing something like this...

e.g.

$wgHooks['SidebarBeforeOutput'][] = function ( $skin, &$bar ) {
  $newbar = [];
  foreach( $bar as $key => $menu ) {
    if ( $key === 'AD1' ) { 
       $newbar[ 'My custom label or message key' ] = $menu;
    } else {
       $newbar[$key] = $menu;
    }
  }
  $bar = $newbar;
};

If the above doesn't help can you provide a bug report-style account of what you are trying to do here?

e.g.

// Do this...

// Run this code

// Expected result..

// Actual result..

$wgHooks['SidebarBeforeOutput'][] = function ( $skin, &$bar ) {
  $newbar = [];
  foreach( $bar as $key => $menu ) {
    if ( $key === 'AD1' ) { 
       $newbar[ 'My custom label or message key' ] = $menu;
    } else {
       $newbar[$key] = $menu;
    }
  }
  $bar = $newbar;
};

is not working because of a serious problem.

$wgHooks['SidebarBeforeOutput'][] = function ( $skin, &$bar ) {
  $newbar = [];
  foreach( $bar as $key => $menu ) {
    if ( $key === 'AD1' ) { 
       $newbar[ 'advertising' ] = $menu; // <== first set
    } else if ( $key === 'AD2' ) { 
       $newbar[ 'advertising' ] = $menu; // <== overriding first set
    } else {
       $newbar[$key] = $menu;
    }
  }
  $bar = $newbar;
};

You see the issue? With two ad blocks one will override the other. :-(

I did another try with array_splice:

public static function onSkinTemplateOutputPageBeforeExec(
		SkinTemplate &$skin,
		QuickTemplate &$tpl
	) {
		global $wgSidebarAd1Code, $wgSidebarAd1Style, $wgSidebarAd1Type;
		global $wgSidebarAd2Code, $wgSidebarAd2Style, $wgSidebarAd2Type;

		$_key1 = empty( $wgSidebarAd1Type ) ? 'advertising' : $wgSidebarAd1Type;
		$_key2 = empty( $wgSidebarAd2Type ) ? 'advertising' : $wgSidebarAd2Type;

		// Transfer keys 'AD1' and 'AD2' to labels
		$_modified = false;
		$offset = 0;
		$sidebar_new = $tpl->data['sidebar'];

		foreach ( $tpl->data['sidebar'] as $key => $value ) {
			switch ( $key ) {
				case 'AD1' :
					if ( empty( $wgSidebarAd1Code ) ) {
						// Deactivate marker 'AD1' if $wgSidebarAd1Code is not defined
						$sidebar_new['AD1'] = false;
					} else {
						// Replace array with the key 'AD1' with key $wgSidebarAd1Type
						array_splice( $sidebar_new, $offset, 1, [ $_key1 => $wgSidebarAd1Code ] );
					}
					$_modified = true;
				break;
				case 'AD2' :
					if ( empty( $wgSidebarAd2Code ) ) {
						// Deactivate marker 'AD1' if $wgSidebarAd1Code is not defined
						$sidebar_new['AD2'] = false;
					} else {
						// Replace array with the key 'AD2' with key $wgSidebarAd2Type
						array_splice( $sidebar_new, $offset, 1, [ $_key2 => $wgSidebarAd2Code ] );
					}
					$_modified = true;
				break;
			}
			++$offset;
		}
		if ( $_modified ) {
			$tpl->set( 'sidebar', $sidebar_new );
		}
	}

> You see the issue? With two ad blocks one will override the other. :-(

You'll need two unique message keys that translate to the heading. Use advertising-1 and advertising-2 and define those messages in i18n/en.json

Appending ?uselang=qqx to url will show you message keys for the page.

That's dirty and by doubling the same entries an increase of the overhead, but I had already thought of that... ;-)

Why is that dirty? And what overhead are you exactly referring to here? I don't see any problem with having 2 messages using the same text. I've seen this in other extensions. The context is different. See https://github.com/wikimedia/mediawiki/blob/master/languages/i18n/en.json#L148 for example.

The benefit of turning these into translatable messages is that you give the site owner control over those headings - I imagine some people may want to blank them for example and not have a heading.

Also please consider somebody reading with a screen reader. Two portals with the same heading is going to be confusing to those users, so another use case might be translating those to "advertisement 1" and "advertisement 2".

If you want to know, why I call it dirty, have a look at the css files: https://github.com/WikiMANNia/MediaWiki-Extension-WimaAdvertising/blob/master/resources/css/Vector.css It's ugly! --WikiForMen (talk) 01:58, 5 January 2021 (UTC)

Nice! Seems easier to maintain than forking the entire skin, though? :) Using LESS might make that a bit easier to maintain as you'd be able to nest all the rules.

e.g.

#p-wimaadvertising-advertising,

#p-wimaadvertising-advertising2

....

#p-wimaadvertising-hint2 {

.body {

   background-color: #ffffff;

   margin-left: -.7em;

   margin-top: .3em;

   padding: 0 0 .1em 0;

   width: auto;

}

}

I'm not that IN with css and thanks for the help and suggested solutions. :-) --WikiForMen (talk) 01:20, 6 January 2021 (UTC)

It would be less "dirty" if it was considered that #2 is only used if both are advertisements or event notes ... But at least it works now. Thanks for the help. May it be helpful for someone. :-) --WikiForMen (talk) 00:13, 3 January 2021 (UTC)

Hi! I'm writing a user script that adds new links to a page, and would like to enable Page Previews handlers for those links. Per this change, it looks like the wikipage.content hook won't work, and I've been looking through the code and can't see any other way to do this. Would that be correct? (And sorry if this is the wrong venue - I wasn't sure opening a task on the Page-Previews phab workboard was a good idea.)

The delegate event handler we use means any link no matter when it is added will trigger a page preview so no hooks are needed here.

The link to be considered valid however must have a link and title attribute and an associated page preview associated with the URL. This code for example will trigger a page preview:

$('<a title="Hello" href="/wiki/Hello">hello</a>').prependTo('#mw-content-text')

Thank you! I tried it, but I'm on a Special-namespace page. Will it only work in mainspace?

It displays on all special pages except those in this list: https://github.com/wikimedia/mediawiki-extensions-Popups/blob/master/extension.json#L90