https://www.mediawiki.org/wiki/Extension:Blackout
This is NOT the code that the Wikimedia Foundation is using for the SOPA/PIPA blackout. This is an extension developed by John Du Hart and myself to help other MediaWiki sites black out.
The code's at:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Blackout/
That page also links to other resources and methods for anti-SOPA JavaScript and so on.
Technical guide on Wikipedia's usage:
https://meta.wikimedia.org/wiki/English_Wikipedia_SOPA_blackout/Technical_F…
Localisation support coming within the hour.
This will be maintained in the coming weeks for use with related SOPA/PIPA / Internet Censorship related actions (my hunch is that this isn't the end of this). After that the extension will be morphed into one for use with any blackout based on the wiki's needs. May make that an option sooner rather than later if there's requests for this feature.
-greg aka varnent
-------
Gregory Varnum
Lead, Aequalitas Project
Lead Administrator, WikiQueer
Founding Principal, VarnEnt
@GregVarnum
fb.com/GregVarnum
The black favicon on test.wikipedia is just perfect for this job. Is
it possible to change the favicon to black just for en:wp? (Or is that
a pain in the backside too far?)
(bikeshed bikeshed)
- d.
Hi.
Skimming <https://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action>,
it seems inevitable that some kind of banner (or "blackout" banner, which is
apparently equivalent to an extra-large banner) will be implemented.
The question becomes: how will this be implemented? I assume some kind of
CentralNotice banner with some CSS absolute positioning or something? Is
that right? Or will it be part of a separate extension?
Primarily I'd like to know if "#siteNotice {display:none !important;}" will
continue to work. If so, there's no further action that needs to be taken.
If it's going to be put into a weird extension or something, I'd personally
favor an edit count check or a "leave me alone" user preference. The
regulars really don't need to be bothered by this obnoxiousness.
And, click-through banner or not, I think obscuring Special:UserLogin is a
poor idea.
I'm not quite sure who's working on this from the tech side, but if anyone
has details about the (proposed) banner's implementation and could share,
that'd be great.
MZMcBride
If you can get to Kolkata, India on January 25th, you can help out an
event that's hoping to learn about MediaWiki development. You can
contact Sucheta for more information.
http://wiki.wikimedia.in/Wiki_Academy/Netaji_Subhash_Engineering_College
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
On 01/12/2012 03:28 AM, wikimediaindia-l-request(a)lists.wikimedia.org wrote:
> Date: Mon, 9 Jan 2012 18:44:55 +0530
> From: Sucheta Ghoshal <sucheta.ghoshal(a)gmail.com>
> Subject: [Wikimediaindia-l] Help needed for Wiki Academy in Kolkata
> To: wikimediaindia-l(a)lists.wikimedia.org
> Message-ID:
> <CAF5rHFdLSyefUQg+4-B1rsR+VwJ1NJ3B-1UwaubZg2TYfOxghg(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> We are having a Wiki Academy for the first time in Kolkata at Netaji
> Subhash Engineering College . We would appreciate to have any kind of help
> to make this Wiki Academy a successful event, as of now We are looking for
> person who is willing to speak on the technical aspects of Wikipedia ( More
> specifically "How a developer can contribute to the Meta-Wiki Source Code).
> Since it is an engineering college,and we are hosting it as a college event
> only so Technical part is necessary according to the students concerned.
> Please help us.
>
> Regards,
> Sucheta Ghoshal
Hey all,
After two weeks of annoyance I'll just dump this here.
There have been many people who have donated their browser resources to our
TestSwarm[1] continuos integration project for MediaWiki.
First and foremost, thanks to all who've been doing so. Please keep doing
that :)
However there's one little thing I'd like to get rid of:
Someone with Ubunto has an "Epiphany" (WebKit based) browser that is
polluting[4] our swarm with false positives.
"Epiphany" is not a supported[2] browser, but due it lying[3] about it's
identity it is not blocked from joining the swarm and instead submits
results under "Safari".
User agent of suspect:
Mozilla/5.0 (X11; Linux i686) AppleWebKit/534.26+ (KHTML, like Gecko)
Version/5.0 Safari/534.26+ Ubuntu/11.04 (3.0.4-1ubuntu1) Epiphany/3.0.4
Please whoever operates this machine, keep it out of the swarm.
(in the future we might get a system to blacklist this but for now..)
Thanks :)
- Krinkle
[1] http://integration.mediawiki.org/testswarm/
[2] http://www.mediawiki.org/wiki/Compatibility#Browser
[3] http://webaim.org/blog/user-agent-string-history/
[4] http://integration.mediawiki.org/testswarm/user/mediawiki/ (if you
don't see a red column to the right here, it means the problem was fixed in
the mean time)
Hi.
https://bugzilla.wikimedia.org/show_bug.cgi?id=13937 is a feature request to
add the ability for users to be able to edit their own edit summaries within
a limited window of time following submission, assuming there are no
subsequent edits to the page.
This seems like it wouldn't be very difficult to implement in an extension.
Is that the correct approach here? Or does anyone feel it should be in core?
In either place, it'd be a special page, I suppose? Or maybe some inline
AJAX thing could be implemented for the &action=history view....
And regardless of where it goes, this doesn't need its own logging, right?
MZMcBride
Hello,
I'm trying to get information from Wikipedia dump based on
categorization or template usage. I first query MediaWiki API with
embeddedin or categorymembers query to get a list of articles I'm
interested in. Then I retrieve them from the dump and extract the
information I need. The problem is that sometimes the current titles
retrieved using the API doesn't match with what's in the dump because
the article has been moved, for example.
I think I could use two options to solve the problem:
- Parse the categorization and template usage information from all
articles in the dump and build the list of all articles in given
category and using given templates myself. This might be prone to errors
because of the need of custom parsing.
- Import the dump into the local MediaWiki installation and query the
API locally. But from what I read in the documentation importing the
dump into a database can take an excessive amount of time.
Is there any easier option? Is there a dump of categorization and
template usage kept somewhere? Or perhaps I missed something and this
information can be retrieved from the dump without parsing it?
Thanks,
Piotr
Because of the changes that have been introduced in ResourceLoader in
1.19 (see https://bugzilla.wikimedia.org/33711 and
https://bugzilla.wikimedia.org/33746 for example), on-wiki gadget users
will begin to see lots of JavaScript errors if we don't act now.
On enwiki.beta (http://en.wikipedia.beta.wmflabs.org/), I enabled all
the gadgets and then went through the JS errors that popped up to see
what modifications needed to be made to
[[MediaWiki:Gadgets-definition]]. I let [[Wikipedia talk:Gadget]] know
about the needed changes
(https://en.wikipedia.org/w/index.php?diff=471706835).
We need a lot more of this sort of testing on all the wikis, but I'm
only one person and there are hundreds of wikis. Please have a look at
http://labs.wikimedia.beta.wmflabs.org/wiki/Special:SiteMatrix and find
other wikis to test.
On some wikis (yiwiki.beta, for example), we're going to need to import
the MediaWiki namespace, so if you come across a wiki that is different
than production, let me know or pop into #wikimedia-labs and ping one of
the beta team members there.
Mark.
Hello,
[r106883] introduces a new global setting to whitelist deprecated
functions: $wgDeprecationWhitelist. Its documentation is:
/**
* Function name whitelist for wfDeprecated warnings. You will not be
warned
* for usage of deprecated functions in this list. This is mainly usefull
* for extension developers unable to not use certain deprecated functions
* due to backward compatinility reasons.
* @since 1.19
* @var array
*/
I do not think we want such setting in core since it does not make sense.
Developers can opt-in to get deprecation warnings shown, it is not to have
them whitelisted later with yet another global. Either the extension need
to be fixed or the core call should not be deprecated.
So, I have reverted the change with [r106946]. That was then opposed
a "fuck you" argument and reverted ....
* I am not going to engage in a revision war.
* I am not going to mark 'ok' a revision I feel is wrong.
So this mail is merely asking for people to please have a look at the
feature, comment on it and reach a consensus about whether we should
or should not keep this setting.
Thanks.
[r106883] Introduced wgDeprecationWhitelist
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106883
[r106946] My reversion
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/106946
--
Antoine "hashar" Musso