Hello Jon. Following our IRC conversation, I have declined the request to install Netlify on Wikimedia's GitHub organisation for MobileFrontend, MinervaNeue and PopUps. If however Netlify or any other GitHub App is needed over there again, please set it up and, in case you cannot approve it, please let me know to have them approved (I might need to check with RelEng though). Best regards.
User talk:Jdlrobson
Hi. I hope that you can point me to where the configuration exists ...
On a page like https://en.m.wikisource.org/w/index.php?title=The_Works_of_Lord_Byron_(ed._Coleridge,_Prothero)/Poetry/Volume_1 the mobile skin is left aligning images that have been typeset to be centred to align with the remainder of the text on the page, see standard view, s:The Works of Lord Byron (ed. Coleridge, Prothero)/Poetry/Volume 1
So in the end we have people using text centering styles rather than image placement formatting to achieve their ends. Is this image positioning forcing something that we can control at a local level? Thanks.
Raised a bug here: https://phabricator.wikimedia.org/T193595 For quicker replies for me, best to add a task to Phabricator. Will see if I can get this fixed.
Ah, I thought that it was a feature that I could control, not a bug. Thanks.
Hello! This is a final reminder that the Wikimedia Foundation survey will close on 23 April, 2018 (07:00 UTC). The survey is available in various languages and will take between 20 and 40 minutes. Take the survey now.
If you already took the survey - thank you! We will not bother you again. We have designed the survey to make it impossible to identify which users have taken the survey, so we have to send reminders to everyone. To opt-out of future surveys, send an email through EmailUser feature to WMF Surveys. You can also send any questions you have to this user email. Learn more about this survey on the project page. This survey is hosted by a third-party service and governed by this Wikimedia Foundation privacy statement.
WMF Surveys, 00:43, 20 April 2018 (UTC)
Every response for this survey can help the Wikimedia Foundation improve your experience on the Wikimedia projects. So far, we have heard from just 29% of Wikimedia contributors. The survey is available in various languages and will take between 20 and 40 minutes to be completed. Take the survey now.
If you have already taken the survey, we are sorry you've received this reminder. We have design the survey to make it impossible to identify which users have taken the survey, so we have to send reminders to everyone. If you wish to opt-out of the next reminder or any other survey, send an email through EmailUser feature to WMF Surveys. You can also send any questions you have to this user email. Learn more about this survey on the project page. This survey is hosted by a third-party service and governed by this Wikimedia Foundation privacy statement. Thanks!
WMF Surveys, 01:34, 13 April 2018 (UTC)
Hello! The Wikimedia Foundation is asking for your feedback in a survey. We want to know how well we are supporting your work on and off wiki, and how we can change or improve things in the future. The opinions you share will directly affect the current and future work of the Wikimedia Foundation. You have been randomly selected to take this survey as we would like to hear from your Wikimedia community. The survey is available in various languages and will take between 20 and 40 minutes.
You can find more information about this survey on the project page and see how your feedback helps the Wikimedia Foundation support editors like you. This survey is hosted by a third-party service and governed by this privacy statement (in English). Please visit our frequently asked questions page to find more information about this survey. If you need additional help, or if you wish to opt-out of future communications about this survey, send an email through the EmailUser feature to WMF Surveys to remove you from the list.
Thank you!
WMF Surveys, 18:36, 29 March 2018 (UTC)
Hi. I am 1339861mzb at phabricator. I want to ask you who is herald? Because it is like bot i.e very fast. I created a new task at phabricator and found like herald add subscribers simultaneously!
Herald is indeed a bot! :)
Thanks. On what rationale it based when subscribing certain subscribers?
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:
- Using the global $wgMobileDetectModuleWhitelist
- 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?
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"
Once you are doing the above only 'mobile' target modules will be loaded by that skin... which I think is the behaviour you want?
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!)
@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.
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!
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?
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.
Hmmm, so basically a souped-up version of MobileDetect as I envision it. Cool :-)
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?
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?
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.
Awesome!:)
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.
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?
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?
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