Hey all,
Following a brief chat in IRC, I've proposed[0] adding curl to the list of
PHP extensions required by MediaWiki, and Chad thought it'd be a good idea
to get wider thoughts before merging.
Right now we have some features that require curl (it's probably the #2
issue third parties have with installing VisualEditor, for instance, after
mis-matched versions).
We already require mbstring (as discussed in March) alongside xml, ctype,
json, and iconv. If you have an opinion, please weigh in on the task.[1]
[0] - https://gerrit.wikimedia.org/r/#/c/294259/
[1] - https://phabricator.wikimedia.org/T137926
J.
--
James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.
jforrester(a)wikimedia.org | @jdforrester
https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-06-29
= 2016-06-29 =
== Product ==
=== Reading ===
==== iOS ====
* 5.0.5 - found a regression on Monday, fixing and testing in beta for the
rest of the week. Expecting to deploy next week
* 5.1 (no changes)
** In development - expected release early August
** Potential blocker for release is GeoData API improvements
https://phabricator.wikimedia.org/T137178 We are working with Discovery to
get this in for our release (blocker INTERACTIVE TEAM)
==== Android ====
* Feed work continues -- will ship to beta channel optimistically by end of
this week, otherwise sometime next week
==== Mobile Content Service ====
* Will need the services team to activate the feed endpoints in the public
REST API before shipping the feed (but work is still in progress)
==== Reading Web ====
* Image lazy loading on mobile web fawiki and ukwiki
* Image lazy loading plus reference lazy loading coming soon to mobile web
tlwiki (approx 30-June-2016 or 4-5 July 2016)
* Wikidata article descriptions added to top of page on mobile web cawiki,
coming to mobile web plwiki 30-June-2016
* Mobile main pages were errantly getting desktop formatting in some places
for a while, now fixed
==== Reading Infrastructure ====
* waiting for Language to say whether they will take T111486 (Update
Translate to use AuthManager)
=== Editing ===
==== Parsing ====
* Parsoid:
** Over last couple weeks, working on a bunch of link rendering /
serialization issues (mostly edge cases) in Parsoid
** About to resume work on native implementation of <gallery> extension --
Arlo has an initial patch in gerrit which needs a round of updates. Should
unblock multimedia & VE work on gallery support once this is done.
** At Wikimania hackathon, Scott worked on an update to support a more
detailed Templatedata format field for serializing transclusions -- this is
not finalized yet and the spec needs to stabilize before this can land.
* Core parser:
** Tim working on a side-by-side preview tool to let editors see how a page
would look with Tidy and with HTML5depurate -
https://gerrit.wikimedia.org/r/#/c/296182/ ... feedback welcome,
especially on the UI aspects or desirable features. Please take a look and
leave comments on the patch.
== Technology ==
=== Technical Operations ===
* '''Blocking'''
** None
* '''Blocked'''
** by noone
* Updates
** Slow week, wikimania
** Some work with interactive/discovery on maps
** some non user affecting changes in our firewalling setup
** Working with LE to review/upload on apt.wikimedia.org apertium related
packages
=== Security ===
* One usability bugs for Ex::OATHAuth in progress (T138423) (help
reproducing appreciated)
* Two-factor usability survey prep continues
* Reviews: 3d2png
* Three additional reviews will have feedback added this week: T130233,
T129175, T132934
=== RelEng ===
* Blocking
** None?
* Blocked
** Gallium phase out questions: https://phabricator.wikimedia.org/T133300
*** Pasted some IRC talk from chase
*** Other input welcome
** CI Documentation publication: https://phabricator.wikimedia.org/T137890
*** Mostly needs some network expertise
** Scandium disk space: https://phabricator.wikimedia.org/T138955
* Updates
** Train is back on track, wmf.8 to group1 today
** 1.27 release is out (yay!)
** Scap3 migrations continue (if you have questions, ask us! :))
=== Analytics ===
* Rebooting stat boxes and analytics cluster to upgrade kernel (security
patch)
* Working on testing a much faster way to load Cassandra directly from
Hadoop
* Cleaning up mediawiki page and user history is still ongoing
* Andrew, Madhu, and Nuria will be out until next week
== Discovery ==
* '''Blocking''': none
* '''Blocked''': none
* TextCat A/B test still running
* New research on typing in wrong character set:
https://www.mediawiki.org/wiki/User:TJones_(WMF)/Notes/Typing_on_the_Wrong_…
* Testing software upgrade for logstash.wikimedia.org at kibana4.wmflabs.org
- backward incompatible upgrade
* WDQS now deployed with scap3
* Everybody's welcome to rate query relevance in Discernatron:
https://discernatron.wmflabs.org/
=== Interactive Team ===
* Wikidata Query service support in geo shapes service is being deployed
* Heavy maps refactoring - might have broken cached pages and will need a
regen
* Need to start deploying shared GeoShapes & tabular data soonish
* RELENG: please make configuration for services available to devs, not
just ops
; '''blocking'''
* Potential blocker for release is GeoData API improvements
https://phabricator.wikimedia.org/T137178 We are working with Discovery to
get this in for our release (blocker INTERACTIVE TEAM)
== WIkidata ==
* Blockers: See T107595.
* Most of the team attended Wikimania.
** Relevant discussions about our plans for a Wikidata-powered Wiktionary:
https://phabricator.wikimedia.org/T986
** WMF support for multi content revisions was promised:
https://phabricator.wikimedia.org/T107595
TL;DR: Gadgets should use HTTP POST for purge/rollback/markpatrolled
actions.
-------
Some gadgets still use HTTP GET for page purge requests.
In order to better facilitate multi-datacenter traffic routing [1] and to
better comply with web standards [2],
these types of requests should use POST instead. GET is considered, by
specification, to be a "safe method".
Since purge requests perform database writes and potentially significant
rendering updates, they should use a
state-changing HTTP method. Also, achieving of our multi-datacenter goal as
planned involves leveraging safe
HTTP methods to route request to either the closest or the primary
datacenter for optimal performance.
Most of such requests to MediaWiki already require POST, but "purge" is one
of the exceptions. There is no
compelling reason for this to be exceptional, however. Exposing a URL
parameter that does database writes,
reparsing, and cache updates simply by following a link (especial with no
CSRF token) encourages bad practice
(having links that bypass cache) and the risk of performance problems if
such a link becomes popular.
Rollback requests should also use HTTP POST given that it results in a page
edit. The database operations are
far more complex than purge, so in a multi-datacenter system, such requests
(if using HTTP GET) could have much worse performance depending on the
client's location (even if very close to a datacenter). Ideally, reversion
tools would use the
API for rollback, instead of index.php.
The markpatrolled action, like rollback, also involves a GET request with a
token parameter. The core JavaScript
MediaWiki provides already uses the API with POST, but users without
javascript (and some Gadgets) are still using
HTTP GET. The Gadgets should be converted to POST.
Purge, rollback, and markpatrolled support both POST and GET right now.
Gadgets still using GET for these actions
should be converted to use POST instead.
There is a task at T135170 [3] for MediaWiki to require POST for purge
requests.
Also see T88044 [4] for the same requirement for rollback requests.
[1] https://phabricator.wikimedia.org/T92357
[2] https://tools.ietf.org/html/rfc7231#section-4.2.1
[3] https://phabricator.wikimedia.org/T135170
[4] https://phabricator.wikimedia.org/T88044
--
-Aaron
Yaron Koren has proposed to reopen the "Unacceptable behavior" section
(https://www.mediawiki.org/wiki/Talk:Code_of_Conduct/Draft#Suggested_change_…).
His perspective and mine are given on the talk page.
In brief:
* He disagrees with how "marginalized and otherwise underrepresented
groups" and "encouraged" are handled in the original text.
* I support the current text and process, and have explained why on the
talk page.
Thanks,
Matt Flaschen
Hi,
Are there any on-going efforts to log JavaScript errors to the server logs?
Every once in a while we see very hard to reproduce errors in the console
that we're not sure how often are actually happening, and that makes us
think that there may be other errors happening that we're not coming across
(or other people savvy enough to open the console and post a bug).
There are open source projects like sentry we could inspect and adapt a
client library for our purposes and log to EventLogging or somewhere else (
https://docs.getsentry.com/hosted/clients/javascript/).
Hi,
With the release of MediaWiki 1.27, the lifetime of MediaWiki version
1.25.x has come to an end.
Users still using MediaWiki 1.25.x are advised to upgrade to version
1.27.0, the latest stable and
LTS version.
--Chad Horohoe
_______________________________________________
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
Hi everyone,
With Wikimania and associated summer travel, this is going to be a rough
week to get everyone together at our usual time for the weekly
ArchCom-RFC IRC office hour:
<https://phabricator.wikimedia.org/E224>
There are a couple of RFCs that might make good short-term choices:
- T137926 - Require 'curl' PHP extension for MediaWiki[1]
James filed this a couple of weeks ago as a "μRfC". The hope is
to enable greater use of MultiHttpClient.
<https://phabricator.wikimedia.org/T137926>
- T136866 - Improve the per-programming-language listings for our
tools[2]
Quiddity plans to expand this documentation in the coming quarter.
A clearer idea about the status quo would help us guide developers
about which languages we hope to attract new development in.
<https://phabricator.wikimedia.org/T136866>
However, we would welcome suggestions for others. Please comment here:
<https://phabricator.wikimedia.org/E224>
If nothing else, we can use this week's meeting as a triage discussion.
Rob
p.s. Updates continue on Architecture_committee/Status:
<https://www.mediawiki.org/wiki/Architecture_committee/Status>