Wikitech-l June 2008

wikitech-l@lists.wikimedia.org

86 participants
91 discussions

Template parameter expansion performance?
by Anon Sricharoenchai 06 Jun '08

06 Jun '08

Given that, 1. Template:A1 = {{{1}}} {{{1}}} {{{1}}} {{{1}}} {{{1}}} {{{1}}} 2. Template:A2 = {{#ifeq: {{PAGENAME}} | ... | ... }} When expanding, 1. {{A1| {{A2}} }}: As Template:A1 contains six of {{{1}}}, it will compute A2's {{#ifeq:...}} six times, or just one time? 2. {{A1| {{#ifeq: {{PAGENAME}} | ... | ... }} }}: Same as above, how many times will it compute {{#ifeq:...}}? If it compute {{#ifeq:...}} six times in the above expansion, is it possible to reduce this computation count by caching the result of expression?

1 0

SUL homewiki selection question
by Anon Sricharoenchai 05 Jun '08

05 Jun '08

Hi, 1. Why still we let the SUL to auto select the homewiki in Special:MergeAccount? 2. Why not we let the wiki that do Special:MergeAccount as homewiki? Example, Assuming that it has user test123@testwiki (1000 edit counts) and test123@lowikibooks (500 edit counts) * If test123 do merge account at, http://test.wikipedia.org/wiki/Special:MergeAccount, then testwiki will be homewiki. * If test123 do merge account at, http://lo.wikibooks.org/wiki/Special:MergeAccount, then lowikibooks will be homewiki. 3. Why not prohibit creation of existing account that have not yet been merged on any wikis? Example, 1. Before SUL, if have test123 created on http://lo.wikipedia.org 2. test123@lowiki has not been merged on any wikis. 3. After SUL, should immediately prohibit the creation of test123 account on any WM wikis. (even that test123 has not yet been merged to SUL) 4. Considering the following situation, 1. Mr.A own "user123" at, * testwiki,meta,common,mediawiki: 100,500,500,500 edits count * enwikipedia,enwikibooks,enwikitionary,enwikisource,enwikinews: 100,100,100,100,100 edits count * lowikipedia,lowikibooks,lowiktionary,lowikisource,lowikinews: 500,100,100,100,100 edits count * totally, Mr.A has 3000 edits count 2. Mr.B own "user123" only at frwikipedia with 2000 edits count 3. When Mr.A use user123 on lowikipedia, and do http://lowikipedia/Special:MergeAccount, what will be the homewiki of user123? 4. Mr.A can successfully merge account? 5. If homewiki determined by the system is user123@frwikipedia, then what thing Mr.A could do to get his accounts merged? Regards, Anon.

9 22

Network downtime Friday June 6th, 12:00 UTC
by Mark Bergsma 05 Jun '08

05 Jun '08

Tomorrow, Friday June 6th, we will be performing maintenance on the network around 12:00 UTC. We'll do network migration in the form of a subnet/vlan split, and upgrade the firmware on our core router in one go. This means that most wikis/sites and services will be down for a couple of minutes only, if no unexpected problems occur. -- Mark Bergsma <mark(a)wikimedia.org> System & Network Administrator, Wikimedia Foundation

1 0

isActiveUser() and freeResult() both useless (was Re: [MediaWiki-CVS] SVN: [35867] trunk/phase3)
by Tim Starling 05 Jun '08

05 Jun '08

brion(a)svn.wikimedia.org wrote: > Revision: 35867 > Author: brion > Date: 2008-06-04 16:56:31 +0000 (Wed, 04 Jun 2008) > > Log Message: > ----------- > Revert r35857, 35858, 35859 for the moment. Some notes: > > * Calling $user->isActiveUser() looks a bit redundant. :) Consider either shortening it to isActive() or changing the last word to be clearer, say $user->isActiveEditor() > * $wgActiveUserEditcount <- consider fully casing here; "editcount" isn't a word. :D -> $wgActiveUserEditCount > * $oldTime is dumped into SQL without any escaping or quoting. This will happen to work on MySQL but will fail on PostgreSQL, and is generally a bad practice. Use addQuotes() to ensure the formatted timestamp string is escaped and quoted for your raw SQL construct > There's also the slight problem that any attempt to use this User::isActiveUser() for the bugs referenced (13225 and 13585) would cause instant death of the site due to DB overload. > * the database result object is not freed, which will leak resources if used in a long-running script > It turns out that was just a misunderstanding on the part of the people who wrote the mysql extension for PHP. There is no need to free the underlying data for resource objects manually. The PHP manual is incorrect and mysql_free_result() is useless. Underlying data for resources is deleted when the reference count for the resource goes to zero. This means assigning the variable to something else, or letting it go out of scope, works well enough. You can easily test this by comparing the memory usage of this: for ($i=0; $i<100000; $i++) { $res = $dbr->query('select * from revision limit 1000'); } with this: $res = array(); for ( $i=0; $i<100000; $i++) { $res[] = $dbr->query('select * from revision limit 1000'); } The former uses virtually no memory, the latter uses lots. -- Tim Starling

3 2

Re: [Wikitech-l] [Mediawiki-api] API action=edit problem
by MinuteElectron 05 Jun '08

05 Jun '08

Russell Blau wrote: > "MinuteElectron" <minuteelectron(a)googlemail.com> wrote: > > >> Marco Schuster wrote: >>> I suspect it are the +es in the "text" field, AFAIR these should be %20, >>> right? >> Perhaps; " " may be encoded as "+" in URL query strings, and most URL >> encoding functions do this. But in post strings maybe "+" is not >> acceptable. I will look to see if your suggestion fixes this. > > On http://www.epstone.net/~andrew/wiki/api.php, the query string with "+"s > in it works as expected. > > Russ Note the difference between "post" and "query" string -- I never said that "+" is not acceptable in query strings (quite the opposite, in fact). But I believe that in post strings "+" is not allowed, please correct me if I am wrong, of course. MinuteElectron.

3 2

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [35921] trunk/phase3/includes/DefaultSettings.php
by Simetrical 05 Jun '08

05 Jun '08

On Thu, Jun 5, 2008 at 5:59 AM, <ialex(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > Define $wgRateLimitsExcludedGroups to an empty array to avoid some PHP warnings, thanks to siebrand for reporting it. This is more than just PHP warnings, it creates a register_globals vulnerability. Don't ever use globals (even with isset() or other non-warning-raising uses) without initializing them, because they can be initialized from the URL on vulnerable installations. One nice thing about PHP 6 is we'll no longer have to worry about this. :)

1 0

TorBlock extension enabled
by Andrew Garrett 05 Jun '08

05 Jun '08

Hi all, After working through the code with Tim for a few hours this afternoon, the TorBlock extension has been enabled on Wikimedia. The TorBlock extension will override local IP blocks to provide a consistent treatment of tor. Currently, this involves allowing only logged-in users to edit, and requiring tor users to have 100 edits, and a 90-day-old account, prior to being autoconfirmed. Hopefully, this will provide a balance between allowing users to edit through tor without the difficult process of granting per-wiki IP block exemptions, and preventing pagemove vandals (such as the user known as 'Grawp' on English) from using Tor for vandalism and so on. I haven't yet implemented this, but I am interested in the prospect of marking Tor users as such on either CheckUser, or (privacy policy depending) on Recent Changes. -- Andrew Garrett

6 12

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [35683] trunk/phase3
by Brion Vibber 05 Jun '08

05 Jun '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 btongminh(a)svn.wikimedia.org wrote: > +* (bug 11659) Urldecode image names in galleries ... > + > + if ( strpos( $matches[0], '%' ) !== false ) > + $matches[1] = urldecode( $matches[1] ); > $tp = Title::newFromText( $matches[1] ); At this point it probably makes sense to go ahead and refactor this check & transformation into Title::newFromText itself -- it's already doing character reference decoding, so tossing in a URL decode doesn't sound too out of bounds, and it'll keep behavior consistent. - -- brion vibber (brion @ wikimedia.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhEPDMACgkQwRnhpk1wk47FGgCfTSR064X3UxIFfmLru0PllhNH fL0AoLCusRpsO81Flvn4MwF3X2RLTwsr =LYHo -----END PGP SIGNATURE-----

4 5

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [35812] trunk/phase3/skins/monobook
by Simetrical 04 Jun '08

04 Jun '08

On Tue, Jun 3, 2008 at 2:55 PM, <alnokta(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > Enable external link icon (along with other links icons too) again on RTL wikis after correcting its behavior. > This time it only adds 1.7kb of code. tested it on Arabic and English wikis. patch by Ahmad Sherif. Actually, it only adds 157 bytes to main.css, by my count. On Tue, Jun 3, 2008 at 3:19 PM, Rotem Liss <rotemliss(a)gmail.com> wrote: > This doesn't work properly in Firefox 2.0.0.14, see: > http://commons.wikimedia.org/wiki/Image:MediaWikiRTLExternalLinkIcon.png > > As far as I recall, this is a bug in Firefox. It may be fixed in Firefox 3. > > Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 It does work fine in Fx3, but I can reproduce the problem in Firefox 2. Do you have any more info on what causes the bug? It seems impossible to me that Firefox 2 doesn't support right-aligned background images. (Testing in Fx2 is a pain in the neck, thanks to the requirement to micromanage profiles and only have one Fx version open at once. Sigh.)

2 2

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [35769] trunk/phase3/skins/common
by Simetrical 03 Jun '08

03 Jun '08

On Mon, Jun 2, 2008 at 8:56 PM, <dantman(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > Cleaning out old comments and changing display of restricted pages. > Splarka suggested marking restricted pages with a star bullet rather than bolding them. I don't like this change. It's inconsistent with the way we usually do interfaces (we practically never use images to convey info), and the star is also a little off-center. It looks kind of ugly to me. It will break if users have images disabled, or of course if they're using a non-visual browser or one that doesn't support CSS: there's no graceful fallback. I suggest going back to bolding them, but rather than using <li class="mw-specialpagerestricted">, use <strong class="mw-specialpagerestricted"> so that the restricted pages are emphasized regardless of visual CSS support. This is more consistent with the way we normally distinguish elements of lists in the interface and also more accessible.

3 4

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l June 2008