All,
Thanks to a few informal code reviews, version 2.1.0 of the Memento time travel Extension for MediaWiki has been released. The extension can be downloaded via [1]. Information on the extension is available at [2]. A demonstration wiki equipped with the extension is available at [3].
This release incorporates changes to enrich the code based on additional review and feedback from members of the WikiMedia team. The extension fixed a few bugs, now supports the newer JSON-based i18n system, and has removed three configuration options in order to streamline the code.
We fully appreciate the feedback we’ve received and appreciate any additional feedback the community can provide. Our goal is to make the extension as solid as possible for MediaWiki users everywhere.
The extension works with Memento clients [4]. Memento clients allow one to select a past date and time to browse, and then browse the web as if it were that date and time. Installing this extension in a MediaWiki installation allows Memento clients to seamlessly transition from using web archives to wikis, allowing one to view the past versions of web pages without interruption. This has numerous applications, from avoiding spoilers [5] to studying the evolution of legal discourse.
Additionally, this extension attempts to address the issue of "temporal coherence", ensuring that old revisions of images and templates match the revision of the page they are embedded in. This functionality is still optional and experimental, but has received some interest from the community.
Earlier this summer, we presented our experiences with reconstructing the past using MediaWiki [6, 7], and demonstrated using the extension to avoid spoilers in Game of Thrones [8, 9, 10] at WikiConference USA 2014.
The extension is fully compliant with RFC 7089 [11], which specifies the Memento protocol. The effort was supported in part by the Andrew W. Mellon Foundation and is a joint effort between Old Dominion University and Los Alamos National Laboratory. Videos [12] and [13] show Memento at work in the web at large, the latter paying attention to navigation within Wikipedia.
The Memento protocol is currently used by major web archives [14] and supported by the International Internet Presevation Consortium [15]. Though we have the support of web archives, the Memento team also considers time travel in MediaWiki to be a major use of the protocol.
We really appreciate the feedback from the Wikimedia team and look forward to additional assistance and improvements.
Thank you again, on behalf of the Memento Team,
Shawn M. Jones
Graduate Research Assistant
Department of Computer Science
Old Dominion University
Email: sjone(a)cs.odu.edu<mailto:sjone@cs.odu.edu>
Research group: http://ws-dl.blogspot.com
Twitter: @shawnmjones
—
[1] https://github.com/mementoweb/mediawiki/releases/tag/v2.1.0
[2] https://www.mediawiki.org/wiki/Extension:Memento
[3] http://ws-dl-05.cs.odu.edu/demo/
[4] http://bit.ly/memento-for-chrome
[5] http://ws-dl.blogspot.com/2013/12/2013-12-18-avoiding-spoilers-with.html
[6] http://wikiconferenceusa.org/wiki/Submissions:Reconstructing_the_past_with_…
[7] http://www.slideshare.net/shawnmjones/reconstructing-the-past-with-media-wi…
[8] http://wikiconferenceusa.org/wiki/Submissions:Using_the_Memento_Mediawiki_E…
[9] http://www.slideshare.net/shawnmjones/using-the-memento-mediawiki-extension…
[10] https://www.youtube.com/watch?v=ciClYjTnscs
[11] http://tools.ietf.org/html/rfc7089
[12] http://www.youtube.com/watch?v=0_70lQPOOIg
[13] http://www.youtube.com/watch?v=WtZHKeFwjzk
[14] http://mementoweb.org/depot/
[15] http://netpreserve.org
Suis désolé de vous interrompu pour cette message et le requis si c'est possible d'annuler les mes demande.
Envoyé depuis mon HTC
----- Reply message -----
De : mediawiki-l-request(a)lists.wikimedia.org
Pour : <mediawiki-l(a)lists.wikimedia.org>
Objet : MediaWiki-l Digest, Vol 132, Issue20
Date : mar., sept. 23, 2014 2:00 PM
Send MediaWiki-l mailing list submissions to
mediawiki-l(a)lists.wikimedia.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
or, via email, send a message with subject or body 'help' to
mediawiki-l-request(a)lists.wikimedia.org
You can reach the person managing the list at
mediawiki-l-owner(a)lists.wikimedia.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MediaWiki-l digest..."
Today's Topics:
1. Re: Archiving articles to another Wiki based on category or
template (Mlpearc)
----------------------------------------------------------------------
Message: 1
Date: Mon, 22 Sep 2014 09:41:53 -0700
From: Mlpearc <mlpearc(a)everythingfoodanddrink.org>
To: MediaWiki announcements and site admin list
<mediawiki-l(a)lists.wikimedia.org>
Subject: Re: [MediaWiki-l] Archiving articles to another Wiki based on
category or template
Message-ID:
<CAGhpzwOAwEROaV2ZxS=5kY3Xp9Z_dG_6HSDMCPST0UU=4ieYkQ(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
You can simply Import the category
<https://www.mediawiki.org/wiki/Manual:Importing_XML_dumps> to a different
wiki.
*Mlpearc*
Founder
Everything Food & Drink.orgeverythingfoodanddrink.org
<http://www.everythingfoodanddrink.org/w/index.php/Main_Page>
On Mon, Sep 22, 2014 at 4:24 AM, Henrik Rasmussen <her(a)adm.ku.dk> wrote:
> Instead of deleting Wiki articles which are not valid any longer, but are
> kept for historical reasons, I want to move those articles away from the
> current Wiki. Historical articles could contain [[category:histocal]] and
> I imagine that those articles could be moved automatically to another Wiki,
> based on this category, (or alternatively to another namespace, but this
> would not be read-only).
>
> How do I accomplish this?
>
> I am currently running Mediawiki version 1.20.4
>
> Henrik Rasmussen
> _______________________________________________
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
------------------------------
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
End of MediaWiki-l Digest, Vol 132, Issue 20
********************************************
Hello Folks,
I got a private Mediawiki 1.4 from 2005 which still runs on a Debian 5 machine.
I'm about to virtualize this because of various reasons but the first problem I ran into just after trying to move it to a clean Wheezy install is that it's incompatible with:
ii php5 5.4.4-14+deb7u14 all server-side, HTML-embedded scripting language (metapackage)
Of course the solution what I found online was to upgrade your mediawiki because it have so many advantages blahblah. Really? New features I do not need, and although I went through with the upgrade it become 20xtimes slower + I lost the custom skin I had. This all seems disadvantages to me.
So correct me if I'm wrong but by just doing some research this version with (1-2 extensions like poem) has no know serious security vulnerability (RFI).
What I don't want to do is to install another outdated debian just because of this, I rather downgrade the php version to (5.2). Can anyone come up with any advantage of upgrading Mediawiki from 1.4 to 1.23?
Question2: Storage Engine
=========================
Since this is a small (~3000 pages) private wiki which doesn't get a lot of articles added every day, mostly just used for searching and reading articles which storage engine is the faster MyISAM or Innodb? I do not care about reliability, only speed since the db is backed up every day and as I said it's rarely gets new content.
Thanks!
TL;DR:
* Several deprecated methods in MediaWiki's JavaScript modules will be removed
in a few weeks' time.
* Ensure your code no longer uses these methods and update it if needed.
* Check and fix any gadgets or scripts you or your wikis rely upon.
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 be
synchronous 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 which will automatically
load a polyfill in older browsers.
## Timeline
These removals will land in MediaWiki 1.25alpha in early October 2014, and
deployed to Wikimedia wikis the week after from October 4th onwards (1.25wmf2).
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 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
-- Krinkle
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/
Installed MediaWiki (git master) with Oracle 11 as the database. Post
installation, the MainPage does not display but shows instead:
Warning: oci_parse() expects parameter 1 to be resource, boolean given
in ...MediaWiki/includes/db/DatabaseOracle.php on line 1266 Warning:
oci_error() expects parameter 1 to be resource, null given in
...MediaWiki/includes/db/DatabaseOracle.php on line 1271
Now, I assume I can ignore these warnings, so I attempted to run
../maintenance/update.php --quick and received:
MediaWiki 1.24alpha Updater
PHP Fatal error: Call to undefined function oci_error() in
...MediaWiki/includes/db/DatabaseOracle.php on line 522
Fatal error: Call to undefined function oci_error() in
...MediaWiki/includes/db/DatabaseOracle.php on line 522
The code at line 522 is:
function lastError() {
if ( $this->mConn === false ) {
$e = oci_error();
} else {
$e = oci_error( $this->mConn );
}
return $e['message'];
}
Why isn't oci_error() defined if oci8 is installed?
Hello everyone, esp. MediaWiki Cooperation members,
I set up a Doodle in order to find a time and date for our next online meeting:
http://doodle.com/pk63uwe492yqzqtg#table
If you want to join, please add your preference.
Best,
Markus
A while back I threw out a question about automatically renaming a file on
upload, but no one had an answer so I thought I would try a different
avenue.
Does anyone know away that all file uploads could be automatically
protected upon upload? So if someone tried to upload a photo with name
already used they couldn't overwrite it?
Thanks
I have built a rather large site & for some reaso when I issue a call to
the mediawiki server that is configured as below:
{{PW:Reference desk/Archives/Answered questions}}<p> </p>
The server searces for the page; Template:PW:Reference
desk/Archives/Answered questions
rather than the page PW:Reference desk/Archives/Answered questions;
On Wikipedia the server selects the "page" not a "Template:" using
exactly the same coding for the call.
Any ideas on how to clear this up.
Thanks!
John
I have the following in my LocalSettings.php file:
// define namespace constants
define("NS_Portal", 100); // This MUST be even.
define("NS_Portal_TALK", 101); // This MUST be the following odd integer.
// add namespaces
$wgExtraNamespaces[NS_Portal] = "Portal";
$wgExtraNamespaces[NS_Portal_TALK] = "Portal_talk";
However tihis is not creating the "Portal" custom NameSpace. I've likely
got this wrong somehow, but don't know what.
Any tips.
Thanks!
john
Hi
Today I had to change my wiki over to only allowing edit post email
confirmation and in the process I noticed the email says "Mediawiki Mail".
I'm looking for the quickest way to change the email over to saying my site
name, not the software. Thanks
ps. -- Just for general info someone has cracked the dynamic questions for
ConfirmEdit extension published here:
http://thingelstad.com/stopping-mediawiki-spam-with-dynamic-questy-captchas/
I've used the questions for months and had the joy of zero spam, but
unfortunately the system has been cracked. I'm throwing it out there in
case someone had became like me and stopped checking for spam on a regular
basis. It makes for a very, very unhappy day when you find on the order of
1000 spam accounts.