Task filed for UW and MediaViewer:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/854
---------- Forwarded message ----------
From: Timo Tijhof <ttijhof(a)wikimedia.org>
Date: Wed, Sep 3, 2014 at 2:41 AM
Subject: [Engineering] [BREAKING CHANGE] Deprecated JavaScript methods
removed in MediaWiki 1.25
To: engineering Wikimedia List <engineering(a)lists.wikimedia.org>
TL;DR:
* Several deprecated methods in MediaWiki's JavaScript modules will be
removed
in a few weeks' time.
* Check your code to ensure it won't break with these changes, and update it
if needed.
* Check and fix any gadgets or scripts you or your wikis rely upon, to
prevent
breakage.
As part of the regular update cycle, a number of deprecated methods in our
JavaScript modules will be removed in the MediaWiki 1.25 release. This is an
announcement to give people notice they should update any extensions,
gadgets
and scripts they have written, maintain, or rely upon.
Usually we don't give this much attention to removal of deprecated methods,
but due to this being our first proper development cycle for our front-end
code base, I want to make sure this reaches everyone. You're likely not yet
in
the habit of updating front-end code between MediaWiki releases.
Deprecated methods to be removed in MediaWiki 1.25:
* Remove mw.user.name() method. [1]
Deprecated since MediaWiki 1.20. Use mw.user.getName() instead.
* Remove mw.user.anon() method. [1]
Deprecated since MediaWiki 1.20): Use mw.user.isAnon() instead.
* Remove mediawiki.api methods' "ok" and "err" callback parameters. [2]
Deprecated since MediaWiki 1.23. Use the returned Promise interface instead.
* Remove mediawiki.api.category "async" parameter. [2]
Deprecated since MediaWiki 1.23. The ability to override $.ajax() to not be
asynchronous has been removed. The default (asynchronous) behaviour remains.
Use the Promise interface to retreive the fetched data from the API.
* Remove jquery.json module.
Deprecated since MediaWiki 1.24. [3] Use standardised JSON.stringify and
JSON.parse methods. And depend on the "json" module to ensure a polyfill is
lazy-loaded for cross-browser support.
## Timeline
These removals will land in MediaWiki 1.25alpha in early October 2014, being
deployed to Wikimedia wikis in October 2014 (probably 1.25wmf2 or 1.25wmf3).
The MediaWiki 1.25.0 stable release is expected to come out around April
2015.
You should make sure that your code is updated before your wiki upgrades to
MediaWiki 1.25. If you know code you rely upon will be affected but don't
know
how to fix it, please check with your wiki's community for local experts. If
none of them can help, you can ask for assistance on the the
wikitech-ambassadors mailing list. [5]
## Reminders
In case you've missed the previous announcements:
* The migration period for jQuery core is still on-going and is also
scheduled
for MediaWiki 1.25. [4] More about that in the mail from June 2014:
https://www.mail-archive.com/mediawiki-l%40lists.wikimedia.org/msg13651.html
* Learn about deprecation notices and how you can see them in your browser.
https://www.mail-archive.com/wikitech-l%40lists.wikimedia.org/msg72198.html
[1] https://gerrit.wikimedia.org/r/#/c/111422/
[2] https://gerrit.wikimedia.org/r/#/c/118733/
[3] https://gerrit.wikimedia.org/r/#/c/140560/
[4] https://gerrit.wikimedia.org/r/#/c/137168/
[5] https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors
– Timo
PS: You can get a sense of the progress on our different migrations, past
and
present, via these graphs: http://codepen.io/Krinkle/full/zyodJ/
PS2: This will soon be sent to wikitech-l, mediawiki-l and
wikitech-ambassadors as well.
_______________________________________________
Engineering mailing list
Engineering(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/engineering
Greetings!
We invite you to join a discussion about Structured Data on Commons, to help us plan our next steps for this project.
The Structured Data initiative proposes to store and retrieve information for media files in machine-readable data on Wikimedia Commons, using Wikidata tools and practices, as described on our new project page (1).
The purpose of this project is to make it easier for users to read and write file information, and to enable developers to build better tools to view, search, edit, curate and use media files. To that end, we propose to investigate this opportunity together through community discussions and small experiments. If these initial tests are successful, we would develop new tools and practices for structured data, then work with our communities to gradually migrate unstructured data into a machine-readable format over time.
The Multimedia team and the Wikidata team are starting to plan this project together, in collaboration with many community volunteers active on Wikimedia Commons and other wikis. We had a truly inspiring roundtable discussion about Structured Data at Wikimania a few weeks ago, to define a first proposal together (2).
We would now like to extend this discussion to include more community members that might benefit from this initiative. Please take a moment to read the project overview on Commons, then let us know what you think, by answering some of the questions on its talk page (3).
We also invite you to join a Structured Data Q&A on Wednesday September 3 at 19:00 UTC, so we can discuss some of the details live in this IRC office hours chat. Please RSVP if you plan to attend (4).
Lastly, we propose to form small workgroups to investigate workflows, data structure, research, platform, features, migration and other open issues. If you are interested in contributing to one of these workgroups, we invite you to sign up on directly on our hub page (5) -- and help start a sub-page for your workgroup.
We look forward to some productive discussions with you in coming weeks. In previous roundtables, many of you told us this is the most important contribution that our team can make to support multimedia in coming years. We heard you loud and clear and are happy to devote more resources to bring it to life, with your help.
We are honored to be working with the Wikidata team and talented community members like you to take on this challenge, improve our infrastructure and provide a better experience for all our users.
Onward!
Fabrice — for the Structured Data team
(1) Structured Data Hub on Commons:
https://commons.wikimedia.org/wiki/Commons:Structured_data
(2) Structured Data Slides:
https://commons.wikimedia.org/wiki/File:Structured_Data_-_Slides.pdf
(3) Structured Data Talk Page:
https://commons.wikimedia.org/wiki/Commons_talk:Structured_data
(4) Structured Data Q&A (IRC chat on Sep. 3):
https://commons.wikimedia.org/wiki/Commons:Structured_data#Discussions
(5) Structured Data Workgroups:
https://commons.wikimedia.org/wiki/Commons:Structured_data#Workgroups
_______________________________
Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation
https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
Hi opsen,
I'm currently working on this changeset:
https://gerrit.wikimedia.org/r/#/c/157157/ whose goal is to pre-render
commonly used thumbnail sizes at upload time, in order to avoid the delay
experienced by users who are the first to view a particular image at a
given size (particularly in media viewer).
So far I've implemented it as a job (in the job queue sense of the term).
Which implies that the server(s) picking up this job type would need to
have the whole stack of image processing software installed on them. The
idea being that we could the resources for this prerendering separately
from the existing pool of on-demand image scalers. Does this approach make
sense from an Ops perspective? Basically having one or more servers with
the same software as image scalers installed on them, configured as job
runners for that particular job type.
The alternative is that the job would cURL the thumbnail urls to hit the
image scalers. I'm not sure that this is a desirable network path, it might
not be the most future-proof thing to expect job runners to be able to hit
our public-facing URLs. Not to mention this makes it a very WMF-specific
solution, whereas the job type approach is more generic. Maybe there's a
better way for a job runner to make the image scalers do something, though.
That alternative approach of hitting thumbnail urls would imply the job
running on the regular pool of job runners. And it would mean that we
probably wouldn't be able to tell apart the resource usage of the
prerendering compared to the regular on-demand thumbnailing that's
happening at the moment.
Mixins in OOjs UI have always had, shall we say, "strange" names.
Popuppable is my personal favorite, but the most strange thing about them
has always been the lack of correlation between their name and what it is
that they actually do. Furthermore, Alex came across a situation where the
convention of providing an element to a mixin at construction is not always
possible.
I've written a patch[1][2][3] which does the following:
- Mixins are now named according to what they do[2], using the "ed"
suffix if the mixin adds/manages attributes, "able" if it adds/manages
behavior and no suffix if it adds content.
- Mixins no longer take a required element argument, but do still allow
the element to be passed through the config options
- Mixins use a set{Type}Element method to set and even change the
element being targeted by the mixin - this is called in the constructor
with an overridable default, but can also be called again and again
Attribute and behavior mixins always operate on this.$element by deafault.
Content mixins always generate an element to operate on by default. Again,
in both cases the element being initially targeted can be configured using
the config object.
This division was made specifically to reduce or eliminate the need for
using this.$( '<{tagName}' ); when invoking the mixin constructor, and
instead doing what was being done most of the time automatically.
The rename will hopefully not cause too much confusion. It's important to
note that both the JavaScript and CSS classes have been updated.
Roan is reviewing the patches and they will probably be merged shortly. If
you know of any code that may be affected by this change but has not been
considered in the patches mentioned, please let me know.
- Trevor
[1] https://gerrit.wikimedia.org/r/#/c/157274
[2] https://gerrit.wikimedia.org/r/#/c/157286
[3] https://gerrit.wikimedia.org/r/#/c/157285
[4] Table of classes that have been renamed
ButtonedElement ButtonElementIconedElement IconElementIndicatedElement
IndicatorElementLabeledElement LabelElementPopuppableElement PopupElement
FlaggableElement FlaggedElement