gmane.org.wikimedia.mediawiki

Re: Wiki spam. Stronger fightback.

Richard — 2013-05-23T19:13:37

In article <op.wxido1sjdykrql< at >daniels-macbook-air.local>,
    "Daniel Friesen" <daniel< at >nadir-seen-fire.com> writes:


OK, now that you've told me what it's not, would you mind telling me
what is standard practice?

The main reason that I haven't opened my wiki up to broader open
registration and editing is exactly because I don't want my wiki
overrun with spam.

Re: Wiki spam. Stronger fightback.

Tim Starling — 2013-05-23T14:43:12

I don't think that would be effective.


Feel free to try.


You can go to jail for that, in a lot of places. Even if they DDoS'd
you first, and you DDoS'd them back, you'd be more likely to go to
jail than them, because being an amateur, you'd be more likely to slip
up in some traceable way.

I think the only effective way to deal with wiki spam would be to
reduce the profit margin. That means either making it more expensive,
say with technical anti-spam tools, or making the revenue smaller, by
getting their sites delisted from Google, and by finding legal ways to
reduce direct revenue sources like pay-per-click search engine
affiliate schemes.

From the experience with email spam, we can expect that if some
organisation became successful in this goal of reducing the
effectiveness of wiki and blog spam, that organisation would come
under attack, by DDoS and other means. So it's not a task for the
faint-hearted.

Re: Wiki spam. Stronger fightback.

Stip — 2013-05-23T13:42:42

Am 22.05.2013 19:07, schrieb halz:
Im using ConfirmEdit with QuestyCaptcha to restrict account-creation, 
and AbuseFilter to filter anonymous edits. Works for me, we had about 2 
Spam-Edits since I configured AbuseFilter (more than a year ago).
I wouldnt recommend trying to out-spam the spammers. Chances are that 
they are better at this.
You can try. Wouldnt count on it though.
Please dont do that. All thats gonna accomplish is that the videos will 
rise in the search rankings (yes, even the downrating does that).

Greetings
Stip

_______________________________________________
MediaWiki-l mailing list
MediaWiki-l< at >lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: Wiki spam. Stronger fightback.

Daniel Friesen — 2013-05-22T23:18:27


No it's not.

Fwd: [QA] First post (almost)

Quim Gil — 2013-05-22T22:35:54

Hi, we have now a mailing list dedicated to software quality assurance:

https://lists.wikimedia.org/mailman/listinfo/qa
http://lists.wikimedia.org/pipermail/qa/

Testing is a good activity for new contributors, improving the quality 
of the software used by MediaWiki sysadmins and users. No prior 
experience in testing / QA is required.

See the rationale and background below.


-------- Original Message --------
Subject: First post (almost)
Date: Wed, 22 May 2013 15:14:15 -0700
From: Quim Gil <qgil< at >wikimedia.org>
Organization: Wikimedia Foundation
To: qa< at >lists.wikimedia.org

Welcome to the QA list!

This mailing list is an umbrella to host people and discussions focusing
on software quality assurance in all its aspects: exploratory testing,
browser automation testing, unit testing, continuous integration, the
beta cluster, bug management and community QA activities.

We hope this list becomes useful to integrate and retain people
primarily interested in testing / QA. We are seeing many people
interested in

Re: Wiki spam. Stronger fightback.

Richard — 2013-05-22T21:44:10

In article <1369242450.63126.YahooMailNeo< at >web172605.mail.ir2.yahoo.com>,
    halz <halz_antispam< at >yahoo.co.uk> writes:


I thought the standard practice was to require admin approval of new
accounts and require new accounts to fill out a profile for their user
page.

Is your problem that you want to open your wiki to a broader base of
people that you don't want to personally vett the users, I'm not sure
how to deal with that.

Re: Wiki spam. Stronger fightback.

Chris Steipp — 2013-05-22T18:00:36

Please do make sure you know the laws of where you live, and stay
within them. They may be a pain, but please don't break the law :)

Personally, I would recommend taking a look at how some of these tools
work and find ways to explicitly detect and block them. At one point
we were able to trip up a few of them, but I don't personally have the
time right now to reverse engineer them and look for signatures. But
if someone wants to do it, I'd gladly point you in the right
direction.



_______________________________________________
MediaWiki-l mailing list
MediaWiki-l< at >lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: Wiki spam. Stronger fightback.

John — 2013-05-22T17:17:44

The spammers know they are being disruptive, they just dont care unless it
is their site.

On Wed, May 22, 2013 at 1:07 PM, halz <halz_antispam< at >yahoo.co.uk> wrote:

_______________________________________________
MediaWiki-l mailing list
MediaWiki-l< at >lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Wiki spam. Stronger fightback.

halz — 2013-05-22T17:07:30

If you've ever set up a fresh MediaWiki and tried to leave it open to editing, you'll know about the problem of wiki spam. There's various well documented tricks to tackle the problem on your own wiki (although it seems to me that some of these are becoming less effective over time. Particularly reCaptcha)


But wiki spammers are behaving in a staggeringly inconsiderate and anti-social way, and I've often thought we should explore stronger ways of delivering some fight back. 

Looking at spam across many wikis e.g. by googling "mediawiki ugg boots" we could do more internet-wide spam cleanup somehow.

But recently I came across something, actually by looking at one the spam links. Take a look at this: sickseo.co.uk/off-page-seo.html   This video shows the use of a tool called 'SENuke Xcr'  and another one called 'Ultimate Demon'  to perform "Off site SEO" ...that's "spamming" to you and me.

I've always known spammers used tools like this, but seeing this instructional video gives me new insights i

Re: Restoring revision table (mwdumper issue)

Ariel T. Glenn — 2013-05-22T12:33:52

Στις 22-05-2013, ημέρα Τετ, και ώρα 13:55 +0200, ο/η Michael Tsikerdekis
έγραψε:

If you mean importDump.php, I strongly recommend against it.  For a
large wiki it's going to take forever, if indeed it completes at all.

I would suggest removing the page that causes the problem and using
mwdumper on the rest, then using importDump.php on the one page and its
revisions only.

There are a couple other experimental tools yu could try but they are
indeed experimental, see
http://meta.wikimedia.org/wiki/Data_dumps/Tools_for_importing

Ariel



_______________________________________________
MediaWiki-l mailing list
MediaWiki-l< at >lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: Restoring revision table (mwdumper issue)

Michael Tsikerdekis — 2013-05-22T11:55:29

Posted the bug here:

https://issues.apache.org/jira/browse/XERCESJ-1614

Now we just have to wait and see. In the meantime I'll try to use the
official mediawiki importer and see if that works.

Michael


On Tue, May 21, 2013 at 6:30 PM, Ariel T. Glenn <ariel< at >wikimedia.org> wrote:

_______________________________________________
MediaWiki-l mailing list
MediaWiki-l< at >lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: Case Study: Skinning Media Wiki

Dmitrii Kouznetsov — 2013-05-22T10:43:17

Thank, perhaos, I shold narrow a little bit the frame for teh main text.
Anyway, it will be signifivantly wider than the default.

Then I shall have to understand, how does it work!

I shall consider..

Yes.

Not yet. I followed the instructions;
the new setting redirects from
http://mizugadro.mydns.jp/q/Main_Page
to
http://mizugadro.mydns.jp/k/Main_Page
but still does not show the page, it says
Not Found
The requested URL /k/Main_Page was not found on this server.

Actually, I already tried to do shotrUrl in this way,
earlier, and got similar messages, and I hoped,
the extenstion can do the same job;
but you explained that it is not the case..


_______________________________________________
MediaWiki-l mailing list
MediaWiki-l< at >lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: Had an error upgrading from MW 1.2.05

Benjamin Lees — 2013-05-22T08:26:30

Check the error log:
https://www.mediawiki.org/wiki/Manual:How_to_debug


On Tue, May 21, 2013 at 6:37 PM, Arcane 21 <arcane< at >live.com> wrote:

_______________________________________________
MediaWiki-l mailing list
MediaWiki-l< at >lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

Re: Case Study: Skinning Media Wiki

Alexis Moinet — 2013-05-22T06:38:41

using Firebug extension of Firefox


It looks alright now in firefox, but in chrome it is overflowing on the main text area.

You shouldn't rely on absolute negative positioning for this.

I would suggest to use margins/padding instead and maybe (as little as possible) browser-specific tweakings.


Oh ... you're making a confusion between the *extension* "Short URL" ( https://www.mediawiki.org/wiki/Extension:ShortUrl ) which does *not* do that and the *URL rewriting* scheme for short URLs as explained in https://www.mediawiki.org/wiki/Manual:Short_URL

Granted, the naming are very confusing if you don't already have some knowledge about URL rewriting and URL shorteners.

what the extension does is making available URLs like http://mizugadro.mydns.jp/q/index.php/Special:ShortUrl/1 that points to a specific page

more exactly http://mizugadro.mydns.jp/q/index.php/Special:ShortUrl/$1 with '$1' being a code in base-36 (so made of sequence of characters in the ranges [0-9] and [a-z])

That way, you have a so-cal

Re: Case Study: Skinning Media Wiki

Dmitrii Kouznetsov — 2013-05-22T02:34:21

Hello, Alexis. Thank you for your feedback.

On Tue, 21 May 2013, Alexis Moinet wrote:
Yes, namely -38px. How do you count these pixels?
I change it to -28px; now, looking with Safari, I see few millimeters unused at left.
Could you visit http://mizugadro.mydns.jp/t again, does it look better?

??
If I try to open
http://mizugadro.mydns.jp/q/Main_Page   or
http://mizugadro.mydns.jp/k/Main_Page
i.e., without to mention "index.php/", the answer is "Not Found"
So, I would say, the ShortURL does not work at all.
The problem is that I do not understand explanations at
http://www.mediawiki.org/wiki/Extension:ShortUrl


At the end of LocalSettings.php I have line
$wgShortUrlTemplate = "http://mizugadro.mydns.jp/k";
I expected this to enable the short URL 
http://mizugadro.mydns.jp/k/Main_Page
but this does not happen.
What shoudd I type there instead of 
$wgShortUrlTemplate = "http://mizugadro.mydns.jp/k";
?

Well, how to make it to work, if I skip index.php/ in the URL?

it seems, and http://mizugadro.mydns.jp/q/i

Had an error upgrading from MW 1.2.05

Arcane 21 — 2013-05-21T22:37:08

When MW 1.20.6 came out, I decided to upgrade to it from 1.20.5, and I decided to run the web updater afterwards.

All I got was a blank screen no matter what I tried, so I reverted back to 1.20.5 and everything was normal again.

I'm not sure what happened, but I thought I'd let everyone on the mailing list know that there might be a problem with the newest security release.

P.S. - Not really related to the above, but still MediaWiki related: Does anyone know what happened to the MediaWiki Users forum? It's been down for awhile, apparently due to database issues, and I was wondering if anyone here has more information on what happened.
       
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l< at >lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

MediaWiki Security Release: 1.20.6 and 1.19.7

Chris Steipp — 2013-05-21T20:14:52

I would like to announce the release of MediaWiki 1.20.6 and 1.19.7.
These releases fix a security related issue that could affect users of
MediaWiki. Download links are given at the end of this email.

* MediaWiki user Marco discovered that security checks for file
uploads were not being run when the file was uploaded in chunks
through the API. This option has been available to users who can
upload files since MediaWiki 1.19.
<https://bugzilla.wikimedia.org/show_bug.cgi?id=48306>

Full release notes for 1.20.6:
<https://www.mediawiki.org/wiki/Release_notes/1.20>

Full release notes for 1.19.7:
<https://www.mediawiki.org/wiki/Release_notes/1.19>

For information about how to upgrade, see
<https://www.mediawiki.org/wiki/Manual:Upgrading>


**********************************************************************
   1.20.6
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.20/mediawiki-1.20.6.tar.gz

Patch to previous version (1.20.5):
http:/

Re: Case Study: Skinning Media Wiki

Stephan Gambke — 2013-05-21T20:05:21

Ok, it's probably a bit premature, but I thought while we were all
happily bashing each others skins I might as well contribute a bit.

As Jason, I do (well, did) not have too much experience regarding
skinning, always gave it a wide berth. But since my skin of choice is
not very well maintained any more, I finally created my own. For this I
also used Daniels manual, which is excellent. So, kudos Daniel. Remind
me to get you a beer should we ever meet.

Since I am rather lazy and also have some more plans with this skin, I
utilized Twitter's Bootstrap framework which worked great. It allowed me
to throw it all together in a few evenings last week. No CSS tweaking
needed, thank you very much.

To do this I created two minimal extensions, one for the Bootstrap
framework itself[1], one for a php LESS compiler [2].

Out came a skin with horizontal menus with dropdowns/dropups for the
sidebar (above the article) and toolbar and language links (below).
Alas, I don't have a working wiki to show off, but have a look

Re: Case Study: Skinning Media Wiki

Alexis Moinet — 2013-05-21T17:21:05

I'm sorry to tell you that your skin is unreadable in Firefox 21 on ubuntu 12.04: the first letter(s) of each line of each menu is (are ?) out of the frame.

It looks as if you're using negative absolute positionning (e.g. "left: -38px;") on the menu ...


As for ShortURL, it seems to be working more or less on your test wiki but you seem to have something wrong in the template $wgShortUrlTemplate.

For instance:

http://mizugadro.mydns.jp/q/index.php/Special:ShortUrl/2

is a ShortURL that redirects correctly to http://mizugadro.mydns.jp/q/index.php/Test

Likewise http://mizugadro.mydns.jp/q/index.php/Special:ShortUrl/1 redirects to the Mediawiki:Sidebar it seems, and http://mizugadro.mydns.jp/q/index.php/Special:ShortUrl/3 to http://mizugadro.mydns.jp/q/index.php/Test1

on each of these pages there is a link "Short URL" in the toolbox. That link is messed up though. I would suggest that something might have to be fixed in $wgShortUrlTemplate.

The Main page does not seem to have that Short URL link, but I

Re: Case Study: Skinning Media Wiki

Daniel Friesen — 2013-05-21T17:13:13

On Tue, 21 May 2013 04:36:52 -0700, Jason Lewis  
<jason.lewis1991< at >gmail.com> wrote:


My guess is that you and a few other people got confused by my pattern of  
using `[...]` as "A placeholder to replace with relevant data. Instead  
thinking that the `...` alone was a placeholder and the []'s we're either  
required or indicated it was a wikilink.

I swapped that out for just `...` inside that specific field on the wiki  
page.

Re: Restoring revision table (mwdumper issue)

Ariel T. Glenn — 2013-05-21T16:30:56

I think this will do it:

http://xerces.apache.org/xerces2-j/jira.html

Ariel

Στις 21-05-2013, ημέρα Τρι, και ώρα 17:53 +0200, ο/η Michael Tsikerdekis
έγραψε:



_______________________________________________
MediaWiki-l mailing list
MediaWiki-l< at >lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l