Fri, Feb 21
Ok, we have a workaround for T245793 (thanks @Mooeypoo!). New issue: there's a race scenario with Popups to insert the new skin preferences section directly underneath skin choice section. I can't think of a way to handle this scenario in the current architecture except:
Thu, Feb 20
Wed, Feb 19
Estimated asynchronously at an extra-large.
Removing Olga as assignee. I think the carryover was just a clerical error.
Tue, Feb 18
Sat, Feb 15
PR is merged so I hope this task is done.
PR is merged so I hope this task is done.
Fri, Feb 14
@phuedx, I've left a comment for you in code review regarding preference conversion. This still "needs work" but is pending your feedback so I'm moving over to code review and assigning to you temporarily
Thank you, @phuedx!
Thu, Feb 13
Config patch is up. I've submitted a revision of the hooks patch that adds tests for the different branches.
@matmarex, sorry if this doesn't make sense but do you think there's a chance https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/541597/ could be contributing to this issue?
Wed, Feb 12
This needs discussion on approach with @Jdlrobson and the other devs.
Tue, Feb 11
Adding a link to Special:Preferences#mw-prefsection-rendering in PHP. Use JS to trap the user clicking the link and use the MediaWiki API to opt them in/out.
Sun, Feb 9
Fri, Feb 7
@polishdeveloper, looks good! Just reframing the above into concepts to make sure I got it:
Thu, Feb 6
I've added some skin preferences section display logic to Core as hide-if only works for field elements not sections.
Can we generate SVGs as a build product like we do in Popups? This allows for developers to have a development friendly version that is built by automation into the shipped user version.
Wed, Feb 5
Tue, Feb 4
@Tgr, let me know if this doesn't make sense and feel free to edit!
Mon, Feb 3
In my opinion this was the skin's right.
I think it could be valuable to separate the ideas of application entry points and UI appearance-only changes. (I'm not sure if it makes sense in MediaWiki for the latter to include content styling too.)
Wed, Jan 29
Tue, Jan 28
^Neat! It doesn't look like this preference even displays unless the skin preference has been saved!
Jan 24 2020
@AronManning, I think a good place to start would be FeaturesManager.php in MobileFrontend and the contents of the features subdirectory. An example mode implementation would be the AMC UserMode (this class represents advanced mode on mobile--the name is a relic from when it was called Advanced Mobile Contributions) and an example feature would be the standard and advanced menus. More details in T242835.
I think we can use something like https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.less/mediawiki.mixins.less?view=raw (unless you know a better URL). Related discussion in Vector.
@AnneT, eek, I'm not seeing that load either! I do see MenuOptionWidget.
Hey @Jhernandez! Point taken but of course the integration won't be perfect or frictionless initially. As I understand it, FAWG and Web will be iterating on the initial solution well beyond this RFC so there will be opportunity to uncover integration complexities (such as the ones you noted) that would arise from any choice and I'll be bold enough to say that I'm probably more optimistic than you that we'll figure them out :]
Jan 23 2020
I can repro the issue in the Chromium device emulator on Vector per the description:
Hello @AronManning! (Sorry for the slightly redundant reply.)
Hi @AronManning! Per the outcome of T234907, development is already underway in Vector itself. My understanding is that this approach will allow us to minimize development costs. The existing experience (now called "legacy") will be carefully preserved via a user preference (the subject of this task) and feature manager.
Jan 22 2020
I was thinking that the same changes could be made to at least Minerva which it looks like you did. Thank you!
Jan 16 2020
Jan 15 2020
Jan 14 2020
Jan 13 2020
I discussed this task with @pmiazga, mostly about how it relates to T237635, and the configuration changes and the approach proposed. We think this work will be pretty loosely coupled from the feature manager but it would be nice to deliver legacy and v2 "modes" in the initial (Vector) feature manager patches whenever they come (Piotr is hoping for next week). No other concerns regarding approach but Piotr has some ideas about using the BetaFeatures extension, when available, in conjunction with the $wgVectorDefaultSkinVersion config to start more users on v2 that he'll be discussing with @ovasileva but that can be decided independently of this task.
The shield should cover the whole article surface and be translucent (opacity: 0.6)