headers
jidanni | 1 May 2008 04:34
Favicon
Gravatar

Re: Special::Statistics Page Problem

What bugs me is even if one explicitly does $wgDisableCounters=true in
LocalSettings.php, Special:Statistics still insists on reporting the
obviously now invalid data! https://bugzilla.wikimedia.org/show_bug.cgi?id=5619
Permalink | Reply | 501 comments |
headers
Sam Odio | 1 May 2008 05:03

Problems with resizing images - /usr/bin/convert

I recently upgraded our mediawiki server, now when uploading &  
resizing images, users receive the following error:
Error creating thumbnail: /usr/bin/convert: error while loading shared  
libraries: libSM.so.6: failed to map segment from shared object:  
Cannot allocate memory

The following line can recreate the error:
[[image:image.jpg|125px]]

While this line works fine:
[[image:image.jpg|left]]

(See http://bluwiki.org/go/User:Sam_Odio/test for an example)

Convert seems to work fine from the terminal: # convert image.png - 
resize 100  image-tiny.png
returns the resized image...

Google hasn't turned up anything... any ideas?

thanks in advance...

-s
Permalink | Reply | 1 comment |
headers
River Tarnell | 1 May 2008 08:00

Welcome to mediawiki-l (weekly posting)

Welcome to mediawiki-l.  This mailing list exists for discussion and questions 
about the MediaWiki software[0].  Important MediaWiki-related announcements 
(such as new versions) are also posted to this list.

	Other resources.

If you only wish to receive announcements, you should subscribe to 
mediawiki-announce[1] instead.

MediaWiki development discussion, and all Wikimedia technical questions, should 
be directed to the wikitech-l[2] mailing list.

Several other MediaWiki-related lists exist:
  - mediawiki-api[5] for API discussions,
  - mediawiki-enterprise[6] for discussion of MediaWiki in the enterprise,
  - mediawiki-cvs[7] for notification of commits to the Subversion repository,
  - mediawiki-i18n[8] for discussion of MediaWiki internationalisation support,
  - wikibugs-l[9] for notification of changes to the bug tracker.

	List administrivia (unsubscribing, list archives).
	
To unsubscribe from this mailing list, visit [12].  Archives of previous postings 
can be found at [3].

This list is also gatewayed to the Gmane NNTP server[4], which you can use to 
read and post to the list.  

	Posting to the list.

Before posting to this list, please read the MediaWiki FAQ[10].  Many common
(Continue reading)

Permalink | Reply | 0 comments |
headers
Platonides | 1 May 2008 12:26
Picon

Re: Problems with resizing images - /usr/bin/convert

Sam Odio wrote:
> I recently upgraded our mediawiki server, now when uploading &  
> resizing images, users receive the following error:
> Error creating thumbnail: /usr/bin/convert: error while loading shared  
> libraries: libSM.so.6: failed to map segment from shared object:  
> Cannot allocate memory

You can try rebuilding imagemagick using static libraries.

> The following line can recreate the error:
> [[image:image.jpg|125px]]
> 
> While this line works fine:
> [[image:image.jpg|left]]
> 
> (See http://bluwiki.org/go/User:Sam_Odio/test for an example)

Probably the left thumbnail was already present, so it's not being 
generated.

> Convert seems to work fine from the terminal: # convert image.png - 
> resize 100  image-tiny.png
> returns the resized image...

Perhaps you have several omagemagickl installs. Does /usr/bin/convert 
image.png - resize 100 image-tiny.png also work?

> Google hasn't turned up anything... any ideas?
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Barrett | 1 May 2008 14:55
Favicon

Best practices for extensions surviving MediaWiki updates?

What are the best practices for coding a wiki extension to survive MediaWiki updates?  As a software
engineer, I imagine you'd want to:

-       Use the standard file/class layout prescribed in http://www.mediawiki.org/wiki/Manual:Extensions#Writing_Extensions.
-       Stick to calling a class's public methods, rather than accessing its $mFoobar members, whenever possible
-       Don't depend on implementation details of MW's methods, just the public interfaces
-       Call methods on the extension's $parser parameter, rather than $wgParser, when possible
-       Avoid modifying MediaWiki core code
-       Don't name your global variables beginning with "$wg" to avoid clashes (present and future)
-       Name your classes so they can't clash with MediaWiki's (past and future) -- maybe prefix their names with
something unique, at least until PHP 6 namespaces are widespread
-       Don't hard-code English text, define system messages

I didn't see documentation on this sort of thing beyond what's on
http://www.mediawiki.org/wiki/Manual:Extensions. Are there other best practices?

Thanks,
DanB
Permalink | Reply | 8 comments |
headers
Alain van Acker | 1 May 2008 15:17
Picon
Favicon

Monobook skinning


Hi,

I removed the <div class="portlet" id="p-logo"> from the MonoBook.php 
and would like to top align the <div class='portlet' id='p-Navigation'> with
<div id="content">.

The only work around I can find is to set the top margin on the .portlet 
to -2.5em which isn't very graceful. Something is preventing the top 
alignment, but I can't figure out what. Any hints more than welcomed.

Alain
Permalink | Reply | 1 comment |
headers
Michael Daly | 1 May 2008 17:31

Re: Best practices for extensions surviving MediaWiki updates?

Daniel Barrett wrote:

> -       Stick to calling a class's public methods, rather than accessing its $mFoobar members, whenever possible
> -       Don't depend on implementation details of MW's methods, just the public interfaces
> -       Call methods on the extension's $parser parameter, rather than $wgParser, when possible

These are just proper OO practice, not specific to MW.  Good coding 
practice is good coding practice. :)

Mike
Permalink | Reply | 5 comments |
headers
Michael Daly | 1 May 2008 17:35

Re: Monobook skinning

Alain van Acker wrote:

> The only work around I can find is to set the top margin on the .portlet 
> to -2.5em which isn't very graceful. Something is preventing the top 
> alignment, but I can't figure out what. Any hints more than welcomed.

Likely some absolute positioning somewhere is mucking it up.  I created 
a skin based on Monobook and removed all absolute positioning and used 
just default relative positioning (i.e. no explicit _relative_ in the 
CSS).  It provides a more flexible page design and correctly handles 
text resizing in browsers.

Mike
Permalink | Reply | 0 comments |
headers
Daniel Barrett | 1 May 2008 18:03
Favicon

Re: Best practices for extensions surviving MediaWiki updates?

I agree, that's how I dreamed up the list of practices.  At the same time, MW does expose classes' $mFoobar
members publicly, e.g., Parser->$mOutput.

DanB

-----Original Message-----
These are just proper OO practice, not specific to MW.  Good coding
practice is good coding practice. :)

Mike
Permalink | Reply | 4 comments |
headers
Jim Hu | 1 May 2008 21:30
Picon
Favicon
Gravatar

Re: EcoliWiki

Sounds reasonable.  This translates to 20% FTE, right?

Jim

On Apr 28, 2008, at 4:52 PM, Dave Clements wrote:

> Hi Jim,
>
> I have been meaning to e-mail you for a week.  I talked to Hilmar and
> Todd about allocating 10% of my time to the list of items below.  They
> agreed that this was completely appropriate.
>
> I propose that I allocate 2 adjacent days every two weeks that are
> explicitly allocated for GoNuts, EcoiWiki, TableEditor, ... (Gnewte!).
> I'm guessing that given the usual fires that come up in this job,
> I'll actually be able to allocate ~50% of each day to those tasks.
> I'm also guessing that Gnewte work will start to creep in to the other
> 8 days over time.
>
> I'd like to try that as an opening strategy and see how it goes.  I'm
> open to other approaches.  I'd like to start with this Thursday and
> Friday.  Is there anything in particular you would like me to start
> on?
>
> And, also, would you like to start receiving my enthralling bi-weekly
> status reports?  One is due out this Friday.
>
> Thanks for your patience,
>
> Dave C.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane