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
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.
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
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
(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.
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
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
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
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