Wikitech-l July 2006

wikitech-l@lists.wikimedia.org

96 participants
149 discussions

by Tim Starling

Stub globals are an idea I came up with to migrate from global dependant code to lazy module initialisation in a fairly painless way. The general idea is: class StubClass { function __call( $name, $args ) { global $wgSomeObject; if ( get_class( $wgSomeObject ) != 'RealClass' ) { $wgSomeObject = new RealClass; } return call_user_func_array( array( $wgSomeObject, $name ), $args ); } } $wgSomeObject = new StubClass; This turns out to be quite robust and effective, and I've implemented it in my working copy for $wgLoadBalancer, $wgContLang, $wgUser, $wgOut, $wgParser, $wgMessageCache and $wgAuth. I've managed to arrange it so that all of these globals make it out of Setup.php without being accessed. $wgTitle and $wgArticle have simply been replaced by null until after Setup.php, the exception handling code can now deal with this. This provides a massive time saving for lightweight requests on systems with no opcode cache. My own desktop computer is one such system, and 304 "not modified" responses are 2-3 times faster than they were before. Other requests which benefit are query.php, action=raw and command line scripts such as eval.php. Parser cache hits load pretty much everything, so they don't really benefit. In my post title "Ideas for faster MediaWiki startup", I also described a change to modules and extensions, allowing their initialisation to be deferred. This has not been done yet, so at the moment, many extensions will access global variables on startup and thus load large amounts of code. The benefit above thus mainly applies to installations with no extensions. However, everything benefits from the message cache that I described in my previous post. Here is the current working diff with both of those changes included: http://noc.wikimedia.org/~tstarling/messages-and-stub-globals.diff File size is 196 KB. -- Tim Starling

17 years, 10 months

How to tell if a Feed is being requested?

by Peter Adams

Hi Folks - Is there a global that tells one if the request is for an RSS/Atom feed? I'm hoping to avoid looking for $_GET['feed']... Thanks in advance. -P- /** * Peter Adams <peter(a)openwebanalytics.com> * * Open Web Analytics - the open source web analytics framework. * Blog >> http://www.openwebanalytics.com/ * Wiki >> http://wiki.openwebanalytics.com */

17 years, 10 months

MediaWiki automated test run failure 2006-07-17

by brion＠pobox.com

An automated run of parserTests.php showed the following failures: Running test Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)... FAILED! Running test Link containing double-single-quotes '' (bug 4598)... FAILED! Running test Template with thumb image (wiht link in description)... FAILED! Running test message transform: <noinclude> in transcluded template (bug 4926)... FAILED! Running test message transform: <onlyinclude> in transcluded template (bug 4926)... FAILED! Running test BUG 1887, part 2: A <math> with a thumbnail- math enabled... FAILED! Running test Language converter: output gets cut off unexpectedly (bug 5757)... FAILED! Running test HTML bullet list, unclosed tags (bug 5497)... FAILED! Running test HTML ordered list, unclosed tags (bug 5497)... FAILED! Running test HTML nested bullet list, open tags (bug 5497)... FAILED! Running test HTML nested ordered list, open tags (bug 5497)... FAILED! Running test Parsing optional HTML elements (Bug 6171)... FAILED! Running test Inline HTML vs wiki block nesting... FAILED! Running test Mixing markup for italics and bold... FAILED! Running test 5 quotes, code coverage +1 line... FAILED! Running test HTML Hex character encoding.... FAILED! Running test dt/dd/dl test... FAILED! Passed 409 of 426 tests (96.01%) FAILED!

17 years, 10 months

Ideas for faster MediaWiki startup

by Tim Starling

Client-side applications are becoming more important. There are plans for using AJAX, and request rates for machine interfaces such as query.php, action=raw and Special:Export are growing. These lightweight requests are often predominantly composed of startup costs. Profiling on Wikimedia currently gives 47ms for startup, including at least 8ms for extensions. This is too slow. My ideas for fixing this are as follows: * Pervasive lazy initialisation. Remove $wgUser, $wgLang and $wgContLang, replace them with wfGetUser(), wfGetLang() and wfGetContLang(). This brings them into line with the successful wfGetDB() interface. Simply returning the variable would be done by those functions, if it doesn't exist, then execution would pass to the relevant autoloaded module for initialisation. The same can be done for $wgTitle, $wgParser, $wgOut, $wgMessageCache... pretty much all the object globals. A version-independent accessor would be put in ExtensionFunctions.php, to support multi-version extensions. By deferring everything, we allow lightweight requests to get by without ever initialising a user object, or loading a language file. * Cached module registration. Each module provides a module.php in a unique directory, which sets a $module variable to an array describing its capabilities. Capabilities would include: * Autoloadable classes and their locations * Hooks * Special pages * Magic words * Messages * Parser elements and functions The registered callback functions would all be static functions in autoloaded classes. To register modules at startup, a function will be called with an array listing the extension directories. This function will load the module.php files and merge the arrays, creating a master hashtable of capabilities and their locations. And crucially, this hashtable can be cached. This reduces average-case module initialisation from tens of lines of code per module to a single unserialize() for all modules. The old extension setup files would be kept for backwards compatibility, but would never be loaded unless the extension explicitly does so when it obtains control via a hook. * Bring Wikimedia's configuration cache into the committed codebase, and extend its abilities. Incorporate settings from DefaultSettings.php into the SiteConfiguration object, thus allowing them to be cached, avoiding a DefaultSettings.php load. The bulk of the default LocalSettings.php can be moved to a separate file, analogous to Wikimedia's InitialiseSettings.php. Thus in the typical case, all configuration, except programmatic modifications, will be done by a single unserialize plus a few stat calls. The general idea is to slash the number of lines of code loaded on startup to a tiny fraction of what it is now. Any thoughts? -- Tim Starling

17 years, 10 months

The Double Edit Trick (was: Borderline notable bios (yes, again))

by Ilmari Karonen

[Crossposted to wikien-l and wikitech-l.] Guy Chapman aka JzG wrote: > On Wed, 12 Jul 2006 17:09:22 -0500, Jimmy Wales <jwales(a)wikia.com> > wrote: > >>When I met Seth, he explained to me how this happened. The vandal used >>a classic trick... the double edit. The first edit was the vandalism, >>the second edit was innocent. So if you checked the diffs incorrectly, >>you would not see the attack paragraph. > > Hell yes. I see that a lot. Presumably this is something that could be countered by technical fixes. Admin rollback already automatically reverts multiple consecutive edits from the same editor; the manifest usefulness of this feature would be one more argument for granting rollback privileges to non-admins. But _seeing_ the sum of the edits should definitely be made easier: I think that the diff links in the watchlist, at least, should automatically show all the combined edits made by the last editor. It'd also be nice if the diff view showed how many edits there are between the two revisions being compared; besides being, IMO, a good thing in general, this would help make the change I proposed above less confusing. I don't think this should be particularly hard to implement. What I'd like is comments on whether this would actually be a good idea, and suggestions on where else, besides the watchlist, it should be applied. (At the risk of [[WP:BEANS]], I'd like to note that there is another related problem; if a vandal blanks the section of an article containing the interlanguage links, a bot will often quickly show up to restore them, as a side effect hiding the vandalism itself from the watchlist. Making the bots smarter would help, but I'm not sure what can be done to solve this problem in general, beyond hiding bot edits from the watchlist by default and making the feature actually do what it should do -- i.e. show the last non-bot edit instead.) -- Ilmari Karonen

17 years, 10 months

How to change default options for blocking users?

by Walter Vermeir

Thanks to Tim bug 550 is fixt and now it is possible to be more specific who and what you like to block. To specify this there are 2 tick boxes with these default settings; [ ] Block anonymous users only [X] Prevent account creation I find these are not good default settings. The default setting should be the softest block possible. And that is only a block for anonymous users and account creation allowed. So that this would be the default setting; [X] Block anonymous users only [ ] Prevent account creation Can this be specified somewhere by a sysop on the wiki? -- Contact: walter AT wikizine DOT org Wikizine.org - news for and about the Wikimedia community

17 years, 10 months

Parsing Wikitext in perl

by Jay R. Ashworth

So, I'm about to head out on a long dark trip in to WebGUI land, and I hate writing lots of HTML just as much as the next guy. So my goal is to find a chunk of perl that parses (some subset) of MW wikitext that I can slide into WebGUI. 1) While I know there are some alternative parsers that already exist, is there anyone floating around in here with any experience patching any of the ones written in perl into other code? 2) How much of MWT do they parse? How much do I really need? (Yeah, I know; how the hell do *you* know? :-) 3) Has anyone ever done a (semi-)formal specification of MWT? 4) Am I crazy? Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 Fanfic: read enough, and you'll loose your mind. --me

17 years, 10 months

MediaWiki automated test run failure 2006-07-16

by brion＠pobox.com

17 years, 10 months

Re: [Wikitech-l] Custom left nav per namespace?

by Adil W. Ahmad

Hi,A custom left nav per namespace is fairly simple to implement if you're willing to program in php. I have done something similar for our internal wiki, and it requires some patience but it can be done.One clue: use $wgTitle->getNamespace(); Let me know if you have questions...A

17 years, 10 months

Tell MW not to share extension's db connection

by Peter Adams

Hi all - I'm writing an analytics package for MediaWiki and am running into an issue where even though my extension creates a separate mysql connection, MW is catching the DB errors and throwing up its stack trace. I'm running php 4.4.2 and MW 1.6.3. It appears that MW is trying to use the mysql connection that my extension has established. a quick look at the MW database.php suggests that this might be an optimization. Could anyone provide some guidance on how to best avoid this if you are writing an extension that needs to make a mysql connection? Thanks, -P- /** * Peter Adams <peter(a)openwebanalytics.com> * * Open Web Analytics - the open source web analytics framework. * Blog >> http://www.openwebanalytics.com/ * Wiki >> http://wiki.openwebanalytics.com */

17 years, 10 months

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

Jump to page:

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 July 2006