Hi all,
I want to inform you that we started a new project called Huggle WA, it's a
web interface based version of popular utility Huggle. It is being
developed by original huggle developers and some other devs and everyone
else, who is interested in this project. Production version and development
server is going to be hosted by wikimedia labs. The tool is probably going
to use OAuth for authentication as soon as it is available and its goal is
to allow anyone with browser to use the utility.
Main benefits include:
- no need to update sw (updates are being done on server)
- no need to download anything or need to have extra permissions on
computer you want to use
- easy access, from any pc
The binary version is still in development, and it's going to be supported
together with the web version. Both versions are going to be compatible, so
that all your settings and history will be transferred from one to other.
In case you are interested in this project, reply here, or join #huggle on
freenode and ask there!
So just to get things straight, i'm rather new with mediawiki development.
I have created an extension where i hook into the tag <sidebarmenu>, and so
when this tag is present in the wiki the following method is called:
public static function renderFromTag( $input, array $args, Parser $parser,
PPFrame $frame )
Now my issue is that i want to publish some $args with certain keys to the
output as javascript variables so they are available in
mw.config.get('my-key'). I have tried using $wgOut->addJsConfigVars(..),
but this doesn't seem to do anything.
i also have the following hook
$wgHooks['ResourceLoaderGetConfigVars'][] =
'SideBarMenuHooks::javascriptConfigVars';
which calls this method.
public static function javascriptConfigVars(&$vars).
And this works fine, all variables i add to the $vars is present in
mw.config.get()...
so how can i pass my <sidebarmenu> tag parameters to mw.config?
Any help is appreciated.
Best regards.
Kim
Since moving to MediaWiki 1.18, several of our extensions that use namespaces have broken in the following way. Any advice/explanation would be very much appreciated! (I don't see anything in the release notes.)
Some of our extensions contain logic like this:
if ($wgTitle->getNamespace() == NS_FOO) { .... }
The problem occurs when an article in the main namespace redirects to the Foo namespace:
#REDIRECT [[Foo:Bar]]
When the user hits this redirect in 1.17 and earlier, the above test returned True. In 1.18 it returns False, and I've had to replace it with more complex logic to follow the redirect:
if ($wgTitle)
if ($wgTitle->getNamespace() == NS_FOO) {
// Really in the User namespace
$fooPageTitle = $wgTitle;
} elseif ($wgTitle->isRedirect()) {
$wikiPage = WikiPage::factory($wgTitle);
if ($wikiPage) {
$t = $wikiPage->getRedirectTarget();
if ($t && $t->getNamespace() == NS_FOO) {
$fooPageTitle = $t;
}
}
}
}
Am I doing something wrong, or is this a bug? What's the right way to detect the namespace of a title, automatically following redirects, as used to work in 1.17?
Thanks,
DanB
On Mon, Feb 27, 2012 at 8:44 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:
> * Code review is falling back behind. As of right now, we have 38
> unreviewed revisions in core (phase3), and another 189 unreviewed
> revisions in extensions. That's up from the 4 core + 28 extensions on
> February 4. We basically let code review get back out of hand as
> we've turned our focus toward bugfixing in deployment.
That was last week. This week, it's even more grim:
* New (unreviewed):
** core: 49
** extensions: 242
* Fixme:
** core: 8
** extensions: 19
The graph: http://toolserver.org/~robla/crstats/
The trendline doesn't look good. What can we do to get back on the right track?
Rob
Summarizing from elsewhere:
Thibaut Horel (User:Zaran) is interested in taking the lead on
ProofreadPage work; if you have requests, please coordinate with him.
He will be developing a roadmap for the development of that MediaWiki
extension soon.
Àlex Hinojo (alexhinojo(a)gmail.com) might have requests for the MediaWiki
web API (and specifically the ProofreadPage web API) that would be
especially helpful for Wikisource, because he is investigating starting
a QRpedia project related to Wikisource (still tentative).
Gaurav Vaidya (gaurav(a)ggvaidya.com) writes that querying
Wikisource-specific bits like ProofreadPage:
"works pretty well! You need to make an 'imageinfo' query on the
multipage image file that the Index page points to to get the number
of pages; you can then query for 'Page:ImageFileName.pdf/PageNumber'
to get the transcribed content for each page.
I'm currently working on a Perl module which handles this
automatically, which -- with many more tests -- will hopefully make it
to CPAN some day. But the source code is up at Github:
https://github.com/gaurav/henderson/tree/develop/WWW-Wikisource "
--
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation
Hi,
In 1.19 a dropdown was added to Special:MovePage for selecting a
namespace. This new feature doesn't disturb me personally, but a few
users in the Hebrew Wikipedia complained about it, saying that it
causes users confusion. I don't have numbers, but the regular
followers of the move logs said that in the days since the upgrade
there was a higher number of mistakes because of this new feature.
A couple of examples, with English namespace names, because the
essence is the same):
1. People moved an article that they wrote from
User:New-article-writer/New_article_name to
Wikipedia:New_article_name, thinking that this is the way to put the
article in Wikipedia.
2. People moved a sandbox page from User:Sandbox-lover/sandbox5771 to
User:User:Sandbox-lover/sandbox5772.
The root cause of the first example mistake is the *very* confusing
name of the "Wikipedia:" namespaces. It should have been called
"Community:", "Forum:", "Documentation:" or anything else, but having
the same name as the project is pretty bad. The new dropdown just
floats it.
Any other thoughts?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
The sources and methods we've been using for the generation of security
tokens in our code has been either fairly inadequate or has system support
issues.
-- TL;DR portion --
In the installer we try to use /dev/urandom directly. While this is a good
source it's not available in some situations. And if it's not available,
then we all the way back to nearly the weakest random number generator we
could have.
For the generation of user_token we take the secret key generated during
installation (or use microtime if not available), combine it with mt_rand(
0, 0x7fffffff ), the wiki id, and the user_id and the md5 it.
Given that both the wiki id and the user id are public and mt_rand is weak
we basically rely entirely on the secret key. If the secret key is leaked
then it becomes a mere matter of time before one could find out what token
was used by trying the possible values of mt_rand. And the entire
user_token column needs to be reset.
Also given that people regularly post their LocalSettings.php in
#mediawiki and some forget to strip out their $wgSecretKey it would be a
good idea to not depend so heavily on the secret key actually being secret.
For the generation of other security tokens like email confirmation tokens
and temporary passwords we use nothing but mt_rand() not even bothering to
see if there is a proper source of random data.
-- END --
In light of that, I've built a new MWCryptRandom class intended to be used
in the installer for generating tokens, when generating user_token, and
when generating other cryptographic random tokens.
The class is in-part based on Drupal's drupal_random_bytes[1] method, some
of our own code, some code I had written prior to writing this (eg: I had
already planned to use openssl_get_random_bytes in User::setToken before I
wrote this), and some extras added into the theory based on what we have
available.
Since it's security related I'd like people to look over the code and give
some feedback on it.
The class was committed in r111964 but backed out till after the git
migration:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/111964
If you want to try out and test the class yourself you can get it into
your trunk svn checkout by using:
$ svn merge -c 111964 .
[1]
http://api.drupal.org/api/drupal/core!includes!bootstrap.inc/function/drupa…
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Hi everyone!
I want to install php module php-fss on php5.3 since I heard that it boosts
MediaWiki performance a lot. Is it possible to do that? Is it installed on
wikipedias?
-----
Yury Katkov