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
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 --
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
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/
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
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
>
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
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.
-----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-----