User talk:Jdlrobson

Jump to: navigation, search

About this board

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

Using ResourceLoader's target option outside of MobileFrontend

9
FreedomFighterSparrow (talkcontribs)

Hi Jon,

A not-so quick question for you:

I use custom responsive skin on my wiki, but recently have started a move to separate the mobile site from the desktop one, in order to improve performance. However, I have no wish to use MobileFrontend, as it is inextricably tied to Minerva. What I did instead was take Extension:MobileDetect and improve upon it, mainly by taking parts out of MobileFrontend.

My main problem at this point is with the ResourceLoader target; I want to use that functionality to prevent some modules from loading in mobile. Unfortunately, the target definition for each module is in core, even though MobileFrontend is a separate extension - therefore certain modules that I need, such as mediawiki.legacy.shared, are not defined for mobile, simply because Minerva doesn't need them. While I can redefine every module manually for mobile, this will be very error prone; therfore, I tried doing so automatically using a whitelist and parsing both $wgResourceModules and Resources.php (because core modules aren't in $wgResourceModules).

What I do is allow 2 ways to define whitelisted mobile modules:

  1. Using the global $wgMobileDetectModuleWhitelist
  2. By a new hook, MobileDetectWhitelistModules, where you can add the name of a module(s).

This is my fork of MobileDetect, and this is a comparison showing only the whitelist changes.

Unfortunately, this just doesn't work... Maybe because I'm doing all the work in onBeforePageDisplay, and it's just too late to register and load my modules? Any ideas how to fix that? Or maybe just tell me if I'm just going down the wrong path?

Thanks,

Dror.

P.S. I did take a look at [[ResourceLoader/Writing a MobileFrontend friendly ResourceLoader module]]. It looks like maybe your are adding modules in SkinTemplateOutputPageBeforeExec?

Jdlrobson (talkcontribs)

Minerva is not inextricably tied to MobileFrontend :) The config variable MFDefaultSkinClass is designed to allow you to choose another skin as the Mobile skin.

e.g. wgMFDefaultSkinClass = "Vector"

Jdlrobson (talkcontribs)

Once you are doing the above only 'mobile' target modules will be loaded by that skin... which I think is the behaviour you want?

FreedomFighterSparrow (talkcontribs)

Hi Jon,

I'll actually give wgMFDefaultSkinClass a go, though I fear MobileFrontend is doing way too much for what I need.

About the mobile target: the problem is that some modules, both in core (mediawiki.legacy.shared) and in extensions (CategoryTree) are not marked for mobile, because MobileFrontend/Minerva doesn't need them; however, my skin does need them. I'm trying to allow for a simple way to mark those as 'allowed on mobile', but for some reason I'm completely failing...

(Thank you for replying!)

Jdlrobson (talkcontribs)

@FreedomFighterSparrow I think the only way to circumvent this is to update the definitions in core unfortunately. I'm not sure if it's possible to do that in a hook. If possible I'd suggest migrating away from those while it's impacting you.

I don't know much about the CategoryTree extension but I suspect there is little harm in updating the module definitions there.

mediawiki.legacy.shared will be a little trickier, but it's quite a simple module and I think it would probably be easier to pick out the bits you need from it.

Jdlrobson (talkcontribs)

And on subject of MobileFrontend - we recognise this and are trying to cut it down. Pulling out the Minerva skin would reduce most of it - https://www.mediawiki.org/wiki/Skin:MinervaNeue - I'm interested to hear how you get on with MFDefaultSkinClass!

FreedomFighterSparrow (talkcontribs)

Hi Jon, thanks for looking at this. I hate patching core - it just takes a one-time mistake when upgrading to have "unexplainable" regressions... but I'd just might do it, as I've exhausted most of my other options.

Regarding the split of MobileFrontend, I know you're working towards this and I appreciate this - we actually discussed this way back in Lyon ;-)

What's left in MF after removing Minerva?

Jdlrobson (talkcontribs)

MobileFrontend without Minerva would essentially be an extension that allows you to serve a different skin to mobile users on a different mobile domain if wanted.

There are other things it would provide under the hood:

  • mobile formatted content to support section collapsing, lazy loaded images, the ability to remove content from the mobile view, main page special casing + API to provide it.
  • various mobile optimised pages where changes to desktop have proved tricky/impossible e.g. the history, diff, watchlist pages. [note: I'd love to see these in core, but it's just not possible without HTML markup changes which will result in visible styling changes]
  • Ability to serve manifests to skins.
  • Possibly some JS friendly modules that can be used by skins that are not yet covered by core /oojs ui.
FreedomFighterSparrow (talkcontribs)

Hmmm, so basically a souped-up version of MobileDetect as I envision it. Cool :-)

Reply to "Using ResourceLoader's target option outside of MobileFrontend"

Collapsing code works on desktop MW, but (glaringly) NOT with MobileFrontend

4
Slgrandson (talkcontribs)

Good day, Mr. Jdlrobson. Yesterday, after hours of experimentation, I implemented an alternative to MW's standard Navboxes in the form of this Collapse Widget on my Referata wiki, The Dixwell Dossier. (Inspired by this StackExchange thread from July 2013, and this answer by "DavidLin".)

I'm already aware that MobileFrontend can't support Navbox because, as I've heard, it's too clunky and unwieldy for mobile. As such, I came up with an alternative that's supposed to be backwards-compatible by design. On the regular MW, the prototype code's "Expand/Collapse" function works with no problems (as is currently demonstrated in the Sandbox on that site), but when seen on the mobile view... Nothing happens. "Expand" is unchanged and unclickable, and the items that are supposed to be hidden below are exposed to view.

I wonder if you can come up with a mobile-compliant/MW-compliant JavaScript fix, or have I run into a bug on MobileFrontend's part?

Jdlrobson (talkcontribs)

Hi @Slgrandson it looks like the script tag is being rendered above the navbox. The code is running but it runs before the navbox is rendered.

You'll need to wrap this to make sure it only executes when ready. $( function() { // code } )

I'm not sure why it is working in desktop mode - is it possible there is a gadget or another extension making it work?

Slgrandson (talkcontribs)

Thanks to your patch, looks like it's now working on both sides; see for yourself. Thanks a dozen!

Don't think gadgets or extensions were involved before I gave it another go.

Jdlrobson (talkcontribs)

Awesome!:)

Reply to "Collapsing code works on desktop MW, but (glaringly) NOT with MobileFrontend"

English Wikisource grappling with CSS issues, planning for Wikimania

2
Billinghurst (talkcontribs)

Hi Jon. The English Wikisource community is grappling with our perennial issues of replicating works with sidenotes. Our expertise in CSS is not widespread, and it is opportune for us to flag the issue for Wikimania 2016 in the hope of the desktop/mobile and export experts. Some assistance / overview from the experts and the decision makers on skins would be helpful to guide us getting the right information/phabricaot/... in place would be much appreciated. While this is specifically an enWS discussion, it will be a broader discussion as an issue for the WS sites. Thanks if you can help.

Jdlrobson (talkcontribs)

Hi @Billinghurst apologies for getting back to you so late - I'm not sure how I missed this message. Is there a specific question/issue I can help you with? I'm not too familiar with what sidenotes are in the Wikisource context but am happy to help in anyway I can. Are there existing pages that are broken on mobile?

Reply to "English Wikisource grappling with CSS issues, planning for Wikimania"
Nirmos (talkcontribs)

Hi! At Swedish Wikipedia (sv.wikipedia) we have a gadget whose JavaScript looks like this:

$( function() {
	'use strict';
	$( '.mw-ui-icon-random' ).after( '<a href="https://tools.wmflabs.org/slumpartikel?mobile=1" title="Exkludera robotskapade sidor" id="ExkluderaRobotskapadeSidor">(−bot)</a>' );
} );

and whose gadget definition looks like this: *ExkluderaRobotskapadeSidorMobil[default|ResourceLoader|targets=mobile]|ExkluderaRobotskapadeSidorMobil.js|ExkluderaRobotskapadeSidorMobil.css

There seems to be some kind of race condition going on here, because it sometimes works and sometimes it doesn't. Can you tell just by looking at this what's wrong? If not, could you point me to a page where the modules that can be loaded as dependencies are described, so that I can try on my own?

Jdlrobson (talkcontribs)

Hi! I'm not surprised this isn't working. The menu is rendered via JavaScript so you'd be better of altering MW.config.get( ' wgMFMenuData' ) to control the rendering of the menu.

There's a longstanding bug around configuring the main menu which would make this a lot easier for you. Sadly it's not a top priority right now but here it is: https://phabricator.wikimedia.org/T65459

Reply to "mobile gadget race condition"
This comment was hidden by The Quixotic Potato (history)
Reply to "Wtf?"
There are no older topics