Wikitech-l September 2008

wikitech-l@lists.wikimedia.org

85 participants
73 discussions

Extension to render Dia as a PNG
by Filipe Brandenburger 08 Sep '08

08 Sep '08

Hello, I need an extension to render Dia files as PNGs. I was using this one: http://www.mediawiki.org/wiki/Extension:Dia However I saw many problems with it, one of them being the wrong way to calculate the size of the image. I tried to fix it, but I did not find a good way to do it. The extension creates a new class that extends ImageHandler. In "doTransform" it calls the "dia" binary with special arguments to convert a .dia file to a .png file. Nothing wrong there. The problem is that it implements a "getImageSize" method where it implements a method that reads the XML file to try to "guess" the size of the image that "dia" will produce in "doTransform", and the problem is that it guesses wrong. I think that the best way to do it would be actually to first generate the PNG image by calling "dia", and then later returning the dimensions of this PNG by using "getimagesize". The problem is that, as far as I understood the source code, getImageSize will always be called before doTransform. In fact, it seems to me that the name of the PNG image that doTransform receives will start with the width of the image returned by getImageSize itself. I implemented a workaround^W^W a dirty hack to fix this issue. In getImageSize, I am calling "dia" (without the size argument) saving it to a tmpfile, then using "getimagesize" to get the dimensions of the PNG in the tmpfile, and then deleting the tmpfile. Then doTransform is called and it will basically do the same again, call "dia" to create the image that will be displayed. It works, but it calls "dia" twice, thus it is twice as slow as it should be. Is there a way around this? To actually generate the PNG image just once and calculate its size only once it is generated? Thanks! Filipe

3 5

MediaWiki 1.13.1 released
by Tim Starling 08 Sep '08

08 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 MediaWiki 1.13.1 is now available. This is a bugfix release. Changes since 1.13.0: * (bug 15460) Fixed intermittent deadlock errors and poor concurrent performance for installations without memcached. * (bug 13770) Fixed DOM module detection for installations with both dom and domxml. * (bug 15148) Fixed Special:BlockIP for PostgreSQL * Fixed SQLite support for installations without memcached. * Localisation updates, Achinese (ace) added. Full release notes: http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_13_1/phase3/RELEASE-NO… ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.1.tar.gz Patch to previous version (1.13.0), without interface text: http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.1.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.13/mediawiki-i18n-1.13.1.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.1.tar.gz.sig http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.1.patch.gz.sig http://download.wikimedia.org/mediawiki/1.13/mediawiki-i18n-1.13.1.patch.gz… Public keys: https://secure.wikimedia.org/keys.html SHA-1 checksums: 41ef2be8939aa27778d93923ba7005165b15876a mediawiki-1.13.1.tar.gz c07136dba374401da8a11c07f8221271b1354138 mediawiki-1.13.1.patch.gz b2876fb00c34e93915a480927798f26e211e679a mediawiki-i18n-1.13.1.patch.gz MD5 checksums: 8e640a5fdad027bd16cd305732f42e77 mediawiki-1.13.1.tar.gz 6afe4884065a3bd404d5ca8938723a63 mediawiki-1.13.1.patch.gz 265c5fa863ddc30524f436d1c67ae7bc mediawiki-i18n-1.13.1.patch.gz - -- Tim Starling -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIwrpidWgrCOij/sQRArdgAKC3ptCs+BNpB4y6arZapIMWgTxWGwCgp0f0 +PzVKcJWrbiaG84gl74Ki1Y= =5tyI -----END PGP SIGNATURE-----

2 1

Largish patch to add an extension for Redland-based RDF
by Mark 07 Sep '08

07 Sep '08

Hi all, A couple of months ago I more-or-less finished major work on this extension to add Redland RDF support and (I think) a pretty nice RDF api to Mediawiki. Then I got distracted by my paid job (we just did an ERP rollout). Anyhow, I haven't written much in the way of documentation for this thing yet, but I'd like to release it. Since it's extension code, and lives by itself there in extensions is it acceptable to just commit it, or should I file a feature request in Bugzilla, or is there some other procedure? thanks, -mark -- -- ================================================================= -- mark at geekhive dot net --

4 6

Wikipedia outage?
by Magnus Manske 06 Sep '08

06 Sep '08

I can't reach XX.wikipedia.org (any language) from the UK at the moment (neither browser nor ping). Same for wikibooks and commons. I can ping "wikipedia.org" fine, though. Just me? Magnus

2 1

Port to DB2 commit access and regression testing
by Leons Petrazickis 05 Sep '08

05 Sep '08

Hello, I am working on a port of MediaWiki to IBM DB2 (http://www.ibm.com/db2/express/) in my personal time. This is comparable to the ongoing projects to port MediaWiki onto MSSQL, SQLite, etc. DB2 is a robust database with a good reputation, and there are several projects I have in mind where it would be the most appropriate choice. I'm hoping to have for a functional, ready to run implementation in late September, early October. Could I have commit access permission as "leonsp"? My public SSH key is at http://lpetr.org/personal/leo-public.pub My other questions deals with testing. Is there any sort of a formal testing process that I should subject my code to before committing? The suite unders tests/ doesn't seem very exhaustive -- the database layer only tests the quoting function, etc. Should I just write my own test cases, as well use the wiki randomly to see if it holds up? Thanks, Leons Petrazickis http://lpetr.org/blog/

1 0

Re: [Wikitech-l] [Commons-l] Massive image loss
by jynus 05 Sep '08

05 Sep '08

On Friday 05 September 2008 14:26:54 Patricia Rodrigues wrote: > There's a list at > <http://commons.wikimedia.org/wiki/User:Patr%C3%ADciaR/missing_images> to > keep up with the ones that are recovered (Commons only). Multichill > suggested warning all uploaders to get the "own work" ones, at least. Good > news: there seems to be some images that were *not* lost after all; please > see > <http://commons.wikimedia.org/wiki/Commons:Village_pump#Massive_image_loss> > too. It seems that it only affected latest revision of each image. In some cases, older versions could be used as a last resource. Thanks for full-disclosure. -- Jynus

1 0

Re: [Wikitech-l] [Foundation-l] Massive image loss
by Husky 05 Sep '08

05 Sep '08

I think it would be very helpful to have a thumbnail gallery of all missing images. I'm sure people still have them lying around on their hard disks or somewhere on the internet. -- Hay / Husky On Fri, Sep 5, 2008 at 12:44 PM, John at Darkstar <vacuum(a)jeb.no> wrote: > Perhaps also add which pages the image was used at on the image list? > That way you increase the chance of people noticing images they have > uploaded. Also, could there be a split on which projects the images was > used at? > John > > Magnus Manske skrev: >> On Fri, Sep 5, 2008 at 11:11 AM, Tim Starling <tstarling(a)wikimedia.org> wrote: >>> This is a triple-crosspost. I suggest you reply to wikitech-l only. >>> >>> A mistake I made caused the loss of 496 full-resolution images from >>> Wikimedia servers. >>> >>> I have recovered as many images as I can, drawing on the following sources: >>> >>> * Squid cache (pmtpa, knams and yaseo) >>> * May 8 backup of some wikis on storage1 >>> * Duplicates with the same signature, found on the same or other wikis >>> >>> That brought the number lost down from about 3000 to the current 496. For >>> the remaining files, I made a copy of their thumbnail directories: >>> >>> http://upload.wikimedia.org/lost-image-thumb-backup/ >>> >>> A list of missing images can be found here: >>> >>> http://noc.wikimedia.org/~tstarling/missing-images-2008-09 >>> >>> If anyone has any ideas about where to find more backup files, I'd be >>> willing to hear them. Otherwise, the community will just have to reupload >>> as many as possible. >> >> At least one of them ( Clan_member_crest_badge_-_Clan_MacTavish.svg ) >> was reuploaded in a coincidence :-) >> >> How about a script adding a message to the talk page of the respective uploader? >> >> Magnus >> >> _______________________________________________ >> foundation-l mailing list >> foundation-l(a)lists.wikimedia.org >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l >> > > _______________________________________________ > foundation-l mailing list > foundation-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l >

1 0

Patch: redirect to login page and after login page
by lists.filbranden＠idilia.com 05 Sep '08

05 Sep '08

Hello, I have a private Wiki, in which access to any page requires authentication. I did that by using this configuration (as suggested in http://www.mediawiki.org/wiki/Manual:Preventing_access): $wgGroupPermissions['*']['read'] = false; $wgGroupPermissions['*']['edit'] = false; $wgGroupPermissions['*']['createaccount'] = false; I was annoyed by the fact that every time I accessed while not logged in I would get a "You must log in to view other pages" message, and then I would have to click on "log in" to go to the log in dialog, and then after the log in I would get a "You are now logged in" message and with a link to the page I originally wanted to see, and then I would have to click on this link again. So I decided to patch MediaWiki to transform those into redirects instead of pages with messages. While doing it, I decided to do it in a generic and configurable fashion so that, if you agree that this might be useful to others, you may incorporate it on the main code. This are the variables that I added to DefaultSettings.php: /** * Set the $wgRedirectMustLogin flag to skip the "You must log in to * view other pages." notice when you do not have enough rights to view * the page. Set the $wgRedirectLoggedIn flag to skip the "You are now * logged in to ..." notice after you log in successfully. * These are convenient in a private Wiki, if you also set * $wgGroupPermissions['*']['read'], ['edit'] and * ['createaccount'] to false. */ $wgRedirectMustLogin = false; $wgRedirectLoggedIn = false; If you set the first of them to true on your LocalSettings.php, it will skip the first page. If you set the second one of them to true, it will skip the page that comes after a successful login, and it will jump to the page you originally requested when you got the login dialog. I am sending the patch attached with this e-mail. I created the patch with a "svn diff" on the trunk of phase3. I tested it against MediaWiki 1.13, it applies cleanly and it works. I hope you find it useful and incorporate it to MediaWiki! Thanks, Filipe

4 3

Re: [Wikitech-l] [MediaWiki-CVS] SVN: [40398] trunk/extensions/LiquidThreads/Lqt.i18n.php
by Minute Electron 04 Sep '08

04 Sep '08

On Wed, Sep 3, 2008 at 9:32 PM, <david(a)svn.wikimedia.org> wrote: > Revision: 40398 > Author: david > Date: 2008-09-03 21:32:05 +0000 (Wed, 03 Sep 2008) > > Log Message: > ----------- > Reverted 40375 'lower case'. > > Modified Paths: > -------------- > trunk/extensions/LiquidThreads/Lqt.i18n.php > > Modified: trunk/extensions/LiquidThreads/Lqt.i18n.php > =================================================================== > --- trunk/extensions/LiquidThreads/Lqt.i18n.php 2008-09-03 21:28:24 UTC (rev 40397) > +++ trunk/extensions/LiquidThreads/Lqt.i18n.php 2008-09-03 21:32:05 UTC (rev 40398) > @@ -118,7 +118,7 @@ > 'lqt-read-message' => 'Read', > 'lqt-read-message-tooltip'=> 'Remove this thread from new messages. > It will still be visible on its original talk page.', > - 'lqt-read-all' => 'Mark all as read', > + 'lqt-read-all' => 'Mark All As Read', > 'lqt-read-all-tooltip' => 'Remove all threads from new messages. > They will still be visible on their original talk pages. > This operation is undoable.', > > > > _______________________________________________ > MediaWiki-CVS mailing list > MediaWiki-CVS(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mediawiki-cvs > Why has this been reverted? Most messages like this are in lower case and generally look better this way. MinuteElectron.

2 2

Handheld and print style overrides
by Brion Vibber 04 Sep '08

04 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've added support for MediaWiki:Handheld.css and MediaWiki:Print.css site-specific style additions for the handheld and printable styles. (bug 2899) I threw in some quick sample styles to flatten the layout tables on the English Wikipedia Main Page in handheld style; see my blog post on the matter for sample images in Opera's small screen mode: http://leuksman.com/log/2008/09/03/handheld-and-print-style-customization/ - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki/XOIACgkQwRnhpk1wk45kywCgkovDhyvY6OUs3qTjnaab5KU8 esUAoNmlbzp8HMNkjZvXzKumj+entM37 =X0ci -----END PGP SIGNATURE-----

1 1

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 September 2008