Wikitech-l December 2016

wikitech-l@lists.wikimedia.org

83 participants
79 discussions

VisualEditor in 1.28 - fails after upgrade from 1.27
by Daniel Barrett 20 Dec '16

20 Dec '16

After updating my wiki from 1.27.1 to 1.28.0, VisualEditor has stopped working. I click the Edit tab, and the page content fades slightly in color as if VisualEditor were about to load. But then the editor tools don't appear, and Chrome displays a dialog box: example.com responded: "http" [OK] [Cancel] There are no PHP errors in the Apache error log, and no errors in the parsoid log file (looks like a normal parsoid access). However, Chrome developer tools show a JavaScript error: BadMethodCallException. If I remove VisualEditor from LocalSettings.php, the error vanishes. The only extension I am running is VisualEditor; otherwise it's a vanilla MediaWiki that requires users to be logged into read (a private wiki). The same LocalSettings.php files works perfectly in MW 1.27.1. Has anything significantly changed in VisualEditor that I need to configure it differently? LocalSettings.php has: # visual editor $wgDefaultUserOptions['visualeditor-enable'] = 1; $wgDefaultUserOptions['visualeditor-enable-experimental'] = 1; $wgVirtualRestConfig['modules']['parsoid'] = array( 'url' => 'http://localhost:8142', 'prefix' => 'example.com' ); $wgSessionsInObjectCache = true; /* Using memcached */ $wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true; The parsoid settings file has: parsoidConfig.setMwApi({ prefix: 'example.com', uri: 'http://dev.example.com/w/api.php' }); parsoidConfig.useSelser = true; Thank you for any insights! DanB

5 14

Goodbye grrrit-wm, hello again wikibugs
by Legoktm 19 Dec '16

19 Dec '16

Hi, grrrit-wm has been subsumed by wikibugs. You'll now see events from Gerrit reported to IRC by wikibugs. The main purpose of this was to unify the pretty similar codebases and infrastructure instead of having to maintain them separately. I also took the opportunity to fix some silly bugs like the "[]" one. I'll be archiving the "grrrit-wm" Phabricator project shortly - you can use the "wikibugs" one to report any issues you notice. -- Legoktm

1 0

Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27
by Daniel Barrett 19 Dec '16

19 Dec '16

Maybe it was this ticket in September? https://phabricator.wikimedia.org/T146686 I’ll try to get a full stack trace later today when I have access to the wiki again. DanB From: Wikitech-l [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Alex Monk Sent: Monday, December 19, 2016 9:38 AM To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> Subject: Re: [Wikitech-l] VisualEditor in 1.28 - fails after upgrade from 1.27 I feel like that sessions error was something we fixed months ago but can't find details right now. Certainly not the first time I've seen it... > > BadMethodCallException from line 845 of <...>/w/includes/session/ > SessionManager.php: > > Sessions are disabled for this entry point > >

3 3

new XML/sql dumps mirror
by Ariel Glenn WMF 19 Dec '16

19 Dec '16

I'm happy to announce that the Academic Computer Club of Umeå University in Sweden is now offering for download the last 5 XML/sql dumps, as well as a mirror of 'other' datasets. Check the current mirror list [1] for more information, or go directly to download: http://ftp.acc.umu.se/mirror/wikimedia.org/dumps/ http://ftp.acc.umu.se/mirror/wikimedia.org/other/ Rsync is also available. Happy downloading! Ariel [1] https://meta.wikimedia.org/wiki/Mirroring_Wikimedia_project_XML_dumps#Curre…

1 0

2016-12-14 Scrum of Scrums meeting notes
by Grace Gellerman 18 Dec '16

18 Dec '16

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-12-14 = 2016-12-14 = == Product == === Reading === ==== iOS native app ==== * Last Week ** Finished work on 5.3.2, shipped to beta (Dynamic text size, data layer update, performance enhancements) https://phabricator.wikimedia.org/project/view/2281/ * This week ** Monitor 5.3.2 beta & regression testsing, fix any issues, release 5.3.2 on Thursday or Friday ** Start work on 5.4 (Nearby, Login updates) https://phabricator.wikimedia.org/project/view/2326/ ==== Android native app ==== * Last week: ** Bug fixes for new release ** Continuing Q2 goals for Wikidata descriptions ** New prod release v2.4.183 ** Initial survey ** Internal test automation discussions; now over 300 unit tests in CI * Next week (https://phabricator.wikimedia.org/project/view/2352/ ): ** More Q2 goals for Wikidata descriptions (polish) ==== Mobile Content Service (MCS) ==== * Board: https://phabricator.wikimedia.org/project/board/1323/query/open/ * Deployed: ** Updated announcements endpoint to shorten survey for Android app (getting lots of responses) ** Caching announcement responses * To be deployed: ** Emitted etags have double quotes now. https://phabricator.wikimedia.org/T150886 ==== Reading Web ==== * Current sprint: https://phabricator.wikimedia.org/project/view/2362/ * Last week: ** Create importable test pages that can be used to test various Reading Web related changes https://phabricator.wikimedia.org/T137527 ** Hovercards rewrite finish up ** Continue working on returning page images from the lead section only * Until we meet next time: ** Make hovercards preferences available on the settings page ** PagePreviews reading depth ==== Reading Infrastructure ==== * API 18n patches go live this week! announcement: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-December/… * starting work on TemplateStyles * blocked: ** WMDE on the last i18n patch before we can move to hard deprecation: https://gerrit.wikimedia.org/r/#/c/321464/ ** could use some advice from Performance on dealing with huge JS data blobs: *https://phabricator.wikimedia.org/T32574#2836570* <https://phabricator.wikimedia.org/T32574#2836570> ** MediaViewer tests failing, mw.language tests seem to be the cause: https://phabricator.wikimedia.org/T152476 * not blocking === Community Tech === * Blockers: None * Blocked: Nope * Updates: ** Created a special page report for looking at page assessment data: https://en.wikipedia.org/wiki/Special:PageAssessments?project=History *** Note that pagination is broken at the moment and the fix will be deployed soon ** Converted a bunch more wikis to numeric and uca collation: https://phabricator.wikimedia.org/T149002 ** Continued work on supporting Programs Dashboard ** Bug fixes on CopyPatrol ** Work in progress for deploying Copypatrol for Czech wikipedia ** Community Wishlist Survey ended with 265 proposals and loads of exciting proposals. === Editing === ==== Collaboration ==== * Updates ** https://www.mediawiki.org/wiki/Collaboration/Deployment_planning ** Edit Review Improvements *** New RecentChanges filters *** Drop inconsistent filters ** Echo *** Fixed unread notification count caching *** Switched to extension.json ** FlaggedRevs (Collaboration team is taking more active involvement here in support of deferred changes ( https://en.wikipedia.org/wiki/Wikipedia:Deferred_changes) project) *** Various fixes ** ORES *** Various fixes ==== Language ==== * Blocked: ** Performance: https://phabricator.wikimedia.org/T152180 - This is Unbreak Now for ULS, but need moreinfo on it. Language team can't reproduce it. ** CI/Jenkins: https://phabricator.wikimedia.org/T153038 - mwext-qunit-jessie test fails on unrelated change(s). ** In ContentTranslation, there's a significantly larger number of badtoken errors in saving articles lately. Did anybody notice this for editing in general? ==== Parsing ==== * Linter extension is now in beta cluster (ex: https://en.wikipedia.beta.wmflabs.org/wiki/Special:LintErrors ) * Services, VE, and Parsing teams collectively decided to postpone deployment of splitting data-mw attribute from the HTML for later when it has higher urgency since Mobile Content Service is already doing this split on their own and no other Parsoid client wants it, and VE doesn't like it right now. * We are still trying to figure out whether we want to use HTML5Depurate (Java) or a PHP version for our pilot deployment of a Tidy replacement. * Work ongoing to parse and render language variants in Parsoid (which includes some fixes to the PHP parser's language variant parsing as well). Close to being finished. === Discovery === * No blockers * Continuing work on crosswiki search and refactoring Special:Search. Load tests OK, now doing relevancy tests. * Refactoring query parsing to allow extensions to add search keywords * Improved handling of characters containing diacritics or accents * Released tabular and map data namespaces to Commons: https://www.mediawiki.org/wiki/Help:Tabular_Data and https://www.mediawiki.org/wiki/Help:Map_Data * Discovery narrative and roadmap 2016-2017: https://www.mediawiki.org/wiki/File:Discovery_narrative_FY_2016-17.pdf == Technology == === Release Engineering === * Blocking ** (Language) CI/Jenkins: https://phabricator.wikimedia.org/T153038 - mwext-qunit-jessie test fails on unrelated change(s). * Blocked ** Nothing right now * Updates ** Reminder last week for deployments is this week until Jan 3rd: https://lists.wikimedia.org/pipermail/wikitech-l/2016-November/086936.html === Security === * Security Reviews ** Recommendations API ** Sanitarium review ** LoginNotify ** Working on scheduling reviews for Wikidata: *** Cognate extension: https://phabricator.wikimedia.org/T149082 *** InterwikiSorting Extension: https://phabricator.wikimedia.org/T149083 === Services === * Blockers: none * Updates: ** Trending service deployed. Some bugs were discovered and still to be fixed *** https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits ** Citoid is behind RESTBase now. *** https://en.wikipedia.org/api/rest_v1/#!/Citation/getCitation === Technical Operations === * Alex has a conflicting meeting up, will probably make the last 10 minutes of the meeting though * '''Blocked''' ** CommunityTech on "Frequent duplicate key errors by page assessments" https://phabricator.wikimedia.org/T152080 * '''Blocking''' ** None * '''Updates''' ** API woes ongoing ** Draft goals posted, again if teams have dependencies on ops for next Quarter, please inform us. ** Labs team is at low capacity, due to severe weather conditions in India ** There is a goal for full precise deprecation next quarter, so expect anything precise in labs or production to have to either migrate of cease existing === Performance === * Not blocked * Team offsite last week. Redefined our long-term goals and short-term projects. Cleaned up by backlog (trimmed by 16%). https://www.mediawiki.org/wiki/Wikimedia_Performance_Team#Focus * Experimented with Grafana 4 alerts. Available right now, use them! == Wikidata == == Fundraising Tech == * added googleweblight to non-JS browser list ** proxy works like opera mini, runs JS server side and renders page down, sometimes breaking it ** https://phabricator.wikimedia.org/T152602, about to deploy https://gerrit.wikimedia.org/r/327043 * Eileen published our first real CiviCRM extension to https://civicrm.org/extensions/unsubscribe-email-data-entry-screen ** existing extensions are all actually Drupal modules, not publicized except in gerrit ** hope more of our code becomes widely usable https://www.mediawiki.org/wiki/Fundraising_tech/Free_Software_Citizenship ** Katie is helping push for time in 2017 to further those goals ** If you have contacts at other non-profits that might be interested in open source payment processing and donor relationship software, please email fr-tech@ * more work on internal dashboard, including adding a vagrant role === Analytics === No blockers nor blocked Updates: * Hired a new engineer who started this week * Worked on information architechture of wikistats2.0 with designer contractor and Erik Z * Worked on cleaning up our mediawiki history reconstruction scala code

3 2

List of clients which try to guess MediaWiki thumbnail URLs
by Gergo Tisza 17 Dec '16

17 Dec '16

The current format of MediaWiki thumbnail URLs is very ad hoc: it depends on the media handler, the contents of the file, and a dozen different configuration settings. As a consequence, it is impossible to guess what a thumbnail URL will be, given the filename and the desired size; clients have to request it from the AP and waste hundreds of valuable milliseconds, or use complicated logic to guess it and accept that sometimes they will end up with the wrong result. There is an ongoing discussion about rethinking the URL format so that it can be used as a proper API. [1] As part of that, I would like to make a list of clients which try to guess thumbnail URLs on their own, instead of fetching them from the API - these clients will need to be updated if we change the URL format. If you know of any, please add them to T153498 [2], and preferably some information on what they do. Clients can include mobile apps, user scripts, bots, whatever you can think of. Thanks! [1]: https://phabricator.wikimedia.org/T66214 [2]: https://phabricator.wikimedia.org/T153498

1 0

Discovery Weekly Update for the week starting 2016-12-12
by Chris Koerner 16 Dec '16

16 Dec '16

Greetings, Here is another weekly update on the work of the Discovery department. If you have questions, please ask! == Highlights == * Published Maps Terms of Use [0] == Discussions == === Search === * The time needed to restart our elasticsearch clusters is improving [1] * Fixed a rare edge case where a wiki could show duplicate results when detecting query language [2] * Fixed a rare edge case that could cause fewer results to be displayed than expected on French projects [3] === Portal === * Wikipedia.org portal article stats were updated on 12 Dec 2016 [4] * Updated Wikipedia portal with translations for browsers that have their primary language other than English. [5] === Interactive === * Kartotherian and Tilerator configurations are now deployed with scap3, a more streamlined process [6] * Updated static maps to now be faster in showing updated details [7] * Updated what we're logging for metrics [8] [0] https://wikimediafoundation.org/wiki/Maps_Terms_of_Use [1] https://phabricator.wikimedia.org/T145065 [2] https://phabricator.wikimedia.org/T153051 [3] https://phabricator.wikimedia.org/T151173 [4] https://phabricator.wikimedia.org/T128546 [5] https://phabricator.wikimedia.org/T142582 [6] https://phabricator.wikimedia.org/T150021 [7] https://phabricator.wikimedia.org/T150358 [8] https://phabricator.wikimedia.org/T151929 ---- The full update, and archive of all past updates, can be found on MediaWiki.org: https://www.mediawiki.org/wiki/Discovery/Status_updates Interested in getting involved? See tasks marked as "Easy" or "Volunteer needed" in Phabricator. [1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R [2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R Yours, Chris Koerner Community Liaison - Discovery Wikimedia Foundation

1 0

Re: [Wikitech-l] [Wmfall] Design statement of purpose reviewed
by Grace Gellerman 16 Dec '16

16 Dec '16

+1 to Anna's :) Good job everyone! On Fri, Dec 16, 2016 at 8:10 AM, Anna Stillwell <astillwell(a)wikimedia.org> wrote: > :) > > On Thu, Dec 15, 2016 at 3:09 AM, Pau Giner <pginer(a)wikimedia.org> wrote: > >> Hi all, >> >> Some months ago we started to define a statement of purpose for design at >> Wikimedia. We shared our initial iteration and got useful feedback. Based >> on that feedback, we have updated a new version: https://www.mediawiki >> .org/wiki/Design/Statement_of_purpose >> >> Please, feel free to check the updated version, and provide any >> suggestion in the talk page. >> >> If the statement just sounds as a logical, simple, and obvious >> description for the purpose of design here, that was the goal. Putting this >> in writing has been helpful for designers and people working with us to get >> into the same page, and will be useful in the future to achieve the level >> of support for design we envision for those areas where we are not there >> yet. >> >> Thanks to everyone that has contributed to the process. >> >> -- >> Pau Giner >> Senior User Experience Designer >> Wikimedia Foundation >> >> >> _______________________________________________ >> Wmfall mailing list >> Wmfall(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wmfall >> >> > > > -- > "If you have knowledge, let others light their candles in it." - Margaret > Fuller > > Anna Stillwell > Director of Culture > Wikimedia Foundation > 415.806.1536 <(415)%20806-1536> > *www.wikimediafoundation.org <http://www.wikimediafoundation.org>* > > > _______________________________________________ > Wmfall mailing list > Wmfall(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wmfall > >

2 1

Arbitrary Wikidata querying
by MZMcBride 16 Dec '16

16 Dec '16

Hi. If I wanted to make a page on the English Wikipedia using wikitext called "List of United States presidents" that dynamically embeds information from <https://www.wikidata.org/wiki/Q23> and <https://www.wikidata.org/wiki/Q11806> and other similar items, is this currently possible? I consider this to be arbitrary Wikidata querying, but if that's not the correct term, please let me know what to call it. A more advanced form of this Wikidata querying would be dynamically generating a list of presidents of the United States by finding every Wikidata item where position held includes "President of the United States". Is this currently possible on-wiki or via wikitext? If either of these querying capabilities are possible, how do I do them? I don't understand how to query Wikidata in a useful way and I find this frustrating. Since 2012, we've been putting a lot of data into Wikidata, but I want to programmatically extract some of this data and use it in my Wikipedia editing. How do I do this? If these querying capabilities are not currently possible, when might they be? I understand that cache invalidation is difficult and that this will need a sensible editing user interface, but I don't care about all of that, I just want to be able to query data out of this large data store. MZMcBride

7 10

Development on img_auth.php
by Robert Vogel 16 Dec '16

16 Dec '16

Hello! Recently I've worked on some MediaWiki setups with enabled "img_auth.php". During that work I've noticed a few things that I think can be improved, to make an extension developer's life easier. I know that this feature is mostly used by private/intranet wikis, so there are only limited resources for future development available at the WMF. Therefore I'd like to volunteer to work on "img_auth.php". Is this something the Wikimedia dev community is interested in? Can I count on some support by the original maintainers of "img_auth.php"? I'd be happy about any feedback. Oh, and I've already created a Phabricator task: https://phabricator.wikimedia.org/T153174 -- Robert Vogel

2 1

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 December 2016