-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is a security and bugfix release of MediaWiki 1.15.2.
Two security issues were discovered:
A CSS validation issue was discovered which allows editors to display
external images in wiki pages. This is a privacy concern on public
wikis, since a malicious user may link to an image on a server they
control, which would allow that attacker to gather IP addresses and
other information from users of the public wiki. All sites running
publicly-editable MediaWiki installations are advised to upgrade. All
versions of MediaWiki (prior to this one) are affected.
A data leakage vulnerability was discovered in thumb.php which affects
wikis which restrict access to private files using img_auth.php, or
some similar scheme. All versions of MediaWiki since 1.5 are affected.
Deleting thumb.php is a suitable workaround for private wikis which do
not use $wgThumbnailScriptPath or $wgLocalRepo['thumbScriptUrl'].
Alternatively, you can upgrade to MediaWiki 1.15.2 or backport the
patch below to whatever version of MediaWiki you are using.
MediaWiki is not compatible with PHP 5.3.1 due to a bug in that
release, which is fixed in PHP 5.3.2. This release of MediaWiki will
refuse to upgrade if an affected version of PHP is present. Note that
local or distribution-specific backports of the PHP bug fix are
supported. See http://bugs.php.net/50394 for details.
Full release notes:
http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_15_2/phase3/RELEASE-NO…
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.2.tar.gz
Patch to previous version (1.15.1), without interface text:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.2.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-i18n-1.15.2.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.2.tar.gz.sighttp://download.wikimedia.org/mediawiki/1.15/mediawiki-1.15.2.patch.gz.sighttp://download.wikimedia.org/mediawiki/1.15/mediawiki-i18n-1.15.2.patch.gz…
Public keys:
https://secure.wikimedia.org/keys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkuVjQcACgkQgkA+Wfn4zXkYqACfRXMeQdbHT2ep+xEbkgPpz+BA
5pgAoMhuJQ6UJrW8Wdh/Ji9VA/h8MRH0
=CDe6
-----END PGP SIGNATURE-----
I'm in somewhat of a unique position to comment on this, since I both do
MediaWiki extension development, and run a MediaWiki consulting company
(shameless plug: wikiworks.com) - so I personally have a financial interest
in making MediaWiki more popular and more easy-to-use. I also tend to hear a
lot about the specific frustrations people have with MediaWiki, which has
led to my development of certain extensions, like Admin Links, which defines
a page meant to serve as a "control panel" for administrators:
http://www.mediawiki.org/wiki/Extension:Admin_Links
Troll-like as the original email was, :) it brought up some fairly common
complaints. The basic answer to these is that they are, in fact, being
addressed: as a few people noted, the usability initiative has already
created a much nicer skin, Vector; and a planned project for the upcoming
Google Summer of Code is to provide a way to install and manage extensions
via the web browser, the way WordPress does it. A few extensions, like
Configure, also allow for a web-based substitute for editing
LocalSettings.php, though they could stand some improvement.
Finally, on the more general subject of Wikimedia's relationship to
MediaWiki: I do think it would be nice if Wikimedia, and outside MediaWiki
developers, were more aware of, and more positive about, MediaWiki's
popularity in the outside world. It's used very heavily as an enterprise
wiki around the world, and I think for good reason: it's robust, stable,
very feature-rich, heavily translated, and when used with the set of
extensions around Semantic MediaWiki I think it's in a class of its own. I
just think a better answer when people ask about problems with MediaWiki is
to say "I don't know", or "I think someone's working on that", rather than
"MediaWiki is intended for use by Wikimedia projects, and if you have a
problem using it, you should switch to another wiki application." First, for
many uses there is no better wiki software, especially not for the cost; and
second, there are a lot of people, especially among extension developers but
also in general, who are trying to improve MediaWiki as a
corporate/organizational application. I just think it would be nice if more
people celebrated MediaWiki's popularity, instead of ignoring or trying to
discourage it. :)
-Yaron
Wikimedia Germany invites all MediaWiki developers, Toolserver users, Gadget
hackers, and other people interested in the technical side of Wikimedia projects
to come to the Developers' Workshop in Berlin on April 14.-16. We have a very
nice venue and a cool option for accommodation, details to be announced soon.
Registration is now open at <http://www.amiando.com/WMCON10DEV.html>.
Registration is *required* and will be open until March 21., but there are only
50 places available. So, sign up soon!
For updates and more information, watch
<http://meta.wikimedia.org/wiki/Wikimedia_Conference_2010/Developers%27_Work…>.
If you have questions, please contact us at <conference(a)wikimedia.de>.
-- Daniel Kinzler
Hi,
Tomasz you rock, I hope the dump works, the pages-meta-history.xml.bz2 file should be about 344.3GB I think.
I have copies of some older english pages-meta-history.xml.7z files, I downloaded the 2006 one from download.wikimedia.org in 2006, and the 2007 and 2008 from a mirror recently. If these are not failed dumps they should be at the wikimedia foundation so I will send them in the mail, either a 2.5" harddrive or DVD's.
20060816-pages-meta-history.xml.7z (5.08GB) 782GB uncompressed
20070402-pages-meta-history.xml.7z (11.3GB) 1.76TB uncompressed
20080103-pages-meta-history.xml.7z (17.2GB) 2.8TB uncompressed
cheers,
Jamie
Date: Wed, 03 Mar 2010 15:55:39 -0800
From: Tomasz Finc <tfinc(a)wikimedia.org>
Subject: Re: [Wikitech-l] enwiki complete page edit history
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Message-ID: <4B8EF6FB.6030607(a)wikimedia.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
The last successful was way before 2009 and sadly doesn't exist on the
wikimedia servers.
Trust me .. as soon as this runs is done were going to stamp it, copy
it, put it into a safe, and mirror it everywhere.
We're not going to let that file get away.
--tomasz
Jamie Morken wrote:
> This is a repost, Tomasz please get back to me about this.
>
> cheers,
> Jamie
>
>
>> Date: Fri, 19 Feb 2010 18:25:50 +0100
>> From: Tomasz Finc <tfinc(a)wikimedia.org>
>> Subject: Re: [Wikitech-l] enwiki complete page edit history
>
>> Do you mean that the failed runs aren't web linked? If so then
>> I'd
>> rather not point people to corrupted files.
>
> Hi Tomasz,
>
> I
> don't think there are any (failed or successful) weblinked
> "pages-meta-history.xml.bz2" or "pages-meta-history.xml.7z" files for
> the enwiki on the wikimedia download server. I think there must be a
> successful enwiki "pages-meta-history" from 2009 floating around
> somewhere, I think that the last successful dump (guessing Sept 2009?)
> should always be linked for download. If you have a copy of the latest
> successful build of "pages-meta-history" (.bz2 or .7z) for enwiki I'd
> appreciate it if you posted a link, thanks
>
> cheers,
> Jamie
>
Thanks for the reply, and I stand corrected on MW's ability to merge
versions. However:
> Date: Fri, 5 Mar 2010 00:03:13 +0100
> From: Roan Kattouw <roan.kattouw(a)gmail.com>
> Subject: Re: [Wikitech-l] External editor with merge capability?
>
> To decide whether you've "seen" a certain change, MediaWiki uses the
> time at which you loaded the edit form: any edits made before this
> time will appear in the edit box, and any made after will be
> considered for potential conflicts. However, in certain cases (like
> restoring your browser session when you restart your browser), your
> browser may reload the edit page but substitute the old content
> (containing your work in progress) in the edit box. MediaWiki doesn't
> know about this, so it records the so-called starttimestamp "wrongly".
Right, this was also my understanding of how it worked internally, the
question is how to work around this? Eg. the API offers "basetimestamp"
and "starttimestamp" fields that can be sent along with the edit
submission, but is there any way to send these or otherwise specify the
last revision with a direct submit POST to MediaWiki?
Cheers,
-j.
Hi
I've been asked to create a template where there is a table where editors
can just input the information. For example
Location
Captial city
Head of state
I know how to include tables but i'm not sure how to include them in the
template.
Thanks Mak.
Greetings,
There are a whole bunch of external editors for Mediawiki, but are any of
them capable of merging/diffing changes instead of simply overwriting *if*
the session is closed in the meantime? That is, if:
1) I open an article externally (v1)
2) Somebody else changes the article (v2a)
3) I save the article back to the Wiki (v2b)
Ideal behavior would be that, assuming no conflicts, v2a and v2b are
silently merged into a new version 3. MediaWiki does not appear to
support this -- by design?
Acceptable behavior would be that I am warned of the difference between
v2a and v2b and allowed to manually resolve them. This works _if_ my
original MediaWiki edit session is still open, but if I have closed and
reopened it (or simply gone away for long enough for the session to end,
so I need to reload the edit page), MW considers v2b newer than v2a and
simply silently overwrites it.
Any ideas for how to fix and/or work around this?
Cheers,
-jani
I hope I am emailing this to the right group. My concern was about mediawiki and it's limitations, as well as it's outdated methods. As someone wo runs a wiki, I've gone through a lot of frustrations.
If Wordpress is like Windows 7, then Mediawiki is Windows 2000. Very outdated GUI, outdated ways of doing things,for example using ftp to edit the settings of the wiki instead of having a direct interface like Wordpress. Mediawiki makes millions more than Wordpress does too, why can't the money be put into making a modern product instead of in pockets of the people who run it? I know Wordpress and Mediawiki serve two different purposes, but that's not the point. The point is, one is modern and user friendly (Wordpress), and the other (Mediawiki) is not. Other complaints:
-Default skins are boring
-Very limited in being able to make the wiki look nice like you could with a normal webpage.
-A major pain to update! Wordpress upgrades are so simple.
-Better customization so people can get a wiki the way they want. It should be more like the wikis on wikia, except without me having to learn css and php to make those types of customizations. Give me some option, some places to put widgets. Not every wiki is going to be as formal as the ones on wikimedia sites. And don't the people at Wikimedia commons get tired of always having to make changes so it actually suits their site? If they had some of the options from the get go, i'm sure they'd appreciate it too.
-I don't want to go to my ftp to download my local settings file, add a few lines then reupload it. This is caveman-like behavior for the modern internet.
-Being able to manage extensions like wordpress does.
In short, it's time to spend some money from those millions of dollars from donations to make this software more modern. Being stubborn in modernizing it will only make this software less relevant in the future if other wiki software companies are willing to do things the people at Wikimedia aren't.
Thank you
This is a repost, Tomasz please get back to me about this.
cheers,
Jamie
> Date: Fri, 19 Feb 2010 18:25:50 +0100
> From: Tomasz Finc <tfinc(a)wikimedia.org>
> Subject: Re: [Wikitech-l] enwiki complete page edit history
> Do you mean that the failed runs aren't web linked? If so then
> I'd
> rather not point people to corrupted files.
Hi Tomasz,
I
don't think there are any (failed or successful) weblinked
"pages-meta-history.xml.bz2" or "pages-meta-history.xml.7z" files for
the enwiki on the wikimedia download server. I think there must be a
successful enwiki "pages-meta-history" from 2009 floating around
somewhere, I think that the last successful dump (guessing Sept 2009?)
should always be linked for download. If you have a copy of the latest
successful build of "pages-meta-history" (.bz2 or .7z) for enwiki I'd
appreciate it if you posted a link, thanks
cheers,
Jamie