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?
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.
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
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
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.
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. :)
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
-----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-----
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.)
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.