[MediaWiki-CodeReview] [MediaWiki r86183]: Revision status changed

[MediaWiki Mail]

User "Catrope" changed the status of MediaWiki.r86183.

Old Status: new
New Status: ok

Full URL: 
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86183#c0
Commit summary:

* (bug 28568) Entries in the iwlinks table are now removed on page deletion

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86088]: New comment added

[MediaWiki Mail]

User "DieBuche" posted a comment on MediaWiki.r86088.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86088#c16063
Commit summary:

Completely rewritten table sorting script.
Fixes Bug 8028, Bug 8115, Bug 15406, Bug 17141, Bug 8732

1. Sites can specify custom collations.
The script accepts an object "tableSorterCollation" which contains a lookup
table, how specific characters should be treated.
For example, after setting "tableSorterCollation={'ä':'ae', 'ß':'ss'};" in the
site's common.js any string containing an ä or Ä will be sorted as if it were a
'ae'.

2. Table rows can be forced to use a specific data type.
By setting class="sort-{Parsername}", the row will be parsed with the specified
algorithm. class="sort-date" would force date sorting etc.
The following parsers are available: text, IPAddress, number, url, currency,
date, isoDate, usLongDate, time

3. Execution time is reduced by half or more.

Sorting a 935 row * 8 columns table:

Browser Before  After
--  -
Chrome 10   90ms42ms
Safari 5115ms   48ms
Firefox 4   412ms   87ms
IE8 720ms   115ms

4. Based on the content language and the mdy vs dmy preference, the parser can
understand dates such as "17. März '11". wgMonthNames=[] and
wgMonthNamesShort=[]
in the content language and the mdy vs dmy preference are exported to js; A
table containing the following dates would be sorted correctly:
17. Jan. 01
23 Feb 1992
9.02.05
13 November 2001
14 Oktober '76

Was tested in ie6-8, chrome, safari 5, ff3 & ff4

Comment:

I'm not fond of it either, but it's necessary in order to use Array.sort ( 
http://www.w3schools.com/jsref/jsref_sort.asp ) 
Array.sort accepts a sorter function, and there no way to build this fn w/o 
eval. 

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86247]: New comment added, and revision status changed

[MediaWiki Mail]

User "Siebrand" changed the status of MediaWiki.r86247.

Old Status: new
New Status: fixme

User "Siebrand" also posted a comment on MediaWiki.r86247.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86247#c16064
Commit summary:

Initial import.

Comment:

Path looks like an error that should probably be fixed.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86254]: Revision status changed

[MediaWiki Mail]

User "Reedy" changed the status of MediaWiki.r86254.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86254#c0
Commit summary:

Remove debugging code accidentally committed in r86253

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86250]: Revision status changed

[MediaWiki Mail]

User "Reedy" changed the status of MediaWiki.r86250.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86250#c0
Commit summary:

Back out r86054 and part of r86059 for now, I'd like to evaluate the 
possibility of integrating NeilK's work into the core now

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86218]: New comment added

[MediaWiki Mail]

User "Helder.wiki" posted a comment on MediaWiki.r86218.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86218#c16065
Commit summary:

Add ParserTest

Comment:

It is necessary to add the file to 
[[svn:trunk/extensions/BookManager/BookManager.php|/BookManager.php]]:
 [[Manual:$wgParserTestFiles|$wgParserTestFiles]][] = $dir . 
"/BookManagerParserTests.txt";

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86056]: New comment added

[MediaWiki Mail]

User "Krinkle" posted a comment on MediaWiki.r86056.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86056#c16066
Commit summary:

Followup to r86047: Rewrite the radio-button updater & move everything to 
action.history. Also move to fixCompare version by Helder, since HTMLdiff is 
scrapped

Comment:

Nice work. Rewrite from legacy to mw-lib for the history looks pretty good 
here! 


+   var $this = $(this);
+   var diffLi = false, // the li where the diff radio is checked
+   oldLi = false; // the li where the oldid radio is 
checked

+   oldLi = $this;
+   diffLi = $this;

+   if ( diffLi && oldLi ) {
+   } else if ( diffLi ) {


jQuery objects don't return boolean false when they don't contain elements, use 
.length instead.



+ [..] .click( function() { updateDiffRadios(); } );

No need to create an anonymous function, you can pass the function directly by 
reference.




___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86056]: New comment added

[MediaWiki Mail]

User "Catrope" posted a comment on MediaWiki.r86056.

Full URL: 
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86056#c16067
Commit summary:

Followup to r86047: Rewrite the radio-button updater & move everything to 
action.history. Also move to fixCompare version by Helder, since HTMLdiff is 
scrapped

Comment:

If you need to create an empty jQuery object, you can do so with var foo 
= $( [] );

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] https://github.com/mediawiki/ is now up again

[Ævar Arnfjörð Bjarmason]

It's been re-cloned and is being updated every 10 minutes.

Note that this was a non-fast-forward updates, so "git pull" on
existing checkouts won't work, you'll have to re-clone.

On the plus side this is now being cloned directly from svn, e.g. this
is the latest commit:

git-svn-id:
svn+ssh://svn.wikimedia.org/svnroot/mediawiki/trunk@86256
dd0e9695-b195-4be7-bd10-2dea1a65a6b6

This means that using this to bootstap your own git-svn checkout (to
use for further development) should be possible now, but I don't have
instructions for how to do that, patches to
http://www.mediawiki.org/wiki/Git#Rebuilding_SVN_metadata welcome.

Note that this is still out of date:

http://gitorious.org/mediawiki

I don't know who maintains it, but if there's demand for having one on
gitorious I'd be happy to update that one too. It's just a matter of
adding a couple of extra pushes here:

https://github.com/avar/mediawiki-mirror/blob/master/mediawiki-mirror.sh#L22

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Linker, more on Skins, OutputPage, and context code patterns changes

[Dmitriy Sintsov]

On 05.04.2011 5:06, Daniel Friesen wrote:
> Continuing with my changes to $wgOut, $wgUser, Skin, and SpecialPage
> patterns.
>
> 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
> Linker::link directly.
> 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:
> http://www.mediawiki.org/wiki/Request_Context
>
>
Context is very interesting. That sounds like easier way of having farms 
sharing one installation path without the symlink hacks, also probably 
an efficient "in-farm transclusion".
Dmitriy

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Linker, more on Skins, OutputPage, and context code patterns changes

[Daniel Friesen]

>> Continuing with my changes to $wgOut, $wgUser, Skin, and SpecialPage
>> patterns.
>>
>> 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
>> Linker::link directly.
>> 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:
>> http://www.mediawiki.org/wiki/Request_Context
>>
>>
> Context is very interesting. That sounds like easier way of having farms 
> sharing one installation path without the symlink hacks, also probably 
> an efficient "in-farm transclusion".
> Dmitriy
Symlink hacks?
You can already make a farm just by using a LocalSettings.php with
conditionals based on a domain or wikiid passed to maintenance scripts.
Request Context only contains limted data and doesn't deal with the
varying loading of different things like extensions. It's also
completely orthogonal to whatv db is being loaded from so it's not
useful at all for transclusion.
But it should eventually provide you with a better way to faux execute a
page on the local wiki, and then include pieces of that into the actual
current page. Like what SpecialPage, LST, etc... do.

-- 
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] https://github.com/mediawiki/ is now up again

[Brion Vibber]

On Sun, Apr 17, 2011 at 5:33 AM, Ævar Arnfjörð Bjarmason
wrote:

> It's been re-cloned and is being updated every 10 minutes.
>
> Note that this was a non-fast-forward updates, so "git pull" on
> existing checkouts won't work, you'll have to re-clone.
>
> On the plus side this is now being cloned directly from svn, e.g. this
> is the latest commit:
>
>git-svn-id:
> svn+ssh://svn.wikimedia.org/svnroot/mediawiki/trunk@86256
> dd0e9695-b195-4be7-bd10-2dea1a65a6b6
>
> This means that using this to bootstap your own git-svn checkout (to
> use for further development) should be possible now, but I don't have
> instructions for how to do that, patches to
> http://www.mediawiki.org/wiki/Git#Rebuilding_SVN_metadata welcome.
>

Sque! I'm probably gonna use that... will see if I can muddle through
and update the notes.


> Note that this is still out of date:
>
>http://gitorious.org/mediawiki
>
> I don't know who maintains it, but if there's demand for having one on
> gitorious I'd be happy to update that one too.


I took it over from the previous person who was mirroring at it a couple
months ago; I actually set you up with admin permissions, so feel free to
set up the automatic pushes. :D

-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status of 1.17 & 1.18

[Aryeh Gregor]

On Fri, Apr 15, 2011 at 9:41 PM, Brion Vibber  wrote:
> But it's also true that there were other bugs buried in code that had been
> changed 8-9 months previously, making it harder to track them down -- and
> much more difficult to revert them if a fix wasn't obvious. I certainly
> experienced that during the 1.17 deployment, and received the same
> impression from other developers at the time.

For a concrete example, see
 and
follow-up commits.  I made that commit shortly after 1.17 deployment,
working with Roan to resolve a bug in my categorylinks rewrite.  It
turned out that I got confused by my own variable naming and
completely broke non-uppercase collations in the process of fixing the
bug that was visible on Wikimedia.  That required effort by
translatewiki.net to track down the bug again more than a month later.
 I'm pretty sure I wouldn't have made that mistake if I had been
writing the fix two weeks later instead of six months later.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r85929]: New comment added

[MediaWiki Mail]

User "Tbleher" posted a comment on MediaWiki.r85929.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85929#c16068
Commit summary:

Implement a $context and getContext/setContext methods for Article (and its 
subclasses).

Comment:

Can you please update callers in extensions? DumpHTML was broken by this 
change, as it calls MediaWiki::articleFromTitle():
 Catchable fatal error: Argument 2 passed to MediaWiki::articleFromTitle() must 
be an instance of RequestContext, none given, called in 
/srv/www/mediawiki/extensions/DumpHTML/dumpHTML.inc on line 804 and defined in 
/srv/www/mediawiki/code/includes/Wiki.php on line 269


___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r85929]: New comment added

[MediaWiki Mail]

User "Krinkle" posted a comment on MediaWiki.r85929.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85929#c16069
Commit summary:

Implement a $context and getContext/setContext methods for Article (and its 
subclasses).

Comment:

Potentially more extensions:

"articleFromTitle" in /trunk/extensions/:

http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=173&hash=082b8bdeb037aee898c6e2ae77910bb0

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86272]: Revision status changed

[MediaWiki Mail]

User "Krinkle" changed the status of MediaWiki.r86272.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86272#c0
Commit summary:

Localisation updates for ToolserverI18N messages from translatewiki.net 
(2011-04-17 19:00:00 UTC)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r85929]: New comment added

[MediaWiki Mail]

User "Happy-melon" posted a comment on MediaWiki.r85929.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85929#c16070
Commit summary:

Implement a $context and getContext/setContext methods for Article (and its 
subclasses).

Comment:

Done in r86273.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r85929]: New comment added

[MediaWiki Mail]

User "Krinkle" posted a comment on MediaWiki.r85929.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85929#c16071
Commit summary:

Implement a $context and getContext/setContext methods for Article (and its 
subclasses).

Comment:

Hm.. can/should we make it default to Main ?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] https://github.com/mediawiki/ is now up again

[Ævar Arnfjörð Bjarmason]

On Sun, Apr 17, 2011 at 19:32, Brion Vibber  wrote:

> I took it over from the previous person who was mirroring at it a couple
> months ago; I actually set you up with admin permissions, so feel free to
> set up the automatic pushes. :D

It's now pushing to gitorious too.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r86288]: New comment added

[MediaWiki Mail]

User "Happy-melon" posted a comment on MediaWiki.r86288.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86288#c16072
Commit summary:

Tidy and reorganise the AutoLoader array, because its 
almost-alphabetical-but-not-quite status was annoying me inordinately...  :D  
classes are now divided strictly by subfolder, the subfolders are in 
alphabetical order, and classes within each subfolder are strictly in 
alphabetical order.

Comment:

Probably the easiest way to review this is to alpha-sort the entire array 
before and after and verify that they contain the same entries.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86175]: New comment added, and revision status changed

[MediaWiki Mail]

User "Tim Starling" changed the status of MediaWiki.r86175.

Old Status: new
New Status: ok

User "Tim Starling" also posted a comment on MediaWiki.r86175.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86175#c16073
Commit summary:

First step of reorganizing profiling files:
* Move them all to includes/profiling/* - If you're using StartProfiler, you'll 
need to update that
* Make ProfileStub subclass the Profiler rather than duplicating function 
definitions conditionally
* Removed unused params to wfGetProfilingOutput(), only used in the stub, and 
they didn't do anything with them
* TODO: Kill $wgProfiling, make $wgProfiler a config array and move the various 
options to that. Also make into a singleton, rather than global (not much calls 
it outside of core)

Comment:

Please do not move files and change them in the same commit, it makes review 
difficult.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Linker, more on Skins, OutputPage, and context code patterns changes

[Dmitriy Sintsov]

* Daniel Friesen  [Sun, 17 Apr 2011 10:16:31 
-0700]:
> >> Continuing with my changes to $wgOut, $wgUser, Skin, and 
SpecialPage
> >> patterns.
> >>
> >> 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
> >> Linker::link directly.
> >> 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:
> >> http://www.mediawiki.org/wiki/Request_Context
> >>
> >>
> > Context is very interesting. That sounds like easier way of having
> farms
> > sharing one installation path without the symlink hacks, also 
probably
> > an efficient "in-farm transclusion".
> > Dmitriy
> Symlink hacks?
> You can already make a farm just by using a LocalSettings.php with
> conditionals based on a domain or wikiid passed to maintenance 
scripts.
> Request Context only contains limted data and doesn't deal with the
> varying loading of different things like extensions. It's also
> completely orthogonal to whatv db is being loaded from so it's not
> useful at all for transclusion.
> But it should eventually provide you with a better way to faux execute 
a
> page on the local wiki, and then include pieces of that into the 
actual
> current page. Like what SpecialPage, LST, etc... do.
>
An instance RequestContext can be a member of MediaWiki object, for 
example. In 1.15.4 I have there
function preliminaryChecks( &$title, &$output, $request )
but a
function checkInitialQueries( $title, $action ) {
global $wgOut, $wgRequest, $wgContLang;

}
Some methods has an output as parameter, while another uses a global. 
I've checked 1.17 branch and not much changed yet. Also, it's 
interesting why an ancestor of DatabaseBase is not a member of MediaWiki 
object, too.
Dmitriy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Linker, more on Skins, OutputPage, and context code patterns changes

[Chad]

On Mon, Apr 18, 2011 at 1:03 AM, Dmitriy Sintsov  wrote:
> Also, it's
> interesting why an ancestor of DatabaseBase is not a member of MediaWiki
> object, too.

What if you needed to switch between DB_MASTER and DB_SLAVE?
Easier to just call wfGetDB() as needed.

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r86228]: Revision status changed

[MediaWiki Mail]

User "Tim Starling" changed the status of MediaWiki.r86228.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86228#c0
Commit summary:

More profiler cleanup:
* Move autoloader up a little bit so the profiler classes can use it
* Make Profiler into a singleton so it's lazy-constructed, $wgProfiler is now a 
configuration array (used 'visible' in ProfilerSimpleText as an example of 
other globals we can move into this array). If $wgProfiler is set to an object, 
it'll use that for back-compat
* Maintenance: rather than setting up the profiler and then disabling it, just 
disable it from the start
* Kill $wgProfiling -> now that ProfilerStub overrides profileIn() and 
profileOut(), it's not needed
* dumpHTML needs some fixes still

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86232]: Revision status changed

[MediaWiki Mail]

User "Tim Starling" changed the status of MediaWiki.r86232.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86232#c0
Commit summary:

Followup r86228 (profiling cleanup):
* Move autoloader up in Maintenance as well
* Add setInstance() method to Profiler, dumpHTML will need it
* Move get/setProfileId() up a level to Profiler. ProfilerSimple subclasses use 
it, behavior is harmless for Stub.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86231]: Revision status changed

[MediaWiki Mail]

User "Tim Starling" changed the status of MediaWiki.r86231.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86231#c0
Commit summary:

Followup r86228 (profiling cleanup):
* Move autoloader up in Maintenance as well
* Add setInstance() method to Profiler, dumpHTML will need it

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86233]: Revision status changed

[MediaWiki Mail]

User "Tim Starling" changed the status of MediaWiki.r86233.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86233#c0
Commit summary:

Various profiler fixes for dumpHTML (needs r86175, r86228, r86231, r86232)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86177]: Revision status changed

[MediaWiki Mail]

User "Tim Starling" changed the status of MediaWiki.r86177.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86177#c0
Commit summary:

Kill file-scope define

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r86289]: Revision status changed

[MediaWiki Mail]

User "Tim Starling" changed the status of MediaWiki.r86289.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86289#c0
Commit summary:

Followup r86233, rm unused global

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Linker, more on Skins, OutputPage, and context code patterns changes

[Dmitriy Sintsov]

* Chad  [Mon, 18 Apr 2011 01:07:09 -0400]:
> On Mon, Apr 18, 2011 at 1:03 AM, Dmitriy Sintsov 
> wrote:
> > Also, it's
> > interesting why an ancestor of DatabaseBase is not a member of
> MediaWiki
> > object, too.
>
> What if you needed to switch between DB_MASTER and DB_SLAVE?
> Easier to just call wfGetDB() as needed.
>
Ok, I didn't think about that. I do not run MySQL cluster. However, 
multiple instances can be stored as member of MediaWiki object. But, 
anyway - maybe that's not needed. I just saw the trend "against the 
globals" and thought that it can be "generalized".
Dmitriy
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r86247]: Revision status changed

[MediaWiki Mail]

User "^demon" changed the status of MediaWiki.r86247.

Old Status: fixme
New Status: reverted

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86247#c0
Commit summary:

Initial import.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r85250]: New comment added

[MediaWiki Mail]

User "Tbleher" posted a comment on MediaWiki.r85250.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85250#c16074
Commit summary:

Continue with r85240; Move getSkin from User to RequestContext, do it without 
globals, strip out the non-functional $title related stuff, and update Skin to 
use a RequestContext.

Comment:

Could you fix the DumpHTML extension that was broken by this change?

 Call to undefined method SkinVector::setTitle
 Backtrace:
 #0 [internal function]: Skin->__call('setTitle', Array)
 #1 /srv/www/mediawiki/extensions/DumpHTML/dumpHTML.inc(819): 
SkinVector->setTitle(Object(Title))
 #2 /srv/www/mediawiki/extensions/DumpHTML/dumpHTML.inc(482): 
DumpHTML->getArticleHTML(Object(Title))
 #3 /srv/www/mediawiki/extensions/DumpHTML/dumpHTML.inc(209): 
DumpHTML->doArticle(Object(Title))
 #4 /srv/www/mediawiki/extensions/DumpHTML/dumpHTML.inc(148): 
DumpHTML->doArticles()
 #5 /srv/www/mediawiki/extensions/DumpHTML/dumpHTML.php(152): 
DumpHTML->doEverything()
 #6 {main}

I do not know enough about the new RequestContext stuff to properly fix this 
extension.

(Small general question: should a revision be marked "fixme" if it breaks an 
extension not currently used by the WMF?)


___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview