MediaWiki-l March 2011

mediawiki-l@lists.wikimedia.org

86 participants
70 discussions

multiple contact emails with Extension:ConfirmAccount?
by Matthew Betts 21 Mar '11

21 Mar '11

Hi, Does any know if it's possible to have multiple contacts for the ConfirmAccount extension please, to notify several people when an account request is pending review? I tried two ways to give two addresses to $wgConfirmAccountContact, once comma-separated and the second time space-separated, and neither worked. Thanks, Matthew -- Matthew Betts PhD, Russell Group CellNetworks, BioQuant, University of Heidelberg Im Neuenheimer Feld 267, 69120 Heidelberg, Germany mailto:matthew.betts@bioquant.uni-heidelberg.de phone:+49 6221 54 513 61

2 1

maintaining extensions code
by Paul Newby 21 Mar '11

21 Mar '11

Hi folks, I'm relatively new to mediawiki, and I'm wondering about best practices for maintaining extension code updates. Is there a way to maintain extensions vis a cvs server, as there is with Drupal modules? Also, is there a searchable archive of this list anywhere? Thanks, Paul N.

6 10

Content-encoding header value error
by Dan Nessett 18 Mar '11

18 Mar '11

Our site uses the ConfirmAccount extension, which allows registration requests to include a CV (supplying one is a pre-requisite for becoming an editor on our site - normal users are registered as authors). I have identified a problem - the response to the download request for the CV contains a content-encoding header value of ", gzip". This befuddles some browsers, such as FF, IE and Safari and they fail to decompress the file. My guess is this is an apache configuration problem or an apache bug, but on the off-chance my guess is wrong and it has something to do with MW configuration, I thought I would bring the issue up here. If this is not an MW problem, then confirmation of that will narrow down the search space for a solution. Here is the request and response headers (I have obscured some file and cookie information using ellipses to ensure privacy - the output is from HTTPFox running on Firefox): (Request-Line) GET /wiki?title=Special:ConfirmAccounts/ editors&file=to...v.pdf HTTP/1.1 Host en.citizendium.org User-Agent Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language en-us,en;q=0.5 Accept-Encoding gzip,deflate Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive 115 Connection keep-alive Referer http://en.citizendium.org/wiki?title=Special:ConfirmAccounts/ editors&acrid=... Cookie __utma=184949757.... (Status-Line) HTTP/1.0 200 OK Date Wed, 09 Mar 2011 01:27:46 GMT Server Apache/2.2.3 (CentOS) X-Powered-By PHP/5.3.5 Expires Thu, 01 Jan 1970 00:00:00 GMT Cache-Control no-cache, no-store, max-age=0, must-revalidate Pragma no-cache Content-Disposition inline;filename*=utf-8'en'to...v.pdf Last-Modified Tue, 08 Feb 2011 05:25:51 GMT Content-Encoding , gzip Vary Accept-Encoding Content-Length 48636 Content-Type application/pdf X-Cache MISS from aristotle.citizendium.org X-Cache-Lookup MISS from aristotle.citizendium.org:80 Via 1.0 aristotle.citizendium.org:80 (squid/2.6.STABLE21) Connection keep-alive Note that the Accept-Encoding header in the request specifies "gzip, deflate", while the Content-Encoding value in the response is ", gzip". I have posted a query about the problem on http://groups.google.com/group/ comp.infosystems.www.servers.unix, but have not received a response. (I posted the query over two weeks ago). This problem occurs on both our live wiki, which runs on 1.13.2 as well as our test wiki, which runs on 1.16.2. The apache version is 2.2.3. -- -- Dan Nessett

4 6

Re: [Mediawiki-l] spam attack avoids captcha
by Kay Diederichs 18 Mar '11

18 Mar '11

Am 17.03.2011 22:06, schrieb Platonides: > Daniel Friesen wrote: >> The spammers haven't coded the bots to handle QuestyCaptcha yet, but if >> people start using it to stop them, then they will code it into the bot. > > Questy captcha is a free form question. You can't learn how to bypass > any instance of it. Not even a human would be able to bypass it using > just generic knowledge (eg. a foreign speaker). > The most that bots could do is to try with common answers such as a the > wiki name, or domain. No bot would be able to solve all by itself "Who > is the current companion of Doctor Who?"* > OTOH it's highly annoying for those users which don't know about Doctor > Who, or that for some reason get their answer rejected. I was once > denied access by one captcha of that kind (naming the character of the > image) despite having found the correct answer, I don't remember exactly > what was the issue. So you may also want to provide some email address > for appealing. > > > *Once a human instructs it, they are able to use it multiple times at > that wiki, though. In Germany, there's a fairy tale about a race between a hare and a hedgehog; I just tried to translate it and found "hare and tortoise" (<http://www.dltk-teach.com/fables/tortoise/tale.htm>) We are the hare, but the hedgehog/tortoise is faster, it seems. The only way out that I can think of is for us, to find those measures that are easy to implement, and that raise the hurdle for the spammer such that the programming effort deters them. One way that I've been thinking of is to just block the outgoing emails to addresses like shown by "grep gmail /var/log/maillog|grep to=", namely fro.stc.h.r.i.st.i.an80(a)gmail.com, e.u.g.eni.o.s.c.hmidt.1.0(a)gmail.com, c.r.o.s.b.y.d.o.k.eocet.ua.n(a)gmail.com and so on. So, a simple way is to use a one-liner for the sendmail and postfix configuration files, which would ideally only affect *.*.*.*.*(a)gmail.com addresses. I found that To:gmail.com REJECT (with one or multiple tabs where the blank appears in the line above) seems to work well when appended to /etc/mail/access which is used by sendmail on my CentOS-5.5 machine. Nota bene: only wikis are on this machine, so it's ok to not confirm account creation to gmail users - they can be told to subscribe with different emails. I have not yet been able to find out why on my SL-6 machines gmail.com REJECT as the last line /etc/postfix/access does not seem to work - at least I see no "reject" message in /var/log/maillog. thanks, Kay

2 1

the media wiki error on install?
by Edward Smith 17 Mar '11

17 Mar '11

(Sry for the spam if you received it, I sent 2 times prior but was not registered, this time I am registered.) the media wiki error on install?hello, I know what causes the error, however I do not know where or how to fix it, I tried to install media wiki and on the "DB Username" my database is several characters long, so the username + database it tells me it is too long, is there a way or script to edit somewhere to make it read more characters in the install? or how would I fix the characters too long as I am unable to make the database username any smaller. thanks and have a good day.

2 2

Maps compatibility note
by Jeroen De Dauw 16 Mar '11

16 Mar '11

Hey all, A quick warning for people using the Maps [0] (and Semantic Maps [1]) extension from svn: the code on trunk has just became dependent on MediaWiki 1.17 or above. If you are running an older version of MediaWiki and want to continue update (Semantic) Maps 0.7.x from svn, "svn switch" to these branches: * Maps: http://svn.wikimedia.org/svnroot/mediawiki/branches/Maps0.7.x/ * Semantic Maps: http://svn.wikimedia.org/svnroot/mediawiki/branches/SemanticMaps0.7.x/ [0] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:Maps [1] https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Extension:Semantic_Ma… Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

1 0

questyCaptcha errors
by Bill Traynor 16 Mar '11

16 Mar '11

I switched to questyCaptcha and am now seeing errors such as: Catchable fatal error: Object of class WebRequest could not be converted to string in/var/www/elinux.org/extensions/ConfirmEdit/QuestyCaptcha.class.php on line 14 Here's the function causing this: function keyMatch( $answer, $info ) { return strtolower( $answer ) == strtolower( $info['answer'] ); } Has anyone else seen errors with questyCaptcha? What would cause the conversion error in this case? Thanks Bill

5 7

JavaScript snippet to unhide parser information
by Marcin Cieslak 15 Mar '11

15 Mar '11

Just in case somebody wants to see it all the time: $('#bodyContent').contents().filter(function() { if (this.nodeType == 8) { return (this.data.indexOf("Saved") > 0 || this.data.indexOf("NewPP") > 0); } else return false; }).replaceWith(function() { return "<pre>" + this.data + "</pre>"; }); https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Snippets/Parser_infor… //Marcin

1 0

Disabling the parser cache... for real
by Daniel Barrett 15 Mar '11

15 Mar '11

I have a parser tag <foo> that disables the parser cache in its callback function, like this: static function myParserTagCallback(&$parser) { ... $parser->disableCache(); ... } However, sometimes the pages using this tag get cached anyway. Should I also need to call $wgParser->disableCache() for the global parser object? DanB

2 1

Control of editions
by Juan Jesús Cremades Monserrat 15 Mar '11

15 Mar '11

Hi, I has isntalled a new mediawiki portal, but the final user wants, for all colaborations, to confirm before the final publications. In other words, if a authenticated user edits some article, before the new changes appear as public, he wants to revise and confirm the edition. Is it possible? Thanks

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

MediaWiki-l March 2011