Wikitech-l April 2008

wikitech-l@lists.wikimedia.org

100 participants
97 discussions

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [33390] trunk/phase3
by Simetrical 16 Apr '08

16 Apr '08

On Tue, Apr 15, 2008 at 4:44 PM, <catrope(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > Adding CSS class for nested <fieldset>s. Nesting fieldsets used to cause a huge amount of whitespace between the parent and the child fieldset, this commit adds a class that circumvents this. > > Modified Paths: > -------------- > trunk/phase3/RELEASE-NOTES > trunk/phase3/includes/DefaultSettings.php > trunk/phase3/skins/monobook/main.css 1) Why can't you just use the selector "fieldset fieldset" to pick up nesting instead of adding yet another class? For that matter, there's enough support for appropriate selectors now that "fieldset > fieldset" would be fine, I think (since this is a minor aesthetic issue, IE6 users can live with it). 2) You don't seem to have actually added the class to any fieldsets . . .

2 1

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [33324] trunk/extensions/GlobalBlocking/GlobalBlocking.php
by Simetrical 16 Apr '08

16 Apr '08

On Mon, Apr 14, 2008 at 9:37 PM, <werdna(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > Fix up GlobalBlocking::purgeExpired() > - $dbw->delete( 'globalblocks', 'gb_expiry<'.$dbw->addQuotes($dbw->timestamp()), __METHOD__ ); > + $dbw->delete( 'globalblocks', array('gb_expiry<'.$dbw->addQuotes($dbw->timestamp())), __METHOD__ ); What's the difference? These do the same thing, don't they?

2 2

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [33404] trunk/phase3/includes
by Simetrical 16 Apr '08

16 Apr '08

On Tue, Apr 15, 2008 at 7:34 PM, <aaron(a)svn.wikimedia.org> wrote: > Log Message: > ----------- > * Allow for things that call addEntry() to pass in a DB object to make the action and logging be one transaction I've been told that this makes no difference. wfGetDB( DB_MASTER ) will apparently not begin a new transaction or connection or anything, if one already exists. It will just continue with the current one.

1 0

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [33375] trunk/phase3
by Roan Kattouw 16 Apr '08

16 Apr '08

ialex(a)svn.wikimedia.org schreef: > Revision: 33375 > Author: ialex > Date: 2008-04-15 17:32:23 +0000 (Tue, 15 Apr 2008) > > Log Message: > ----------- > (bug 13752) Section redirects now works again > <snip> > > + function followRedirect( $getFragment = false ) { > + if( $getFragment ) > + // We'll need to use the content of this page, as Article::getRedirectTarget() > + // now loads the data from redirect table, wich doesn't store the fragment > + $rt = Title::newFromRedirect( $this->getContent() ); > + else > + $rt = $this->getRedirectTarget(); > Wouldn't it be cleaner and more efficient to add a field to the redirect table that stores the fragment? Also, is followRedirect(false); (or followRedirect(); for that matter) ever really used? Roan Kattouw (Catrope)

2 1

OpenID
by Earle Martin 16 Apr '08

16 Apr '08

Hello, I was wondering if there are any plans to enable OpenID support (presumably building on http://www.mediawiki.org/wiki/Extension:OpenID) after the work on single sign-on is completed in the future. Best wishes, Earle. -- Earle Martin http://downlode.org/ http://purl.org/net/earlemartin/

10 13

JS Libraries in MediaWiki
by DanTMan 16 Apr '08

16 Apr '08

Erm... never, EVER! try to write a long e-mail on a Wii... Especially when occasionally your Wi-Fi disconnects which ends up killing everything you've written. Well onto the topic... I've notice that the number of extensions using JS Libraries has increased recently. Notably Semantic MediaWiki/Semantic Forms, and SocialProfile. Additionally I was contracted to create a new mp3 playing extension because all the current ones break the lines (The requester wants to be able to let the music play inline, basically beside a normal link to an audio file, instead of needing a plugin or something on their computer, or a big player that takes up unneeded space)... So I found the mp3inline <http://pjoe.net/software/mp3inline/> Wordpress plugin, and intend to adapt some of it into a MediaWiki extension which will automatically let audio links be playable inline with an icon located cleanly beside the link. Of course, the note on this topic is that the player uses Scriptaculous which is another JS Library which would be put into MW. Various extensions use different methods of including the libraries they need. Mostly just requiring the user to find a way to put it in. However SocialProfile includes a YUI extension which can be used. This extension however is basically just a short bit that includes a single script which is basically a minified part of the basic required YUI code, and an unminified version of the animation package (Why they used the minified version for one half, and the full version of another part is beyond me though)... The biggest issue with any of these that I see... Is load time. For all of them you need to add a bunch of script tags to the page for them to work, and suddenly you drastically increase the number of HTTP calls for stuff on your site. Since things are growing, I was thinking it would be a good idea to add some stuff to core to allow extensions to add use of JS libraries in an intuitive way. I started an allinone.php extension awhile ago (inspired by Wikia's allinone.js idea) and was thinking I should probably rewrite it and make something good for core. The idea is to have a single script in the page which contains all of the needed JS Libraries... And even wikibits.js inside it... All of them minified to compact space... Of course, if you need to debug any errors or anything, simply reload the page with &allinone=0 and the system automatically includes the separate non-minified files in individual script tags for debugging. Perhaps even a no-allinone preference for those doing heavy debugging in areas where they have a post request they can't add &allinone=0 to. Additionally, the system would have a understanding of the structure of a js library. Basically, a sort of definition module would be created for each library that people may use (YUI, jQuery, Scriptaculous, Prototype, etc...) which would outline things like the different parts of the system (Core file, individual parts of the system like ui or other things only needed sometimes, separation of full/minified files (perhaps a notion of debug like what YUI has), and files like YUI's utilities.js or yahoo-dom-event.js which are minified versions of a grouping of various parts of the library.) And using calls like, say... Making the thing handling this called "JSLibs" just for this example... JSLibs::addUse( 'YUI', 'animation' ); which would note that YUI's animation bit is required for use in the page. And so it'll automatically know that the 'yahoo' bit is also needed, additionally if various other things like the dom, event, etc... bits are needed it'll automatically use one of the combined files instead of individual ones. Of course, there is a little bit of optimization by use that things using the libs need to do... Primarily this is because some things are needed at some times, and not at others... But if you don't define good times that it should be included, then the number of varying types of allinone groups you have increases and you end up with more stuff for the browser to cache and more requests to the server. So basically: * Skins... For the JS Libraries that they require, they should include the libraries all the time when inside of that skin. (There'll be code to let Skins define what they need inside of the definition of where to put the stuff) * Site scripts... When JS Libraries are wanted for site scripting, the stuff should be included using calls inside of LocalSettings.php and included all the time. * Extensions... It depends on what kind of extension... ** For low use things inside articles, like perhaps a TagCloud which is likely only to be used on a few major pages, this should be only included when needed (ie: The thing needing it is parsed into existence) ** For special page stuff, and things meant for only edit pages and the like the libraries should always be included while on these pages, but not in general while reading articles. ** For high use things, like SMW's attributes, factboxes, and such... The libraries should be included 100% of the time... Of course, if you really want you can put in some exclusions for when on special pages... But these are used a high amount of times, and can add up the number of variations easily. If you don't understand what I'm meaning... It occurs when multiple extensions of different types are used... For example... Say we had a low use tag cloud, and something like SMW which included dynamic stuff every time an attribute was used... If the tag cloud loaded only when needed, and SMW included only when an attribute was used... then we'd have the variations: * One for when tag cloud, and SMW attributes are used (main pages mostly) * One for when tag cloud isn't used, but SMW attributes are used (most article pages) * One for when tag cloud is used, but SMW attributes are not (extremely rare case) * And one for when the tag cloud isn't used, and SMW attribues are not (another rare case) Those last two shouldn't exist... They only exist because one extension didn't define when stuff should be included right. If the example SMW had loaded it's libraries 100% of the time when on articles because of the high use of it... Then there would only be two variations, one for with tag cloud, and one for when it's not... Another issue, is minification... Not everything comes with a minified counterpart... I was hoping to make this something which could be done automatically. However, I found out that most of the minification programs that seam to be good, run in other languages like Java, rather than having PHP ports. So perhaps a toolserver service would be nice, one allowing extension authors to submit a page of code in a form to the toolserver, and have it return them a minified version using the best program for the job, that way people developing scripts and stuff for use can distribute the extension with pre-minified code, rather than requiring the people using the extension to download something to minify the code on their own. ^_^ And yes, of course we'd have a minified version of wikibits.js... We include it 100% of the time, why waste bytes on the comments and whitespace? Especially when using a non-minified/minified split allows us to put nice literate documentation inside of the code, while still making end use of something extremely compact. -- ~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)

4 8

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [33381] trunk/phase3/includes
by Roan Kattouw 15 Apr '08

15 Apr '08

brion(a)svn.wikimedia.org schreef: > Revision: 33381 > Author: brion > Date: 2008-04-15 18:11:28 +0000 (Tue, 15 Apr 2008) > > Log Message: > ----------- > Revert some chunks of r33133 and r33375: > * Let followRedirect() *always* work correctly by working from the article text. > * This ensures that we're not falsely looking up data from another version and that we're not missing interwik and fragment data. > > Should clean up both bug 13754 (editing old version of redirect sometimes gives the target page text) > and bug 13752 (bugs with fragments and probably interwikis in redirect target). > > Haven't been able to repro 13754 at home though, so we'll see. :O This is even crazier than r33375 (no insult to either committer): we have a redirect table to fetch redirect targets efficiently, and we're not actually *using* it anywhere. Bugs 13752 and 13754 should be fixable without reverting to the old (and inefficient) behavior (possibly with a schema change to the redirect table, as I suggested in response to r33375). Roan Kattouw (Catrope)

2 3

How do the MediaWiki pros keep their PHP pretty?
by jidanni＠jidanni.org 15 Apr '08

15 Apr '08

How do the MediaWiki pros keep their PHP pretty? Do they use http://en.wikipedia.org/wiki/Prettyprint#Code_Beautifiers ?

6 9

GlobalBlocking extension - announcement, and review
by Andrew Garrett 14 Apr '08

14 Apr '08

Hi! I'd like to announce (a bit late) the availability of the GlobalBlocking extension[1]. The GlobalBlocking extension has been written to allow blocks to be made which apply across all Wikimedia wikis. It is anticipated that it will be used by stewards, or admins on meta, for blocking crosswiki vandals, spammers, et cetera. Currently, the interface for this allows blocks to be made on single IP addresses, although rangeblocks are planned, and I think somebody wanted to work on SUL global-user blocks. I'd also like to solicit code review of this extension. It's already been comprehensively reviewed by Tim Starling, but, given the size of it, I'm sure the various sysadmins would be much more comfortable enabling it on Wikimedia if there'd been a few pairs of eyes over it. The appropriate bug for enabling this extension on Wikimedia is bug 8707[2]. Thanks. [1] http://www.mediawiki.org/wiki/Extension:GlobalBlocking [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=8707 -- Andrew Garrett

3 4

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [33133] trunk/phase3
by Brion Vibber 14 Apr '08

14 Apr '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 catrope(a)svn.wikimedia.org wrote: > Log Message: > ----------- > Committing patch for bug 10931, which also fixes bug 13651. For a > detailed explanation of what this commit does, see bug 10931 comment #24 For future reference, please try to include the actual details *in* the commit message... It's okay to make it as long as it needs to be! If you do point to external documentation instead of keeping the details in one place, put in a URL if possible to make it easy to jump right there. - -- brion vibber (brion @ wikimedia.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkf/qCMACgkQwRnhpk1wk451jgCeJqKfQYioBg2dqLIxs9BfiFFf MoYAnimdm4BEOxccNC5UE4krnyXZZT1X =eyxJ -----END PGP SIGNATURE-----

4 6

← 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 April 2008