Wikitech-l January 2016

wikitech-l@lists.wikimedia.org

93 participants
86 discussions

Developer Relations Weekly Summary
by Quim Gil 02 Feb '16

02 Feb '16

The Winter break took longer than expected. Busy times! You can help develop the next summary. *Developer Relations focus* * Wrapping up Google Code-in 2015 * Wikimedia Hackathon 2016 travel sponsorship requests * Wikimedia Developer Summit 2016/Lessons Learned * Developer Relations strategy and annual plan There is a lot more at https://www.mediawiki.org/wiki/Developer_Relations/Weekly_summary#2016-01-26 -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

5 6

New [[Main Page]] for Wikitech
by Bryan Davis 02 Feb '16

02 Feb '16

I've been working on a little redesign project for the Main Page on wikitech [0] and three key sub pages it points to since 2016-01-01 in my User space. Tonight I decided that although it is far from perfect it is better enough. I hope that some of you like it better than the old page and that none of you hate it with a fiery passion that compels you to revert it rather than helping me make it better. [0]: https://wikitech.wikimedia.org/wiki/Main_Page Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

10 10

Parsoid entrypoint http://parsoid-lb.eqiad.wikimedia.org being decommissioned
by Subramanya Sastry 02 Feb '16

02 Feb '16

Hello everyone, The public Parsoid endpoint http://parsoid-lb.eqiad.wikimedia.org is being decommissioned [1] once we migrate over all straggler references to that endpoint [1] possibly as soon as 3 weeks from now. As far as we know, there are very few requests to that endpoint right now, but if you have been using that endpoint, please switch over to using the RESTbase service instead. You can access Parsoid HTML for the wikimedia wikis via their REST API endpoint. For example, https://en.wikipedia.org/api/rest_v1/?doc is the REST API url for English Wikipedia content. Thanks, Subbu. 1. https://phabricator.wikimedia.org/T110474

3 4

VisualEditor deployment to 1000+ users: who wants the feedback?
by Daniel Barrett 01 Feb '16

01 Feb '16

Within the next few weeks, I'll be deploying VisualEditor for 1000+ authors here at Cimpress/Vistaprint, in a wiki with 225,000 articles. I plan to collect feedback from our users on what works and what doesn't. What would be the best way to communicate this feedback to Wikimedia? Here are some early, informal comments from our pilot group of 20 users: "I am in love!" "TemplateData integration is awesome." "How do I insert <code> tags?" (He didn't notice the "More" link in the font menu.) "How do I set the width of a table column?" "How do I copy and paste table rows?" "Editing links is fiddly" (https://phabricator.wikimedia.org/T124305) "I didn't see the editing tools at first because they're white on a white background." "Can we save the page without having a pop-up?" Thanks, DanB

3 3

Announcing mediawiki-containers, a Docker-based MediaWiki installer
by Gabriel Wicke 30 Jan '16

30 Jan '16

I am writing to announce mediawiki-containers [1], a simple installer for MediaWiki with VisualEditor, Parsoid, RESTBase and other services, using Linux containers. The main goal of this project is to make it really easy to set up and maintain a fully featured MediaWiki system on a wide range of platforms. The project is in an early stage, but already supports full installation on Ubuntu, Debian and other systemd-based distributions, as well as starting containers on OS X via the Docker toolbox [6]. These are the basic steps involved in setting up your own MediaWiki instance with VisualEditor: 1) Get a Linux VM in labs or from a hosting provider, and select Debian (Jessie or newer) or Ubuntu 15.04+ as the distribution. Commercial VMs with reasonable specifications cost about $5 per month [2]. 2) Log into your VM, and run this command [7]: curl https://raw.githubusercontent.com/wikimedia/mediawiki-containers/master/med… | sudo bash 3) Answer the questions in the installer. Here is a screencast of an installer run, illustrating steps 2) and 3): https://people.wikimedia.org/~gwicke/mediawiki-containers-install.ogv Under the hood, mediawiki-containers uses several Docker containers: - wikimedia/mediawiki [3] with MediaWiki 1.27-wmf9 and VisualEditor. - wikimedia/mediawiki-node-services [4] with Parsoid and RESTBase running in a single process to minimize memory use. - MariaDB as the database backend [5]. Data and configurations are stored on the host system in /srv/mediawiki-containers/data, which means that upgrading is as simple as fetching the latest container images by re-running the installer. Optionally, the installer can set up automated nightly updates, which helps to keep your wiki installation up to date. The project is brand new, so there is a fair chance that you will encounter bugs. Please report issues at https://phabricator.wikimedia.org/maniphest/task/create/?projects=mediawiki… . Here are some ideas we have for the next steps: - Forward `/api/rest_v1/` to RESTBase & configure RESTBase updates. Enable Wikitext / HTML switching in VE. - Improve security: - Run each container under a different, unprivileged user. - Secure the install / update process with signatures. - Add popular extensions, and streamline the support for custom extensions. - Add services like mathoid, graphoid. - Use the HHVM PHP runtime instead of Zend, possibly using ideas from https://github.com/kasperisager/php-dockerized. - Support developer use cases: - Optionally mount code volumes from the host system. - Improve configuration customization support. - Support for more distributions. Let us know what you think & what you would like to see next at https://phabricator.wikimedia.org/T92826. Happy holidays, Gabriel Wicke and the Services team [1]: https://github.com/wikimedia/mediawiki-containers [2]: http://serverbear.com/compare?Sort=BearScore&Order=desc&Server+Type=VPS&Mon… [3]: https://github.com/wikimedia/mediawiki-docker and https://hub.docker.com/r/wikimedia/mediawiki [4]: https://github.com/wikimedia/mediawiki-node-services and https://hub.docker.com/r/wikimedia/mediawiki-node-services/ [5]: https://hub.docker.com/_/mariadb/ [6]: https://docs.docker.com/mac/step_one/ [7]: We agree that `curl | bash` has its risks, but it is hard to beat for simplicity. The Chef project has a good discussion of pros, cons & alternatives at https://www.chef.io/blog/2015/07/16/5-ways-to-deal-with-the-install-sh-curl… .

5 6

Unable to log into phabricator
by Devang Gaur 29 Jan '16

29 Jan '16

I registered into phabricator with my Mediawiki account initially . Now when I opt for "login or register via mediawiki" . It takes me to a new account registration page whereas I have an existing phabricator account (@dg711) already linked with that same mediawiki account . Is that a bug or what ? Please help me resolve this . Thanks , Devang Gaur

2 1

*unclear-"now"-timestamp* (was Re: Bot operators: Please check your configuration)
by Brad Jorsch (Anomie) 29 Jan '16

29 Jan '16

On Fri, Jan 29, 2016 at 1:41 PM, Bináris <wikiposta(a)gmail.com> wrote: > 2016-01-29 18:56 GMT+01:00 Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org>: > > > by going to > > https://www.mediawiki.org/wiki/Special:ApiFeatureUsage, entering your > > agent > > (or any useful prefix of it), and looking for "https-expected". > > > > What does *unclear-"now"-timestamp* mean here? > For various API timestamp-typed parameters, you can pass unusual values such as the empty string or "0" and it will be interpreted as meaning "now", which doesn't make very much sense except for the fact that it has always done that. If you really mean "now", you should pass that as the value instead. action=edit even has to hack around this to avoid spurious edit conflicts if you do it for the 'basetimestamp' parameter. Ideally we'd make empty string and '0' be rejected as invalid timestamps, but first people have to stop passing them in. -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

2 1

Bot operators: Please check your configuration
by Brad Jorsch (Anomie) 29 Jan '16

29 Jan '16

It currently still works to POST to the API via http instead of https. But we'd really like to stop allowing that, see https://phabricator.wikimedia.org/T105794. Thus, the API will now return a warning if https was expected but not used. If you run a bot, please check your configuration to make sure that you're using https rather than http. If you're using a distinctive user agent for your bot (which you all are, right?[1]), you can now check whether your bot is using http by going to https://www.mediawiki.org/wiki/Special:ApiFeatureUsage, entering your agent (or any useful prefix of it), and looking for "https-expected". If for some reason your bot cannot support https, you really should upgrade it to make that happen. [1]: https://meta.wikimedia.org/wiki/User-Agent_policy -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

2 1

[FINAL COMMENT PERIOD] [RFC]: Defining a policy for REST API result format versioning / negotiation
by Gabriel Wicke 29 Jan '16

29 Jan '16

This is now entering its final comment period, so please weigh in at https://phabricator.wikimedia.org/T124365. Based on your input, the Parsing, Editing & Services teams will make a decision on this next Wednesday, Feb 2nd. Thanks, Gabriel On Thu, Jan 21, 2016 at 4:29 PM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote: > Hi, > > we are considering a policy for REST API end point result format > versioning and negotiation. The background and considerations are > spelled out in a task and mw.org page: > > https://phabricator.wikimedia.org/T124365 > https://www.mediawiki.org/wiki/Talk:API_versioning > > Based on the discussion so far, have come up with the following > candidate solution: > > 1) Clearly advise clients to explicitly request the expected mime type > with an Accept header. Support older mime types (with on-the-fly > transformations) until usage has fallen below a very low percentage, > with an explicit sunset announcement. > > 2) Always return the latest content type if no explicit Accept header > was specified. > > We are interested in hearing your thoughts on this. > > Once we have reached rough consensus on the way forward, we intend to > apply the newly minted policy to an evolution of the Parsoid HTML > format, which will move the data-mw attribute to a separate metadata > blob. > > Gabriel Wicke -- Gabriel Wicke Principal Engineer, Wikimedia Foundation

1 0

Re: [Wikitech-l] [Mediawiki-api] [Engineering] Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Gabriel Wicke 29 Jan '16

29 Jan '16

Luigi, On Thu, Jan 28, 2016 at 2:09 AM, XDiscovery Team <info(a)xdiscovery.com> wrote: > I tried /rest_v1/ endpoint and it is terribly fast. that is great to hear. A major goal is indeed to provide high volume and low latency access to our content. > @Strainu / @Gabriel , what does 'graph' extension do ? If you refer to https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_graph_png…, this is an end point exposing rendered graph images for https://www.mediawiki.org/wiki/Extension:Graph (as linked in the end point documentation). > I have few questions for using proxy cache: > 1# Is it possible to query a page by page_ID and include redirect? We don't currently provide access by page ID. Could you describe your use case a bit to help us understand how access by page id would help you? > /page/title/{title} > allow to get metadata by page, including the pageID , but I would like to > have final page redirect (e.g. dna return 7956 and I would like to fetch > 7955 of redirected 'DNA' ) We are looking into improving our support for redirects: https://phabricator.wikimedia.org/T118548. Your input on this topic would be much appreciated. > /page/html/{title} get the article but page_ID / curid is missing in source > I would like to get the two combined. This information is actually included in the response, both in the `ETag` header and in the <head> of the HTML itself. I have updated the documentation to spell this out more clearly in [1]. The relevant addition is this: The response provides an `ETag` header indicating the revision and render timeuuid separated by a slash (ex: `ETag: 701384379/154d7bca-c264-11e5-8c2f-1b51b33b59fc`). This ETag can be passed to the HTML save end point (as `base_etag` POST parameter), and can also be used to retrieve the exact corresponding data-parsoid metadata, by requesting the specific `revision` and `tid` indicated by the `ETag`. > 2# The rest are experimental: > what could happen if a query fail? > Does it raise an error, return 404 page or what else? The stability markers are primarily about request and response formats, and not about technical availability. Experimental end points can change at any time, which can result in errors (if the request interface changed), or return a different response format. We are currently discussing the use of `Accept` headers for response format versioning at https://www.mediawiki.org/wiki/Talk:API_versioning. This will allow us to more aggressively stabilize end points by giving us the option of tweaking response formats without breaking existing clients. > I am thinking if possible to use api.wikipedia as fallback, and use proxy > cache as primary source any ajax example for doing that to handle possible > failures? Yes, this is certainly possible. However, you can rely on end points currently marked as "unstable" in the REST API. Basically all of them are used by a lot of production clients at this point, and are very reliable. Once we introduce general `Accept` support, basically all of the unstable end points will likely become officially "stable", and several `experimental` end points will graduate to `unstable`. > 3# Does /rest/ endpoint exist also for other languages? Yes, it is available for all 800+ public Wikimedia projects at /api/rest_v1/. [1]: https://github.com/wikimedia/restbase/pull/488/files#diff-2b6b60416eaafdf0a… -- Gabriel Wicke Principal Engineer, Wikimedia Foundation

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

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