Hi,
I've wasted a great deal of time today trying to figure out what was
causing issues in resource loader, whereby execution of JS seemed to
randomly abort without any errors. It turns out that a harmless call to
jQuery's .data() within RL was the cause. But not because of mediawiki
code... it was because of the FireQuery Firebug extension, which somehow
overrides or modifies jQuery.data in the execution environment. And not in
a good way, since it just seems to silently abort execution of the JS that
was calling it.
I'm not sure if having Firebug open was necessary for issues to occur. At
any rate, considering that FireQuery hasn't been updated in over a year and
that the author stated that he can't maintain it anymore [1], it seems like
sane advice to disable it.
[1] https://github.com/binaryage/firequery/issues/39#issuecomment-52431755
Legoktm has just merged Gerrit change 160798,[1] Gerrit change 161093,[2]
Gerrit change 160819,[3] and a few associated patches. Collectively, these
make the following changes to the human-readable aspects of the API output,
which will be deployed to WMF wikis with 1.25wmf4 (see
https://www.mediawiki.org/wiki/MediaWiki_1.25/Roadmap for the schedule).
* action=help now outputs a nice HTML page instead of a plain-text document
wrapped in XML.
* Hitting api.php with no parameters will display help for the main module
only, with links to each submodule. One of the examples provided shows how
to get everything on one page as with the old help.
* The default for the 'format' parameter is now jsonfm rather than xmlfm.
* Syntax highlighting for format=jsonfm and format=xmlfm now uses
Extension:SyntaxHighlight_GeSHi rather than ad-hoc code that only worked
right for xmlfm. Other formats are not highlighted.
The patches also change the aspects of action=paraminfo that return
help-related information:
* Module description is no longer returned by default; a new parameter
selects html, wikitext, or raw Message data.
* The 'examples' result property is now an array rather than a string.
* The 'allexamples' result property has been removed.
* Parameter descriptions are no longer returned by default; a new parameter
selects html, wikitext, or raw Message data. Machine-readable parameter
info remains available.
The impact of these changes on existing bots and scripts is expected to be
minimal, as non-human consumption is likely to be limited to ApiSandbox.
[1]: https://gerrit.wikimedia.org/r/#/c/160798
[2]: https://gerrit.wikimedia.org/r/#/c/161093
[2]: https://gerrit.wikimedia.org/r/#/c/160819
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
Hello everyone,
The prior maintenance release announcement email titled
MediaWiki Security and Maintenance Releases: 1.23.6, 1.22.13 and 1.19.21
included the word "Security" in the subject. This inclusion was a
mistake. There are no security fixes included in these releases.
Best,
Mark A. Hershberger
(Wiki Release Team)
The structured logging implementation that I began work on in February
has been making progress through code review recently following the
completion of Jenkins and Zuul tooling changes which allow the test
infrastructure to cope with the introduction of the mediawiki/vendor
repository. The next patch in the series [0] will require that all
consumers of MediaWiki from the git repository either use Composer
directly or clone the mediawiki/vendor repository to provide the PSR-3
[1] interfaces and abstract classes [2].
For the WMF production cluster, the mediawiki/vendor repository [3] is
being included as a submodule on the wmf/1.25wmfX deployment branches.
This repository is also used on the *.beta.wmflabs.org and with the
Jenkins tests. The MediaWiki-Vagrant project includes Puppet
configuration that automates the installation of \Psr\Log with
Composer as defined in the mediawiki/core/composer.json configuration
file. Developers and other users of MediaWiki via git clone can pick
one installation option or the other as they prefer.
Starting with the 1.25 release cycle (which is several months away)
the tarball release process will need to be updated to either include
the mediawiki/vendor repository or provide the required external
classes via other means.
[0]: https://gerrit.wikimedia.org/r/#/c/119941/
[1]: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-…
[2]: https://github.com/php-fig/log
[3]: https://git.wikimedia.org/summary/mediawiki%2Fvendor
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
I am pleased to announce Marielle Volz joining the Wikimedia
Foundation as a Software Engineer for the Editing team.
Marielle will be working remotely from London, UK. She made her first
website[1] in 1997 with Adobe PageMill 2.0[2], which according to one
review at the time, "has terrific tables by today's standards for an
HTML editor, although they're not bad by any standard."[3]. When her
house finally got the internet in 1999, she first discovered the "view
source" button. It wasn't until 5 years later in 2004 that she
registered her first Wikipedia account, wherein she developed a lovely
addiction to that damnable website.
During a brief period of insanity (i.e. all of her undergraduate and
graduate education) she considered becoming a Scientist, before
realizing it's actually more fun to sit inside on a computer all day
editing Wikipedia articles about Science rather than Doing Science and
actually going outside, which, with the advent of vitamin D
supplementation, is wholly unnecessary, and perhaps one could even
say, *inadvisable*.
Only now, having recently become a member of the 10 year club, has
finally joined two of her passions: "making internet stuff" and
"Wikipedia internet stuff" to work on VisualEditor, an HTML editor. To
that end of continuing to edit articles about Science, and also making
internet stuff, she did the FOSS Outreach Program for Women program
this Summer[4], and started developing a node.js service Citoid[5] to
make it easy to insert citations using a URL/DOI/Title in VE/Wikitext.
She'll be continuing to do that, and maybe other things, but mostly
that, as a contractor starting last month.
Please join me in welcoming Marielle to the Wikimedia Foundation.
--tomasz
[1] http://web.archive.org/web/20030126114223/http://www.tufts.edu/as/engdept/m…
[2] https://en.wikipedia.org/wiki/Adobe_PageMill
[3] http://web.archive.org/web/20080620021417/http://www.soc.org.uk/bulletin/pa…
[4] https://www.mediawiki.org/wiki/User:Mvolz/OPW_proposal_round_8
[5] https://www.mediawiki.org/wiki/Citoid
Hello,
I am currently drafting a short document about what is a Mediawiki
Hackathon. Could you please help me by pinpointing to me some of the
greatest / coolest tools or achievements that were made during previous
Wikimedia Hackathon?
Best regards,
Sylvain.
--
*Sylvain Boissel*
ADMINISTRATEUR SYSTÈME ET RÉSEAUX
*WIKIMÉDIA FRANCE*
*Tél +33 9 80 93 07 54*
*www.wikimedia.fr <http://www.wikimedia.fr/>*
*40 rue de clery, **75002 Paris*
<http://www.openstreetmap.org/node/691082430#map=19/48.86814/2.34683>
*Imaginez un monde où chaque personne sur la planète aurait librement accès
à la totalité du savoir humain. C'est notre engagement. Aidez Wikimedia
France à en faire une réalité <https://dons.wikimedia.fr>.*
tl;dr:
In the xml dumps, I want to change
<text> <sha1> <model> <format>
to
<model> <format> <text> <sha1>
However, this is a breaking change to our XML schema.
See https://bugzilla.wikimedia.org/show_bug.cgi?id=72417
Background:
While trying to fix bug 72361, I ran into an issue with our current XML dump format:
The <model> and <format> tags are placed *after* the <text> tag.
This means that we don't know how to handle the text when we process XML events
in a stream - we'd have to buffer the text, wait until we know model and format,
and then process it. A pain.
The current order has no deeper meaning - it is, indeed, my own fault: i didn't
think this through when adding these tags. I propose to change the order of the
tags now, to make stream processing easier.
That would technically be a breaking change to the dump format, incompatible
with <https://www.mediawiki.org/xml/export-0.8.xsd> and export-0.9.xsd. I doubt
however that any consumers rely on the current placement of <model> and
<format>, as it is extremely inconvenient (compare bug 72361), but you never know.
I propose to release a new XSD version 0.10 with the order changed, and mention
it in the release notes. Should be fine.
Any objections?
-- daniel
Hello everyone,
This is a notice that on Wednesday, October 28, 2014, between
20:00-22:00 UTC, we will release maintenance updates for current and
supported branches of the MediaWiki software. Downloads and patches will
be available at that time.
Best,
Mark. A. Hershberger
(Wiki Release Team)