The April run of the english history dumps is incomplete. There is at
least one file that will need to be regenerated. When it's ready I'll
send an email update. I expect a delay of 4-5 days for that.
Continuing with my changes to $wgOut, $wgUser, Skin, and SpecialPage
The Linker is now static, $sk->link will still work, however you should
not be requiring a Skin anymore to use linker methods. Please use
The only exception is the method to create an editsection link, that
method IS part of Skin itself now.
Also there is some compat for hooks that were passed the linker as an
instance, and `$parserOptions->getSkin();` However note that
ParserOptions::getSkin no longer returns an actual Skin, it now returns
a plain linker instance and makes a depreciated call.
((for reference the 'instance' of Linker which is static is actually a
"DummyLinker" class which has a __call that forwards old method calls to
static calls to the linker))
So nearly EVERY case you are currently grabbing a Skin for, you should
no longer be fetching a skin.
Now, if you really do need a skin, the the new way to get a skin is
`$context->getSkin()`, OutputPage has a helper `$out->getSkin()` if you
happen to be working on OutputPage related stuff and need to interact
with the skin. `$wgUser->getSkin();` has some BackCompat to keep
working, however please avoid using it, it uses the main RequestContext,
not whatever the RequestContext for whatever context you are in is.
Also, there is no equivalent to `$wgUser->getSkin( $title );`. Skin no
longer has a mTitle of it's own, it gets the title used in the attached
RequestContext, which is the same one that OutputPage uses, and is
essentially the replacement to $wgTitle. So you don't need to work
around bugs like that in Skin, nor in OutputPage anymore. Additionally
that format was never actually used right, nearly every call to that was
actually made in contexts where one was using the Linker methods (which
don't use mTitle) and was not interacting with the skin.
I started a page on the RequestContext object:
---- some extra ----
I'm still contemplating skin setting and relation to context right now.
I would like to make it possible to do something like
`$context->setSkin( new DummyOfflineSkin );` but also want to avoid bugs
where you try to set the same skin onto two contexts and get an error.
I examined the code paths, and Skin doesn't actually make any
RequestContext dependent calls except inside calls made from the
Skin::outputPage( $out ); entrypoint which is called by
OutputPage::output();, in other words theoretically I could avoid tying
a Skin instance to any specific context by setting the context at the
start of Skin::outputPage( $out ) ($out provides the RequestContext),
and exiting that context when it's done. However there is one instance
where this rule is broken, ApiParse which makes a direct call outside of
that context when you use categoryhtml or languagehtml (which I wanted
to stop from being released from the start).
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
2011/4/14 Mark Hershberger <mhershberger(a)wikimedia.org>:
> Sorry, I should have been clearer. Yes, branch now(ish) and then aim for a
> 1.18 release on July 15th. My idea is that setting a date for the release
> to be soon and early would provide the motivation to the people involved in
> code review to keep it up-to-date.
The point I was trying to make was that July is by no means "soon and
early" in my book. It's three months away, which is way to long.
Setting a date is nice, but if we can get a release out before the set
date, that's a good thing, and I think we can (and /should/) get 1.18
out way faster.
Roan Kattouw (Catrope)
This is a fork of this thread:
Is there a possibility that I could instead (easily) merge the handful
of individual wiki's content into one consolidated wiki and implement a
more enhanced search against it instead? I've no experience performing a
merge like this so expert advice would be appreciated!
Thanks - Tod
I'm getting close to releasing JSWikiGantt extension and I'm wondering
if this should go to SVN or not? And in effect should I ask for commit
access to SVN or not. I have my own server so I can put my code there,
but I'm not sure what are the habits with extensions.
Just to clarify what the extension is - it's basically a port of JSGantt
to MediaWiki. It allows injecting Gantt diagrams as XML into articles.
There's certainly a lot room for improvement (like e.g. an ability to
have more then one diagram per page) and I still need to go for i18n,
but that should be ready soon (I hope).
BTW are there any guidelines (or at least good examples) of i18n in JS?
What I mean is - I need to use some (most) localized strings in JS and
would like to use existing code (if possible) for pushing strings from
PHP to JS.
I also have another extension for editing diagrams of certain type -
namely calendar-diagrams for activities such as "Delegation",
"Vacation", "Sick leave". From what I've read this probably shouldn't go
to SVN or should it?
Oh, both extensions where written for 1.16, but I'm mostly using JS
anyway so this probably shouldn't matter.
Extension and Core:
* Patrick Reilly (preilly)
Patrick has joined the WMF engineering team as Sr. Software Developer
Code Maintenance Engineer
San Francisco, CA