Wikitech-l February 2020

wikitech-l@lists.wikimedia.org

54 participants
65 discussions

`Parser::getTitle` may return `null`, even though it is not allowed to
by Robert Vogel 14 Feb '20

14 Feb '20

Hello! In version 1.34 creating a `Parser` object without explicitly setting the `mTitle` value was deprecated. But as it is just a deprecation yet, there are still cases where `mTitle` can be `null` (it seems like this is even the case when calling the proper service with `MediaWikiServices::getInstance()->getParser()`). Unfortunately the `Parser::getTitle` method got changed, in a way that it _must_ return an instance of `Title`. No `null` allowed. This leads to a `TypeError`. I have found two Phabricator tasks, each with a proper patch for this: - https://phabricator.wikimedia.org/T228881 / https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/533559/ - https://phabricator.wikimedia.org/T245129 / https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/571940/ It looks like a very small change. I'd very much appreciate if somebody could review and merge one of these. -- Robert Vogel

1 0

Scrum of scrums/2020-02-12
by Željko Filipin 13 Feb '20

13 Feb '20

Hi, for HTML version see https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-02-12 Željko -- = 2020-02-12 = == Callouts == * SRE for Release engineering on Looking for scap reviewers for syslog support [[gerrit:563468]] * Parsing - Project retrospective of how Parsoid was ported to PHP: [[phab:phame/post/view/189/parsoid_in_php_or_there_and_back_again]] == Product == === Community Tech === * Updates: ** We anticipate new database table will be created this week (Watchlist Expiry). === Anti-Harassment Tools === * Blocking: ** Release Engineering - [Regression 1.35.0-wmf.19] i/p/IndexPager.php:* PHP Warning: implode(): Invalid arguments passed [[phab:T244937]]. This is part of adding more functionality (multicolumn sort). === Editing === * Updates: ** Deploying Reply v1.0 for talk pages next week ** For Reply v2.0, refining the approach to autcomplete @-mentions ([[phab:T232601]]) and developing a technical approach to editing comments ([[phab:T242562]]) === Growth === * Updates: ** Newcomer tasks 1.1 (topic matching): building the infrastructe to upgrade the topics to use the ORES models instead of our initial "morelike" algorithm. Big thanks to the Search and Scoring teams for their ongoing support. ** Newcomer tasks 1.2 (guidance): We are also beginning engineering work on this part of the newcomer tasks workflow ([[phab:T244431]]) === iOS native app === * Updates: ** Continuing development on 6.6 release (mobile-html integration) [[phab:project/view/4273]] === Android native app === * Updates: ** Finishing up conversion logic from old caching to new offline database scheme. (relating to mobile-html migration) ** Iterating on design refinements of Image Tagging interface. === Web === * Updates: ** Summary: continuing desktop improvements (DIP). Digging into logo handling, conventions, feature management, and legacy version preferences. ** [[Reading/Web/Desktop_Improvements|Desktop Improvements Project (Vector / DIP)]]: *** [[phab:T232140|<nowiki>Separate out logo handling into square image logos and long text/wordmark banner logos</nowiki>]] *** [[phab:T239269|<nowiki>[SPIKE 16hrs] Add coding convention for new commits to Vector</nowiki>]] *** [[phab:T242381|<nowiki>Add a Vector skin version preference</nowiki>]] *** [[phab:T236711|<nowiki>It should be possible to customise the implementation of mw.util.addPortletLink function on a skin basis</nowiki>]] ** Mobile website (MinervaNeue / MobileFrontend): *** [[phab:T244444|<nowiki>Replace all possible, non-product specific icons in MobileFrontend/MinervaNeue with WikimediaUI/OOUI ones</nowiki>]] *** [[phab:T244436|<nowiki>[Regression, Production] user contributions icon missing on AMC mode</nowiki>]] *** [[phab:T212465|<nowiki>[EPIC] None of our View's should exhibit 2 levels of inheritance</nowiki>]] *** [[phab:T32405|<nowiki>[EPIC] MobileFrontend extension should stop special-casing main page</nowiki>]] *** [[phab:T244106|<nowiki>Setup storybook from Minerva</nowiki>]] *** [[phab:T214641|<nowiki>[Technical] The LoadingOverlay and src/mobile.startup/rlModuleLoader.js pattern should be removed - it results in overlay flashes during switches</nowiki>]] *** [[phab:T139221|<nowiki>Better expose table of contents to assistive technology by using role=navigation</nowiki>]] === Product Infrastructure === * Updates: ** Push notifications technical planning in process === Structured Data === * Blocking: ** Search Platform: Data dumps for SDC: [[phab:T221917]] - honestly, we're not blocking this anymore * Updates: ** no update from last week - finishing off SDC (input types, constraints, novalue/somevalue) === Parsing === * Updates: ** Project retrospective of how Parsoid was ported to PHP: [[phab:phame/post/view/189/parsoid_in_php_or_there_and_back_again]] ** Working on a parsoid extension api using Parsoid's Cite implementation as a guinea pig. === UI Standardization === * Updates: ** OOUI v0.36.5 on the way, all icon related changes, added MF/MN icons ** Started OpenDesignKit integration discussions into design.wikimedia.org ** WikiEditor 2010 toolbar design aligned to standard components (thanks, Ed Sanders) == Technology == === Analytics === * Blocking: ** Release Engineering: The manual analytics-refinery-release and analytics-refinery-update-jars Jenkins jobs need to be ported from bare-metal Jessie into Docker (or just dropped) [[phab:T210271]] === Fundraising Tech === * Updates: ** Re-evaluating failure modes on paymentswiki - when we get networking errors making API calls donors often donate twice due to unclear errors. - [[phab:T243873]] ** More work towards recurring donations with backup card processor - [[phab:T243334]], ** Updating translated thank you letters and adding a button in the CiviCRM UI to send the multilingual versions - [[phab:T243098]] ** Better aligning our use of a few CiviCRM concepts with core - [[phab:T244326]] ** Upstreaming or discarding more local CiviCRM performance hacks - [[phab:T194313]], [[phab:T217600]] ** More work to finish CentralNotice sub-national geotargeting - [[phab:T243011]] === Core Platform === * Blocking: ** German Technical Wishlist (Release Engineering/SRE/Core Platform (?)) - Issues with logging into beta wikipedia cause failures of daily selenium tests of TwoColEditConflct extension: [[phab:T243123]] ** Search Platform: MW Job consumers sometimes pause for several minutes [[phab:T224425]] * Updates: ** API gateway plan in technical planning stages [[Core_Platform_Team/Initiatives/API_Gateway]] ** Search enhancement epic starting [[Core_Platform_Team/Initiatives/Core_REST_API_in_MediaWiki#Epic_1.5:_Search_enhancement]] === Engineering Productivity === ==== Quality and Test Engineering ==== * Updates: ** Started with series of internal testing strategy presentations. First in series - CheckUser. ==== Release Engineering ==== * Blocked by: ** Analytics: The manual analytics-refinery-release and analytics-refinery-update-jars Jenkins jobs need to be ported from bare-metal Jessie into Docker (or just dropped) [[phab:T210271]] ** Anti-Harassment Tools - [Regression 1.35.0-wmf.19] i/p/IndexPager.php:* PHP Warning: implode(): Invalid arguments passed [[phab:T244937]] * Blocking: ** SRE on Looking for scap reviewers for syslog support [[gerrit:563468]] ** German Technical Wishlist (Release Engineering/SRE (?)) - Issues with logging into beta wikipedia cause failures of daily selenium tests of TwoColEditConflct extension: [[phab:T243123]] * Updates: ** Train Health *** Last week: 1.35.0-wmf.18 - [[phab:T233866]] *** This week: 1.35.0-wmf.19 - [[phab:T233867]] **** Anti-Harassment Tools - [Regression 1.35.0-wmf.19] i/p/IndexPager.php:* PHP Warning: implode(): Invalid arguments passed [[phab:T244937]] *** Next week: 1.35.0-wmf.20 - [[phab:T233868]] === Scoring Platform === * Updates: ** Rolled back ORES deploy for memory issues. New deploy out on Monday. [[phab:T242705]] *** Memory opened up but issues still persist when doing logrotate. ** Coloring OOJSui icons using the WMF standard color palette. Is there a good way to do this? === Search Platform === * Blocked by: ** Structured Data: Data dumps for SDC: [[phab:T221917]] ** Core: MW Job consumers sometimes pause for several minutes [[phab:T224425]] * Updates: ** Load ORES articletopic data into ElasticSearch via the weekly bulk update [[phab:T240556]] === Security === * Updates: ** [[phab:T242124]] - EventStreamConfig Security Review = done ** [[phab:T240010]] - Wikipedia Previews = stalled on one or two questions for requesters ** [[phab:T242134]] - Talk Pages/Discussion Tools review = started ** [[phab:T243007]] - KaiOS review = waiting for code freeze or commit specification === Site Reliability Engineering === * Blocked by: ** Release engineering on Looking for scap reviewers for syslog support [[gerrit:563468]] * Blocking: ** German Technical Wishlist (Release Engineering/SRE/Core Platform (?)) - Issues with logging into beta wikipedia cause failures of daily selenium tests of TwoColEditConflct extension: [[phab:T243123]] == Wikimedia DE == === German Technical Wishlist === * Blocked by: ** Release Engineering/SRE/Core Platform (?): Issues with logging into beta wikipedia cause failures of daily selenium tests of TwoColEditConflct extension: [[phab:T243123]]

2 1

Reminder: Wikimedia Café online meeting for February 2020 with focus on the 2030 strategy
by Pine W 13 Feb '20

13 Feb '20

Hello colleagues, This is a reminder that this month's Wikimedia Café will start approximately 48 hours from now. -- Hello colleagues, The February 2020 Wikimedia Café meetup will occur on 15 February 2020 at 8:30 AM PST / 11:30 AM EST / 4:30 PM UTC / 10 PM IST. The date is earlier than usual in the month due to scheduling constraints. This month's meetup will focus on the 2030 strategy recommendations, and will be divided into two discussions of one hour each. More information regarding the agenda and links to strategy documents are available at https://meta.wikimedia.org/wiki/Wikimedia_Café. As usual, the meeting style for the Café will emphasize discussion rather than presentation. People are welcome to participate as listeners only if they prefer. Please see the page on Meta for more information about the Café. Please watch the page for any updates, particularly to the schedule or the agenda. Signing up for the meeting is optional, but is helpful to the organizers so that we can estimate how many people will attend. Signing up for the meeting also informs us who we should notify individually if there are significant changes. If there are any problems with connecting to the meeting or if you have any questions or comments then please write on the Meta talk page. Pine ( https://meta.wikimedia.org/wiki/User:Pine )

1 0

How to invalidate a ResourceLoader URL that depends on user-generated content?
by Máté Szabó 13 Feb '20

13 Feb '20

Hi all, I am working on a custom ResourceLoader module whose style contents are compiled from Sass stylesheets. These Sass stylesheets take as input user-defined theme variables that affect the output. I am looking for a way to invalidate ResourceLoader URLs that include such style modules, when these variables change as a result of an user action—primarily so that the user can see their own changes. ResourceLoader will cache such style URLs for 5 minutes on the CDN and in the user’s browser cache, so by default the user would have to wait until their cached copy of styles expire before they would receive the updated version. Accordingly, I have tried to explore if following the document steps to empty one’s browser cache[1] after making changes would cause the browser to fetch the updated resource from the backend. Unfortunately, both Chrome and Firefox appear to send a “Cache-Control: no-cache” request header for the style URL if the page is hard refreshed, which seems to cause most CDNs (including WMF’s) to act as the source of truth and serve the asset from cache if it is already there, without triggering a backend fetch or conditional revalidation. In the case of a simple refresh, Chromium and derivatives will not trigger a conditional revalidation of resources including on a page since 2017,[2] so they just continue to use the asset that was already in the browser’s cache. Thus, the standard instructions for emptying one’s cache do not seem to be sufficient to allow the user to see the effect of their styling changes. Given the above, the only option I see that would allow the user to see the updated styles after modifying input variables would be to append a version hash to the style URL included in the page HTML—something which ResourceLoader does not currently do. Do you know of a better approach to this problem? Are there any examples in MediaWiki core or extensions that accomplish something similar? I have consulted the code for ResourceLoaderSiteStylesModule, but it does not seem to have any specific invalidation behaviour, nor does it use a version hash in style URLs in the page HTML, so it seems that any updates to it take 5 minutes to propagate. Thanks in advance! — [1] https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache [2] https://bugs.chromium.org/p/chromium/issues/detail?id=505048 Cheers, Máté Szabó SOFTWARE ENGINEER +36 30 947 5903 Fandom Poland sp. z o.o. z siedzibą w Poznaniu, ul. Abp. A. Baraniaka 6 Sąd Rejonowy Poznań – Nowe Miasto i Wilda w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000254365 NIP: 5252358778 Kapitał zakładowy: 50.000,00 złotych

3 3

Phabricator database master restart - Thursday 13th 06:00AM UTC
by Manuel Arostegui 13 Feb '20

13 Feb '20

Hello, Thursday 13th at 06:00 AM UTC we'll be restarting phabricator database master for https://phabricator.wikimedia.org/T239791 and to get it upgraded as well (https://phabricator.wikimedia.org/T244566) Phabricator will be on read-only mode for around 1 minute. Sorry for the inconvenience, Manuel.

1 2

TechCom Radar 2020-02-12
by Alexandra Paskulin 13 Feb '20

13 Feb '20

Hi all, Here are the minutes from this week's TechCom meeting: * Discussed: RFC Re-evaluate librsvg as SVG renderer on Wikimedia wikis <https://phabricator.wikimedia.org/T40010> * Discussed: Config on the RequestContext may not be the same as the main config <https://phabricator.wikimedia.org/T240000> * Opened: Improve file attribution for “Called deprecation function” logs <https://phabricator.wikimedia.org/T245075> * RFC review meeting scheduled for next week: Adopt a modern JavaScript framework for use with MediaWiki <https://phabricator.wikimedia.org/T241180> 2020-02-19 22:00 UTC (14:00 PT, 23:00 CET) on Freenode in #wikimedia-office You can also find our meeting minutes at <https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes> See also the TechCom RFC board <https://phabricator.wikimedia.org/tag/mediawiki-rfcs/> If you prefer you can subscribe to our newsletter here <https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar> Best, - Alex -- Alex Paskulin Technical Writer Wikimedia Foundation

1 0

Thank you... twuensday ?
by Derk-Jan Hartman 12 Feb '20

12 Feb '20

Well it's not Tuesday, but better late than never. I'd like to think volutneer DannyS712 [1] who has frankly done a humongous amount of work over the last couple of weeks. DannyS712 has been going through many technical-debt and code cleanup tasks, splitting them and tackling them each one extension at a time, all while working at the same time on their Global watchlist userscript [2] and many other technical tasks on en.wp at the same time. Absolutely impressive. I also want to join [3] VolkerE in thanking MattFitzpatrick, PerfektesChaos and heydonworks for highlighting and persisting on indicating a simple accessibility improvement [4] of the Table of Contents for screenreader users, that will soon be deployed. [1] https://phabricator.wikimedia.org/p/DannyS712 [2] https://meta.wikimedia.org/wiki/User:DannyS712/Global_watchlist.js [3] https://twitter.com/Volker_E/status/1227261008059592704 [4] T139221: Make generated table of contents a navigation region <https://phabricator.wikimedia.org/T139221>

1 0

Invitation to apply to Outreachy and Google Summer of Code program with Wikimedia!
by Srishti Sethi 10 Feb '20

10 Feb '20

*(feel free to forward the message as is to your friends, family members & colleagues)* Hello folks, We would like to invite you to apply to the Outreachy and Google Summer of Code program with the Wikimedia Foundation (a non-profit organization behind Wikipedia)! *About the Outreachy program* Wikimedia will be mentoring ~7 projects in the Outreachy program in the May to August 2020 round. The initial applications are due February 25th at 4 pm UTC. Apply today: https://www.outreachy.org/apply/ Outreachy offers three-month internships to work remotely in Free and Open Source Software (FOSS) projects with experienced mentors. The internships may include programming, user experience, documentation, illustration and graphic design, or data science. Outreachy internships run twice a year – from May to August and December to March. Interns are paid a stipend of $5,500 USD for the three months of work. They also have a $500 USD stipend to travel to conferences and events. Interns often find employment after their internship with Outreachy sponsors or in jobs that use the skills they learned during their internship. Outreachy is open to both students and non-students. Outreachy expressly invites the following people to apply: * Women (both cis and trans), trans men, and genderqueer people. * Anyone who faces under-representation, systematic bias, or discrimination in the technology industry in their country or residence is invited to apply. * Residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latin@, Native American/American Indian, Alaska Native, Native Hawaiian, or Pacific Islander. *About the Google Summer of Code program* Wikimedia is planning to mentor 8-10 projects in 2020’s Google Summer of Code (GSoC) program. Beginning February 20th, pending Wikimedia’s acceptance as a mentoring organization, applicants can begin discussing ideas with the mentors! The student application will be due on March 31st 18:00 UTC: https://summerofcode.withgoogle.com/ Google Summer of Code now in its 16th year, is Google's summer program for university students who want to get involved in open source software. Over 15,960 students from 109 countries have already participated. Google Summer of Code is a unique program that pairs students with mentors who introduce them to the open-source community and provide guidance while they work on real-world open-source projects during their summer break from university. Projects cover a wide range of fields including: Cloud, Operating Systems, Graphics, Medicine, Programming Languages, Robotics, Science, Security and many more. It's a highly competitive program (and this year is expected to be even bigger than last year), so don't wait until the last minute to prepare! *About the Wikimedia Foundation* The Wikimedia Foundation <https://wikimediafoundation.org/> is the nonprofit organization that hosts and operates Wikipedia and the other Wikimedia free knowledge projects <https://wikimediafoundation.org/our-work/wikimedia-projects/>. Our vision is a world in which every single human can freely share in the sum of all knowledge. We believe that everyone has the potential to contribute something to our shared knowledge, and that everyone should be able to access that knowledge, free of interference. We host the Wikimedia projects, build software experiences for reading, contributing, and sharing Wikimedia content, support the volunteer communities and partners who make Wikimedia possible, and advocate for policies that enable Wikimedia and free knowledge to thrive. *Resources* * Browse through the participants’ guides, to learn more about the application process steps: https://www.mediawiki.org/wiki/Outreachy/Participants https://www.mediawiki.org/wiki/Google_Summer_of_Code/Participants * All the projects will be showcased here: https://www.outreachy.org/communities/cfp/wikimedia/ https://www.mediawiki.org/wiki/Google_Summer_of_Code/2020 We hope you will help us spread the word about Wikimedia’s participation in these programs: https://twitter.com/mediawiki/status/1224790357361098752 (by retweeting the post in the link or by sharing this email) Looking forward to your participation! Cheers, Srishti & Pavithra (Wikimedia organization administrators for GSoC & Outreachy) *Srishti Sethi* Developer Advocate Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

Inform about myself
by yasas ekanayaka 10 Feb '20

10 Feb '20

Hey everyone! I'm Yasas Ekanayaka From Sri Lanka. I'm a University student. I'm following a degree in computer science. I'm good at C/C++, Python, HTML, JavaScript, AngularJS, PHP languages and frameworks. I like to contribute your open source projects. Thank you

2 1

Re: [Wikitech-l] Storing some values in the DB
by crawlspaces 08 Feb '20

08 Feb '20

What about log_search, which is intended for permanent storage of data; could your extension generate a log event and then use that log_id as the ls_log_id? https://www.mediawiki.org/wiki/Manual:Log_search_table Maybe there could be a new type of log_type/log_action introduced, e.g. storedata/myextension, if your extension is called MyExtension. Each extension that stores data in this way would have its own log_action, and would generate one or more log events as needed to reserve a log_id(s) for data storage.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l February 2020