Hi, I'd like to present a new RFC for your consideration:
https://www.mediawiki.org/wiki/Requests_for_comment/Minifier
It is about how we can shave 10-15% off the size if JavaScript
delivered to users.
Your comments are highly welcome!:)
--
Best regards,
Max Semenik ([[User:MaxSem]])
When api.php was basically the only API in MediaWiki, calling it "the API"
worked well. But now we've got a Parsoid API, Gabriel's work on a REST
content API, Gabriel's work on an internal storage API, and more on the
way. So just saying "the API" is getting confusing.
So let's bikeshed a reasonably short name for it that isn't something awful
like "the api.php API". I'm horrible at naming.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Thank you for the quick fix!
Best,
--
Sukyoung
On Jan 29, 2014, at 9:55 AM, Nathan wrote:
> FYI in case you aren't subscribed to the list.
>
> ---------- Forwarded message ----------
> From: Yair Rand <yyairrand(a)gmail.com>
> Date: Tue, Jan 28, 2014 at 7:25 PM
> Subject: Re: [Wikitech-l] Bug in the Wikipedia main web page
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
>
>
> Thank you for pointing out this bug. Your suggested change to
> MediaWiki:Gadget-wm-portal.js has been implemented by Meta-Wiki
> administrator User:PiRSquared17.
>
>
> On Tue, Jan 28, 2014 at 6:50 PM, Sukyoung Ryu <sukyoung.ryu(a)gmail.com>wrote:
>
> > Dear all,
> >
> > We are researchers at KAIST in Korea working on finding JavaScript bugs in
> > web pages. While analyzing top websites from Alexa.com, we found an issue,
> > which seems to be a bug, on the Wikipedia main web page (wikipedia.org).
> > We would be grateful if you can either confirm that it is a bug and even
> > better fix it or let us know what we're missing.
> >
> > Here's the issue. When a user selects a language in which search results
> > are displayed via the language selection button from the Wikipedia main web
> > page, the following JavaScript function is executed:
> >
> > 1 function setLang(lang) {
> > 2 var uiLang = navigator.language || navigator.userLanguage, date
> > = new Date();
> > 3
> > 4 if (uiLang.match(/^\w+/) === lang) {
> > 5 date.setTime(date.getTime() - 1);
> > 6 } else {
> > 7 date.setFullYear(date.getFullYear() + 1);
> > 8 }
> > 9
> > 10 document.cookie = "searchLang=" + lang + ";expires=" +
> > date.toUTCString() + ";domain=" + location.host + ";";
> > 11 }
> >
> > Depending on the evaluation result of the conditional expression on line
> > 4, "uiLang.match(/^\w+/) === lang", the function leaves or dose not leave
> > the selected language information on the user's computer through a cookie.
> > But we found that the expression, "uiLang.match(/^\w+/) === lang", always
> > evaluates to false, which results in that the function always leaves
> > cookies on users' computers. We think that changing the contidional
> > expression, "uiLang.match(/^\w+/) === lang", to the expression,
> > "uiLang.match(/^\w+/) == lang", will solve the problem.
> >
> > This problem may occur in the main web pages of all the Wikimedia sites.
> > Could you kindly let us know what you think? Thank you in advance.
> >
> > Best,
> > Changhee Park and Sukyoung Ryu
> >
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Hey all,
TL;DR: jQuery will soon be upgraded from v1.8.3 to v1.11.x (the latest). This
major release removes deprecated functionality. Please migrate away from this
deprecated functionality as soon as possible.
It's been a long time coming but we're now finally upgrading the jQuery package
that ships with MediaWiki.
We used to regularly upgrade jQuery in the past, but got stuck at v1.8 a couple
of years ago due to lack of time and concern about disruption. Because of this,
many developers have needed to work around bugs that were already fixed in later
versions of jQuery. Thankfully, jQuery v1.9 (and its v2 counterpart) has been
the first release in jQuery history that needed an upgrade guide[1][2]. It's a
major release that cleans up deprecated and dubious functionality.
Migration of existing code in extensions, gadgets, and user & site scripts
should be trivial (swapping one method for another, maybe with a slight change
to the parameters passed). This is all documented in the upgrade guide[1][2].
The upgrade guide may look scary (as it lists many of your favourite methods),
but they are mostly just addressing edge cases.
== Call to action ==
This is a call for you, to:
1) Get familiar with http://jquery.com/upgrade-guide/1.9/.
2) Start migrating your code.
jQuery v1.9 is about removing deprecated functionality. The new functionality is
already present in jQuery 1.8 or, in some cases, earlier.
3) Look out for deprecation warnings.
Once instrumentation has begun, using "?debug=true" will log jQuery deprecation
warnings to the console. Look for ones marked "JQMIGRATE" [7]. You might also
find deprecation notices from mediawiki.js, for more about those see the mail
from last October [8].
== Plan ==
1) Instrumentation and logging
The first phase is to instrument jQuery to work out all the areas which will
need work. I have started work on loading jQuery Migrate alongside the current
version of jQuery. I expect that to land in master this week [6], and roll out on
Wikimedia wikis the week after. This will enable you to detect usage of most
deprecated functionality through your browser console. Don't forget the upgrade
guide[1], as Migrate cannot detect everything.
2) Upgrade and Migrate
After this, the actual upgrade will take place, whilst Migrate stays. This
should not break anything since Migrate covers almost all functionality that
will be removed. The instrumentation and logging will remain during this phase;
the only effective change at this point is whatever jQuery didn't think was
worth covering in Migrate or were just one of many bug fixes.
3) Finalise upgrade
Finally, we will remove the migration plugin (both the Migrate compatibility
layer and its instrumentation). This will bring us to a clean version of latest
jQuery v1.x without compatibility hacks.
A rough timeline:
* 12 May 2014 (1.24wmf4 [9]): Phase 1 – Instrumentation and logging starts. This
will run for 4 weeks (until June 9).
* 19 May 2014 (1.24wmf5): Phase 2 – "Upgrade and Migrate". This will run for 3
weeks (upto June 9). The instrumentation continues during this period.
* 1 June 2014 (1.24wmf7) Finalise upgrade.
== FAQ ==
Q: The upgrade guide is for jQuery v1.9, what about jQuery v1.10 and v1.11?
A: Those are regular updates that only fix bugs and/or introduce non-breaking
enhancements. Like jQuery v1.7 and v1.8, we can upgrade to those without any
hassle. We'll be fast-forwarding straight from v1.8 to v1.11.
Q: What about the jQuery Migrate plugin?
A: jQuery developed a plugin that adds back some of the removed features (not
all, consult the upgrade guide[2] for details). It also logs usage of these to
the console.
Q: When will the upgrade happen?
A: In the next few weeks, once we are happy that the impact is reasonably low.
An update will be sent to wikitech-l just before this is done as a final reminder.
This will be well before the MediaWiki 1.24 branch point for extension authors
looking to maintain compatibility.
Q: When are we moving to jQuery v2.x?
A: We are not currently planing to do this. Despite the name, jQuery v2.x
doesn't contain any new features compared to jQuery v1 [3]. The main difference
is in the reduced support for different browsers and environments; most
noticeably, jQuery 2.x drops support for Internet Explorer 8 and below, which
MediaWiki is still supporting for now, and is outside the scope of this work.
Both v1 and v2 continue to enjoy simultaneous releases for bug fixes and new
features. For example, jQuery released v1.11 and v2.1 together[4][5].
-- Krinkle
[1] http://blog.jquery.com/2013/01/15/jquery-1-9-final-jquery-2-0-beta-migrate-
final-released/
[2] http://jquery.com/upgrade-guide/1.9/
[3] http://blog.jquery.com/2013/04/18/jquery-2-0-released/
[4] http://blog.jquery.com/2014/01/24/jquery-1-11-and-2-1-released/
[5] http://blog.jquery.com/2013/05/24/jquery-1-10-0-and-2-0-1-released/
[6] https://gerrit.wikimedia.org/r/131494
[7] https://github.com/jquery/jquery-migrate/blob/master/warnings.md
[8] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg72198.html
[9] https://www.mediawiki.org/wiki/MediaWiki_1.24/Roadmap
Hi all,
I'm Rexford, and just posting here for the first time. Please inform if
this place isn't the right area to suggest features. I was encouraged to
request features here. Please correct me if I'm wrong.
Its about edit conflict on Wikipedia and other projects. It happens when I
get into an article to edit, but before I could save, someone else goes
into the article, edits and save. It happens to myself and many out there.
Sometimes many minutes work of changes can be lost.
The feature request is this: When a person starts editing an article, and
another person tries to edit that same article, he or she gets a message on
screen that the article is already engaged. This suggestion is similar to
how WordPress informs the second person who tries to edit a page whiles
someone else is already editing.
Its likely one wouldn't like to edit a page when he or she knows someone is
in it editing. I think its much better that way than allowing multiple
edits on the page but allowing one persons edit to go in per save.
Thanks.
rexford | google.com/+Nkansahrexford | sent from smartphone
Are you good in swearing? WE NEED YOU
Huggle 3 comes with vandalism-prediction as it is precaching the diffs
even before they are enqueued including their contents. Each edit has
so called "score" which is a numerical value that if higher, the edit
is more likely a vandalism.
If you want to help us improve this feature, it is necessary to define
a "score words" list for every wiki where huggle is about to be used,
for example on English wiki.
Each list has following syntax:
(see https://en.wikipedia.org/w/index.php?title=Wikipedia:Huggle/Config&diff=573…)
score-words(score):
list of words separated by comma, can contain newlines but comma
must be present
example
score-words(200):
these, are, some, words, which, presence, of, increases, the, score,
each, word, by, 200,
So, if you know english better than me, which you likely do, go ahead
and improve the configuration file there, no worries, huggle's config
parser is very syntax-error proof.
If you have any other suggestion how to improve huggle's prediction,
go ahead and tell us!
Shahyar, Juliusz, Trevor, Roan and I met to discuss using oojs inside
the mobile and Flow projects.
The following 3 patches kicks off moving MobileFrontend's class model
towards that of oojs - many thanks for Roan for doing most of the
legwork :-):
https://gerrit.wikimedia.org/r/155593https://gerrit.wikimedia.org/r/155589https://gerrit.wikimedia.org/r/129336
On the long term we'd look to swap out the Class.js and
eventemitter.js files in MobileFrontend for oojs, but this is going to
be tricky and require some care, possibly mixing both oojs and
MobileFrontend's class code in the repository at the same time. e.g.
increasing JavaScript on the short term, but reducing it on the
longterm. The MobileFrontend core development team will need to work
out how best to manage this transition.
Since Flow is very DOM-focused, as opposed to many smaller JavaScript
modules with element management per the currently-accepted use of
OOjs, it is unclear how we may go about integrating with OOjs fully.
However, some potential use cases have been identified as candidates
for implementing OOjs on an interim basis, primarily by abstracting
some current FlowBoardComponent workflows, such as those which handle
(re-)rendering of existing and new content fetched from the API.
Hi,
There are currently three pending patches to change category collation
configuration for various Wikimedia wikis:
https://gerrit.wikimedia.org/r/140580https://gerrit.wikimedia.org/r/147922https://gerrit.wikimedia.org/r/154213
(This generally makes it so that accented letters like 'é' or 'ą' are not
sorted at the end of lists, after 'z', and fixed ordering for languages
with interesting alphabets; see
https://www.mediawiki.org/wiki/Manual:$wgCategoryCollation.)
I have previously been told that these are on hold because of WMF's Trusty
migration and the need to rebuild all existing collation data. (No one
told me how long that might take, but by my estimates that can't possibly
take more than two or three weeks, and I know for a fact that it can be
done with no downtime and minimal problems.)
That was about two months ago.
Is anything known about the current status of the collation things, and
the Trusty migration in general? Is there any public venue that I could
follow to know what is going on, or at least a private one I could be cc'd
on if I asked pretty-please? Is there any ETA, even vague, as to when
things might get done?
I would like to update the bugs that are stuck with this information.
--
Matma Rex
Following up on disabling JavaScript support for IE6 [1], here is some
additional research on other browsers. I'd appreciate if people with
experience testing/developing for/with these browsers would jump in
with additional observations. I think we should wait with adding other
browsers to the blacklist until the IE6 change has been rolled out,
which may expose unanticipated consequences (it already exposed that
Common.js causes errors in blacklisted browsers, which should be fixed
once [2] is reviewed and merged).
As a reminder, the current blacklist is in <resources/src/startup.js>.
As a quick test, I tested basic browsing/editing operation on English
Wikipedia with various browsers. Negative results don't necessarily
indicate that we should disable JS support for these browsers, but
they do indicate the quality of testing that currently occurs for
those browsers. Based on a combination of test results, unpatched
vulnerabilities and usage share, an initial recommendation for each
browser follows.
Note that due to the heavy customization through gadgets/site scripts,
there are often site-specific issues which may not be uncovered
through naive testing.
== Microsoft Internet Explorer 7.x ==
Last release in series: April 2009
- Browsing: Most pages work fine (some styling issues), but pages with
audio files cause JavaScript errors (problem in TMH).
- Editing: Throws JS error immediately (problem in RefToolbar)
Both of these errors don't occur in IE8.
Security vulnerabilities:
Secunia reports 15 out of 87 vulnerabilities as unpatched, with the
most serious one being rated as "moderately critical" (which is the
same as IE6, while the most serious IE8 vulnerability is rated "less
critical").
Usage: <1%
Recommendation: Add to blacklist
== Opera 8.x ==
Last release in series: September 2005
Browsing/editing: Works fine, but all JS fails due to a script
execution error (which at least doesn't cause a pop-up).
Security: Secunia reports 0 unpatched vulnerabilities (out of 26).
Usage: <0.25%
Recommendation: Add to blacklist
== Opera 10.x-12.x ==
Last release in series: April 2014
Browsing/editing: Works fine, including advanced features like
MediaViewer (except for 10.x)
Security: No unpatched vulnerabilities in 12.x series according to
Secunia, 2 unpatched vulnerabilities in 11.x ("less critical") and 1
unpatched vulnerability in 10.x ("moderately critical")
Usage: <1%
Recommendation: Maintain basic JS support, but monitor situation re:
10.x and add that series to blacklist if maintenance cost too high
== Firefox 3.6.* ==
Last release in series: March 2012
Browsing/editing: Works fine (MediaViewer disables itself)
Security: 0 unpatched vulnerabilities according to Secunia
Recommendation: Maintain basic JS support
== Firefox 3.5.* ==
Last release in series: April 2011
Browsing/editing: Works fine (MediaViewer disables itself)
Security: 0 unpatched vulnerabilities according to Secunia
Recommendation: Maintain basic JS support
== Safari 4.x ==
Last release in series: November 2010
Browsing/editing: Works fine
Security: 1 unpatched "highly critical" vulnerability according to
Secunia ("exposure of sensitive information")
Recommendation: Maintain basic JS support, but monitor
== Safari 3.x ==
Last release in series: May 2009
Browsing/editing: Completely messed up, looks like CSS doesn't get loaded at all
Security: 2 unpatched vulnerabilities, "highly critical"
Usage share: Usage reports for Safari in [3] are broken, all Safari
versions are reported as "0.0". However, [4] suggests that Safari 3
usage is negligible/non-existent.
Recommendation: Styling issue may be worth investigating in case it
affects other browsers and/or is JS-caused. Otherwise probably can be
safely ignored.
[1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-August/077952.html
[2] https://gerrit.wikimedia.org/r/#/c/152122/
[3] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
[4] http://stackoverflow.com/questions/12655363/what-is-the-most-old-safari-ver…
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Since we had the luxury of having several people in the office,
Trevor, Juliusz, Rob Moen, Ed Sanders, Shahyar, May, Monte and I sat
down to talk about the problem we currently have of having no standard
way to create icons. Here is my write up of this meeting, again, if
you attended please add/correct me on anything and if you were not
please ask for clarification where needed.
Currently we have two modes of creating icons in MediaWiki
1) Using a font
2) Using SVGs with PNG fallbacks
and the markup varies depending on what extension you look at.
We discussed both approaches and advantages and disadvantages of each.
One of the major disadvantages of the WikiFont is the additional HTTP
request it creates to download the font and cannot be embedded in the
stylesheet using data uris like SVGs can (due to URL size
restrictions).
One of the major advantages of WikiFont is you can design a grayscale
icon, and style it using font colour. Shahyar was happy to move Flow
to using SVG based fonts if we could build grayscale SVGs and change
their colours using ResourceLoader. One concrete example is when you
have an icon used in a constructive anchor. The icon needs to be
green, but when hovered over a lighter green.
Another advantage brought up by May was that currently she finds it
much easier to build icons in this way, and that having to maintain
separate coloured versions of the SVGs is a pain point to her.
We decided that we should push towards using SVGs that can be built
into fonts for the purpose of the app.
As next steps
1) Monte to explore using SVGs in the Wikipedia apps. He will create
font from SVGs. He will work with May to ensure her workflow is as
easy as before.
2) Trevor is going to look into how we can automatically generate
different colour versions of SVGs and automatically create PNGs from
them.
3) I am going to aim to agree on a standard icon HTML markup for
mediawiki ui. We still have an issue with the fact that everyone is
using different HTML markup to create icons. After reviewing all our
current approaches [1] it was clear that we were relatively closely
aligned and that it simply is a case of agreeing on class names.
We aim to get all the above done by Sept 15th, 2014 so please poke us
on the mailing list if you haven't had a follow up then.
Full disorganised notes can be found here [2].
[1] https://www.mediawiki.org/wiki/Icon_standardisation
[2] http://etherpad.wikimedia.org/p/Icon_standardisation