Hi,
On Mon, 2013-07-01 at 20:54 -0300, Aran wrote:
My wiki's giving an error generating SVG thumbnails, e.g.
Cannot parse integer value '-h214' for -w
Does this refer to creating bitmap thumbnails from SVG files? In that
case, which SVGConverter is used to generate thumbnails?
andre
--
Andre
This is most likely bug 45054, fixed in MediaWiki 1.21. It has a rather simple
workaround, too, see https://bugzilla.wikimedia.org/show_bug.cgi?id=45054 .
--
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 01/07/13 23:21, Nicolas Torzec wrote:
Hi there,
In principle, I understand the need for binary formats and compression in a
context with limited resources.
On the other hand, plain text formats are easy to work with, especially for
third-party users and organizations.
Playing the devil
Στις 02-07-2013, ημέρα Τρι, και ώρα 11:47 +0100, ο/η Neil Harris έγραψε:
The simplest possible dump format is the best, and there's already a
thriving ecosystem around the current XML dumps, which would be broken
by moving to a binary format. Binary file formats and APIs defined by
code
Yep that's my problem, thanks a lot :-)
On 02/07/13 07:28, Bartosz Dziewoński wrote:
This is most likely bug 45054, fixed in MediaWiki 1.21. It has a
rather simple workaround, too, see
https://bugzilla.wikimedia.org/show_bug.cgi?id=45054 .
___
Hi Guys,
I've just upgraded my wiki from 1.19.2 to 1.21.1 to fix the SVG
rendering problem which now is all fine, but now my Math rendering has
broken. I'm getting the following error:
Failed to parse (PNG conversion failed; check for correct installation
of latex and dvipng (or dvips + gs +
Hey,
Over the past few months a number of people have been poking at Composer
[0] support for MediaWiki [1]. Today I had a look at this and found that
though we are close to getting this to work, there are a few remaining
problems to be tackled.
1. MediaWiki needs to load the composer autoloader
PHP codestyle question re. isset( $array['key'][0] ) versus
array_key_exists( 0, $array['key'] )
On a recent patch [1], we had a discussion what is - or may be - better
* isset( $array['key'][0] )
* array_key_exists( 0, $array['key'] )
This is still unclear after consultation of these
On Tue, Jul 2, 2013 at 9:40 AM, Thomas Gries m...@tgries.de wrote:
PHP codestyle question re. isset( $array['key'][0] ) versus
array_key_exists( 0, $array['key'] )
On a recent patch [1], we had a discussion what is - or may be - better
* isset( $array['key'][0] )
* array_key_exists( 0,
On Wed, Jul 3, 2013 at 12:47 AM, Brion Vibber bvib...@wikimedia.org wrote:
On Tue, Jul 2, 2013 at 9:40 AM, Thomas Gries m...@tgries.de wrote:
PHP codestyle question re. isset( $array['key'][0] ) versus
array_key_exists( 0, $array['key'] )
On a recent patch [1], we had a discussion what is -
Tim
This sounds great. I've always felt the RFC process was a bit of a
black box of no return. I think regular triage of these and
closing/progressing these is much needed and will be a hugely positive
thing.
I'm looking forward to seeing this progress!
On Mon, Jul 1, 2013 at 10:03 PM, Tim
I endorse this message as well. We should start taking ownership and
shepherding the RFCs through to either completion or rejection with good
reasons. I'll be tearing myself away from mobile apps fun a little to make
more time for this. :)
-- brion
On Mon, Jul 1, 2013 at 10:03 PM, Tim Starling
On Mon, Jul 1, 2013 at 10:15 PM, Daniel Friesen
dan...@nadir-seen-fire.comwrote:
How are you dealing with extensibility?
We need to be able to extend the format. The fields of data we need to
export change over time (just look at the changelog for our export's XSD
file
Am 02.07.2013 18:47, schrieb Brion Vibber:
On Tue, Jul 2, 2013 at 9:40 AM, Thomas Gries m...@tgries.de wrote:
PHP codestyle question re. isset( $array['key'][0] ) versus
array_key_exists( 0, $array['key'] )
On a recent patch [1], we had a discussion what is - or may be - better
* isset(
On Tue, Jul 2, 2013 at 2:18 PM, Petr Onderka gsv...@gmail.com wrote:
Unless I'm mistaken, Liquid Threads don't have much of a future and are
used only on few wikis like mediawiki.org.
Does anyone actually use this information from the dumps?
LiquidThreads is an extension. I don't think
There is one other difference that has not been pointed out yet. Consider
the following:
$array = null;
array_key_exists( 0, $array['key'] );
isset( $array['key'][0] );
In this case, array_key_exists will cause an error, because $array['key']
doesn't exist, but isset() won't because it doesn't
On Tue, Jul 2, 2013 at 12:30 PM, Jeroen De Dauw jeroended...@gmail.comwrote:
It also needs to happen after the start of LocalSettings,
since some extensions need the core configuration to be set already or
require the user to define things before they get included.
This is an issue with the
I've found that the logged shell command actually does execute properly
and creates the .png when executed manually from shell - even when I
execute it as the www-data user that the web-server runs as.
But from the wiki it creates the tmp/hash.tex file, but not the png, and
there's nothing logged
Hey,
This is an issue with the extensions. The expectation for extensions is
that when the extension file is included MediaWiki is not set up. If an
extension needs to do things *after* MW is set up, it should be adding a
callback to $wgExtensionFunctions, which is called from the end of
Le 02/07/13 18:40, Thomas Gries a écrit :
* isset( $array['key'][0] )
* array_key_exists( 0, $array['key'] )
isset() acts on the value while the second look for a key. So they are
slightly difference.
I use array_key_exists() which is explicit and well known. I tend to
forget isset() is
Hello,
AbuseFilter does not match word boundaries in devanagari script which is
logged at https://bugzilla.wikimedia.org/46773 (has some unit test
result attached).
The root cause is that the regex pattern are not in unicode mode ('u'
regexp flag) and thus \b is being dumb.
The fix would be
On Tue, 02 Jul 2013 09:30:57 -0700, Jeroen De Dauw
jeroended...@gmail.com wrote:
2. Installing extensions leaves the composer.json file modified.
When installing one or more extensions via Composer, they will get added
to
the require section in composer.json. composer.json is not in the
On Tue, Jul 2, 2013 at 4:22 PM, Daniel Friesen
dan...@nadir-seen-fire.comwrote:
On Tue, 02 Jul 2013 09:30:57 -0700, Jeroen De Dauw jeroended...@gmail.com
wrote:
2. Installing extensions leaves the composer.json file modified.
When installing one or more extensions via Composer, they will
On Tue, 02 Jul 2013 17:27:50 -0700, Erik Bernhardson
ebernhard...@wikimedia.org wrote:
On Tue, Jul 2, 2013 at 4:22 PM, Daniel Friesen
dan...@nadir-seen-fire.comwrote:
On Tue, 02 Jul 2013 09:30:57 -0700, Jeroen De Dauw
jeroended...@gmail.com
wrote:
2. Installing extensions leaves the
On Tue, Jul 2, 2013 at 7:22 PM, Daniel Friesen
dan...@nadir-seen-fire.comwrote:
Another one is extension assets. Have you dealt with the fact that MW
doesn't have a proper path to serve the css/js in debug mode, images to IE,
and other assets that an extension needs.
Installing to custom
On Tue, Jul 2, 2013 at 5:56 PM, Daniel Friesen
dan...@nadir-seen-fire.comwrote:
I do not consider this a case of NIH. Composer is NOT an attempt by the
PHP community to provide a way to mange their own plugins. Composer is an
attempt by the PHP community to let PHP applications and libraries
Jon Robson wrote:
This sounds great. I've always felt the RFC process was a bit of a
black box of no return. I think regular triage of these and
closing/progressing these is much needed and will be a hugely positive
thing.
It's only a black box of no return in the sense that creating an RFC on
27 matches
Mail list logo
