- User Since
- Dec 13 2019, 7:37 PM (181 w, 2 d)
- LDAP User
- MediaWiki User
- Polishdeveloper [ Global Accounts ]
Jun 27 2022
Reviewed and merged, @Jdlrobson can you take over?
Mar 8 2021
Mar 2 2021
@Jdlrobson can you add QA steps?
Mar 1 2021
@Yash4357 Your core patch got merged. Are you interested improving the MobileFrontend by using this interface?
Feb 19 2021
I'll look into it today. Sorry to keep you waiting
Feb 10 2021
Feb 2 2021
Feb 1 2021
Pushed the smallest/simplest change to get this task done. Menu handling still requires some small refactoring but that can be a part of different task.
Jan 22 2021
Yes, definitely. Happy to help. Thank you for the ping @Jdlrobson .
Sep 23 2020
I see some action in phab, give me this week to push what I have so far.
Aug 17 2020
It looks like there is lots of old/outdated documentation as most of the stuff was migrated to MinervaNeue and MobileFrontend is currently not involved in building Menu for minerva.
https://doc.wikimedia.org/mediawiki-core/master/php/MobileMenuHook_8php.html -> is missing as we do not have interface for that MobileMenu, it's part of Minerva, not core.
Aug 10 2020
data-mw="interface" definitely should stay. And on top of that we should use something else instead of #pt-logout, also I don't see real value in wrapping elements menu elements with additional wrappers, so we would have to search for element that has both classname and data-mw element. Something like .menu a[data-mw=interface][class*=menu__item--logout] should do the job. I'll create a patch.
Aug 5 2020
Ok, so a short summary of my struggles
Aug 4 2020
I'm still going to push the fix for that, but after ~4 months not working on MediaWiki code literally nothing works and the only solution is to drop entire repo and start it from scratch again. I struggled to get my env working again with everything what I had on the weekend but after couple hours I surrended.
Jul 30 2020
let me pick that, it should be simple and straightforward ;)
I vote for 1 - Minerva being compatible with what core/vector provides. Adding support for MenuEntries shouldn't be a problem ( id's are already supported, you can pass those as an attribute when creating a component).
Jul 15 2020
The PDF print service is not aware of any user/user preferences. It prints all articles as anon user. Therefore - when a logged in user asks to print page with some special option, then it's exactly as @Jdlrobson says:
Proton uses puppeteer node library to tell chrome (that is running in headless mode) to do things. What we currently do is that we tell chrome to open a Wikipedia page, and call window.print() and print to PDF. It behaves almost the same way as someone going to Wikipedia on their desktop and clicking "Print" and then pick "PDF" as output. It doesn't use Parsoid output (at least at the time of implementation) as there were differences in styles for mobile pages.
May 15 2020
Great work @phuedx
LGTM, Signing off
May 13 2020
I'm on it, I should sign it off by end of today - so far it looks good but I want to verify couple more things.
May 11 2020
Apr 13 2020
Just to make this topic easier to process - what we want to achieve is easily accessible "Feature Toggles" that can be used anywhere in the MediaWiki land. For more information please read https://martinfowler.com/articles/feature-toggles.html
I can work on it
Apr 8 2020
Is there anything I can help with to push this RFC forward?
Mar 31 2020
Mar 23 2020
Mar 13 2020
Mar 3 2020
I'm more than happy to join any meetings, explain the idea behind Feature Management and try to answer all questions.
Mar 2 2020
@Jdlrobson - pmiazga was the account I was using earlier, now it's @polishdeveloper :). Also, I'll create another task for other skins plus changes required in mwcore ( adding deprecation for $data property in QuickTemplate ).
Feb 28 2020
@Jdlrobson - yeah, we could add a default value of empty string. The only concern I have is that if someone makes a typo and tries to text( 'unknown' ) it would still work but with empty string - this can cause problems when debugging stuff. Maybe we could do sth like that"
Feb 27 2020
Thank you @MarcoAurelio. Just to verify, am I getting +2 rights for both MWCore and extensions/skins or do I have to submit another ticket and specify the list of skins/extensions I'm working on ?
Feb 26 2020
yes, but I don't think it should go to Backlog, as backlog is mostly for code-related tasks and this one is about permissions/way to access slack.
I would go even further, and I would make:
@Aklapper sorry, but I have no idea on how to tag this task, could you help?
@Tgr yes, so in this idea you would have - the UserMode called ( GrowthCommunityMemeber ).
Then you would have multiple features, that are not available to any mode, only to growthCommunityMemeber. Once User opts into growthCommunityMember (or someone opt's that person) user will get all features available on that mode.
Feb 14 2020
Feb 11 2020
@Jdlrobson why not use hooks? It doesn't introduce tech deb, you define new Hook called sth like PopupsInitialization, and allow other extensions to listen to that hook and returm false. See https://phabricator.wikimedia.org/T236097#5809640
IMHO it's much cleaner approach and it doesn't introduce any tech debt. What more, if there is any other Popups like extension, it will be also able to easily disable PagePreviews so it doesn't conflict.
Feb 10 2020
Feb 8 2020
Feb 7 2020
@phuedx yeah, I agree, the ISet is pretty problematic, I spent some time ago thinking on it, and my idea is that we could define sets of features per context. So for example, the mode could be:
Feb 6 2020
@phuedx, The Feature interface shouldn't define more things, definitely things that shouldn't be there are:
- getGroup() - it is used to group MobileFrontend, Minerva, other features, no idea why we did that, it's used for translations now
- getNameKey() - is using getName() and getGroup() do create a Feature name key for translations, used on MobileOptions to show each feature name, but most probably won't be used in DIP
- getDescriptionKey() - similar to getNameKey(), but this one provides a short description of feature.
@phuedx please check the T244481: Provide basic FeatureManagement in Vector codebase
Feb 4 2020
I'm not sure, pmiazga account has many permissions and I if I remember right I was using the PMiazga (WMF) mediawiki account, it's just easier to grant only contributor permissions to the new account.
Jan 31 2020
Jan 29 2020
@Krinkle I'd like to follow-up on what I wrote earlier. I checked with Readers Web, and we agreed that we currently maintain the Feature Management in MobileFrontend. We're going to do something similar in Vector, therefore we will have to maintain it also in Vector. Therefore there is no difference for us between maintaining it in MobileFrontend/Vector or maintaining it in the MediaWiki Core.
@Jdlrobson can you add QA steps and move it to needs QA?
Jan 24 2020
@Krinkle I don't think there is a roadmap/stewardship in place for this project. We found a need for such solution, I also did a quick research and looks like other teams are facing similar problems as we start to feature flag and A/B test many things. This is an idea to centralize the common requirement we, Readers Web have (maintaining multiple modes) and make it handy for other teams. I can definitely help with maintaining such project in my volunteer time.
Jan 22 2020
Jan 21 2020
@phuedx I already tried to do that and there was lack of agreement on where to put the getEditCountBucket method. Please check T210106: Provide a reusable getEditCountBucket function for analytics purposes, there is a patch that adds this function on the JS side, but we abandoned that work.
Jan 17 2020
The code for PrefUpdate lives in WikimediaEventsHooks::onUserSaveOptions file. To achieve this goal we need to:
- edit the Schema:PrefUpdate wiki page and add edit count bucket
- (SEE NOTE BELOW) edit the WikimediaEventsHooks and bump the schema revision
- edit the $commonData array and add new editCount bucket
Jan 16 2020
On the backend side we could use the Hooks system to allow other extensions to disable PagePreviews. The code would look like sth like that:
Jan 15 2020
RFC is available here T242835: RFC: Standard method for feature-management in skins/extensions - moving to ready for sign off
Jan 13 2020
As a result of this spike we decided to submit an RFC. We would like to implement the Feature Management system in MediaWiki core as it's feels like a core feature that is required by multiple projects/teams.
- MobileFrontend and Minerva uses the bespoke Feature Management system
- Growth team is juggling multiple config flags and Feature Management could help simplify their system
- Vector is another place where we want to enable/disable features in groups, thus Feature Management system looks like a best approach.