Hi everyone,
Bryan Tong Minh has been doing some great work on VipsScaler
extension, but there hasn't been a lot of recent chatter on the
mailing list about it. Since we're somewhat close to deploying
something on the cluster, it probably warrants at least an email.
First, some background. Currently, we use ImageMagick for scaling
images on Wikimedia websites. VIPS (http://www.vips.ecs.soton.ac.uk/
) is an alternative image processing system that has a couple
advantages over ImageMagick for our purposes: 1) it's faster, and 2)
it's way more efficient with memory. The latter means that we can
allow for much larger images with VIPS than we can currently allow
using ImageMagick. For example, we currently disallow PNG images
greater than 12.5 MP.
Changing image scalers may introduce bugs, so we're proceeding
cautiously. We have a three step plan:
Step 1: Deploy VipsScaler extension, but only use it for PNGs over
12.5MP and/or TIFFs (which currently generate errors). Let this sit
in production a while, fixing any bugs we find with this
configuration.
Step 2: Deploy a comparison tool (to be written) that allows anyone to
rescale an image with VIPS, and compare it to the ImageMagick version.
Allow more time for testing and fixing.
Step 3: Switch to VIPS for everything
If you're interested in following progress, there's a couple places
you can look:
* VipsScaler tracking bug: https://bugzilla.wikimedia.org/28135
* Follow changes in SVN:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki?path=%2Ftrunk%2Fexten…
Step 1 could go out as early as next week, pending final review of the
extension. If anyone is interested in helping accelerate this, the
comparison tool in step 2 is only just started (it's the
SpecialVipsTest special page code), and Bryan is only working on it
when he has time (which isn't right now).
When we're ready to schedule this, we'll update the calendar here:
https://wikitech.wikimedia.org/view/Software_deployments
Rob
I'm happy to announce the availability of the first beta release of
the new MediaWiki 1.18 release series.
Please try it out and let us know what you think. Don't run it on
any wikis that you really care about, unless you are both very
brave and very confident in your MediaWiki administration skills.
MediaWiki 1.18 is a large release that contains many new
features and bug fixes. This is a summary of the major changes of
interest to users. You can consult the RELEASE-NOTES file for the
full list of changes in this version.
*********************************************************************
What's new?
*********************************************************************
MediaWiki 1.18 brings the usual host of various bugfixes and new
features.
jQuery 1.6.4 is now included as standard, along with numerous
more jQuery plugins
Breaking changes:
* action=watch / action=unwatch now requires a token
As of 1.18 extensions are now being bundled with the releaset tarball.
MediaWiki 1.18 bundles:
* ConfirmEdit
* Gadgets
* Nuke
* ParserFunctions
* Renameuser
* Vector
* WikiEditor
$wgEnableDublinCoreRdf and $wgEnableCreativeCommonsRdf no longer
work in core, and the functionality has been moved to the relevant
extensions.
See http://www.mediawiki.org/wiki/Extension:DublinCoreRdf and
http://www.mediawiki.org/wiki/Extension:CreativeCoreRdf as appropriate
Math
- ----
$wgUseTeX has been superseded by the Math extension. To re-enable
math conversion after upgrading, obtain the Math extension from SVN or from
http://www.mediawiki.org/wiki/Extension:Math and add to LocalSettings.php:
require_once "$IP/extensions/Math/Math.php";
Language support
- ----------------
As with every release, MediaWiki 1.18 brings improved support for
languages in MediaWiki, with improved translation and features for
the many supported languages.
New languages:
* Angika (anp)
* Brahui (brh)
* Central Dusun (dtp)
* Jamaican Creole English (jam)
* Khowar (khw)
* Liv (liv)
* Kichwa (qug)
API
- ---
API bug fixes and new features have been added to 1.18, providing
more options for input and output.
* API modules were added to access QueryPage based special
pages, to Compare pages, Revert files, and to be able to access
other special pages such as Special:UnwatchedPages,
Special:MimeSearch and Special:ActiveUsers
* The output of the generated help page has been improved
The API contains a breaking changes against previous releases:
* action=watch now requires POST and token.
Release notes
- -------------
Complete release notes are at
http://www.mediawiki.org/wiki/Release_notes/1.18
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0beta1.tar.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.0beta1.tar.gz.si
g
Public keys:
https://secure.wikimedia.org/keys.html
For the coding challenge, I wanted to have something very concise to
teach people who aren't necessarily new to JS, but who are new to
MediaWiki, about user scripts & gadgets. I took a stab at it here:
http://www.mediawiki.org/wiki/Gadget_kitchen
Would appreciate help, esp. in terms of making my tutorial script
nicer or fixing any mistakes/bad practices. If this looks like it
could become a useful central page, perhaps others would be interested
in writing tutorial scripts demonstrating more advanced concepts both
of MediaWiki / the API, as well as JavaScript development in general?
I think having really good introductory docs and tutorials on
MediaWiki.org will become ever-more important as we expand what the
gadgets framework can do (RL2 and beyond), so any help & feedback is
appreciated :)
Cheers,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Does anybody else feel a pang of spite in
"There will be no other notifications in case of further changes unless you visit this page."
especially when other software doesn't force the user to "prove his
loyalty" each time like something from
* Your World As I See It - Guilt
http://www.youtube.com/watch?v=qhwKqq0j1S8&list=PL6E40919035151385
Why can't he be given a choice between "subscriptions that keep dying"
and "subscriptions that act like ones everybody else is used to"?
I'm talking about official MediaWiki software decisions, please don't
mention 'you can just install an extension'.
And OK maybe if one is worried about too many dead
accounts there could also be 'renew once per 365 etc. days' features --
that users could also pick from too...
r88077 [1] added a default XML namespace (xmlns attribute on the root node)
for the API's XML output.
In r99135 [2] this was partially backed out to avoid clobbering some
modules that specified their own XML namespaces in output, such as RSD
discovery info. With this change a query parameter needed to be added to
include the namespace, but it would still clobber if you used it on
affected modules.
In r101912 [3] I took the parameter out, returning almost to r88077's
behavior -- but swapping the order of things so an xmlns contained in the
output data will take precedence, avoiding the clobbering.
However I do want to confirm that this is an OK thing to do; as noted in a
CR comment on [1] this may actually break XPath queries assuming the
non-namespaced data. If there is a compat issue, we need to make sure it's
documented and communicated...
[1] <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/88007>
[2] <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/99135>
[3] <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/101912>
-- brion
The last weekend of the October 2011 Code Challenge is upon us. It's going
to be a big weekend for those coders who want to do well, and we're
encouraging them to visit wikitech-l and the #mediawiki IRC channel, so
please take a special interest in helping this weekend.
Many of these questions may be from very novice developers, but we want to
give all of them the best chance to succeed. It may be impractical to
answer every question that comes in, but it would be a great help if you
can at least point them to the right documentation, and do your best to
answer any substantive questions that they may have.
Thanks in advance for any help you can provide this weekend.
--g
What: 1.18 tarball Triage
When: Friday, November 4, 2011, 21:00UTC (17:00PDT)
Where: #wikimedia-dev on irc.freenode.net
See also: http://www.mediawiki.org/wiki/Bug_management/Triage
Since we plan on having a beta tarball out for 1.18 tomorrow (Thursday),
I am holding a triage for any 1.18 issues that people discover on
Friday. I'd like to use the triage to hand out work to anyone who wants
to help us make the 1.18 release of MediaWiki happen faster.
Thanks,
Mark.
Per https://bugzilla.wikimedia.org/show_bug.cgi?id=32183 ...
In r101860 I've removed most of the client-* classes from the <html> that
were added based on user-agent sniffing. Sniffing UA strings is a fragile
practice which should be strongly discouraged in favor of checking for the
actual features or bugs that you need to address -- encouraging people to
use styles like "client-firefox7" makes me feel a little ill inside. :)
The client-js / client-nojs classes remain; they are in fact a good example
of use of feature detection (whether JS is enabled or not) which allows
targeting display of UI elements specifically at that condition.
No extensions in SVN or core code appears to be using any of the other
client-* classes; there could be some in user JS/CSS code -- if you've been
using them or seen someone use them, you should see about fixing them up to
make sure they don't break in unexpected browsers or on MediaWiki 1.19.
-- brion