Talk:MediaWiki 1.19

Jump to: navigation, search
Start a new discussion


Thread titleRepliesLast modified
Thumbnails didn't work since Update to 1.195403:02, 7 February 2014
Release notes?121:49, 4 July 2013
Wiki trouble3101:56, 26 June 2013
UML extension still support?017:06, 6 June 2013
login doesn't work since update.305:19, 23 May 2013
Fehler beim Erstellen des Vorschaubildes: Die Miniaturansicht konnte nicht am vorgesehenen Ort gespeichert werden215:33, 29 November 2012
Common.css - what's new?305:21, 30 May 2012
Error in Special:NewFiles123:57, 7 May 2012
Sprint to make the page actually useful211:38, 14 April 2012
Reference tooltips1302:37, 6 April 2012
Not released on time111:34, 5 April 2012
how to update105:21, 30 May 2012

Thumbnails didn't work since Update to 1.19

Hey there, since I have updated my 1.18.3 release of mediawiki to 1.19.0 I can't get new thumbnails created. If I upload a new picture I get the following error:

Error creating thumbnail: Unable to save thumbnail to destination

in my LocalSettings.php there is the following:

## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads  = true;
$wgUseImageMagick = true;
$wgImageMagickConvertCommand = "/usr/bin/convert";
#$wgUseImageResize = true;
$wgImageMagickTempDir = "/srv/httpd/vhosts/";
#$wgCustomConvertCommand = "/usr/bin/convert -resize %wx%h %s %d";

ImageMagick 6.6.0-4 is installed on a debian squeeze system. I can't see any errors in the apache logfiles and I didn't change the rights on my image folder. Anyone has the same problem? Greeting Andreas, 4 May 2012

Is this your issue?

No, I test the patcht, but still didn't work. If it's an open_base_dir thing, I should see something in the apache logs., 4 May 2012

I made a mistake adding the patch. Forgot to delete the line

return sys_get_temp_dir();

Now it works fine! Thanks for the Patch and thanks for your help!, 4 May 2012

Hi Sumana,

I found a problem in the patch for open_base_dir. I changed the upload_tmp_dir to /srv/php-tmp/ in my php.ini. This is a security thing. So the patcht checks first for /tmp which is the system tmp directory and this drops out an open_basedir error in apache log. Then it goes to the php.ini upload_tmp_dir, which works. I think the order of the patch schould changed to first look at php and then the system temp dir to avoid the error in apache log.

Greetings Andreas, 5 May 2012

Andreas, can you go ahead and just submit a corrected patch either via Developer access or via the bug in Bugzilla?

Hi, I don't have access to Bugzilla, so here is my Patch, the whole function wfTempDir() looks like that on my Mediawiki:

function wfTempDir() {
        foreach( array( 'TMPDIR', 'TMP', 'TEMP' ) as $var ) {
                $tmp = getenv( $var );
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
        if (ini_get('upload_tmp_dir')!==false) {
                $tmp = ini_get('upload_tmp_dir');
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
        if( function_exists( 'sys_get_temp_dir' ) ) {
                $tmp = sys_get_temp_dir();
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
        # Usual defaults
        return wfIsWindows() ? 'C:\Windows\Temp' : '/tmp';
}, 9 May 2012

You do have access to Bugzilla:

MarkAHershberger(talk)12:18, 9 May 2012

Hi, I don't have access to Bugzilla, so here is my Patch, the whole function wfTempDir() looks like that on my Mediawiki:

function wfTempDir() {
        foreach( array( 'TMPDIR', 'TMP', 'TEMP' ) as $var ) {
                $tmp = getenv( $var );
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
        if (ini_get('upload_tmp_dir')!==false) {
                $tmp = ini_get('upload_tmp_dir');
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
        if( function_exists( 'sys_get_temp_dir' ) ) {
                $tmp = sys_get_temp_dir();
                if( $tmp && file_exists( $tmp ) && is_dir( $tmp ) && is_writable( $tmp ) ) {
                        return $tmp;
        # Usual defaults
        return wfIsWindows() ? 'C:\Windows\Temp' : '/tmp';
}, 9 May 2012

Hey, I seem to be having the same problem, but the patch doesn't help: No matter what I do, I get the same error message.

It's a brand new MW installation, 1.19.0, in a shared hosting environment. I have php 5.3.10 (apache2handler) and GD library enabled. My "upload_tmp_dir" in phpinfo.php says "/tmp", and the /tmp directory on my server has rights drwxrwxrwt.

This is what I have in LocalSettings.php - uncommenting the ImageMagick variables has no effect:

$wgEnableUploads = true;

  1. $wgUseImageMagick = true;
  2. $wgImageMagickConvertCommand = "/usr/bin/convert";

I have tried to get some more error messages out of the php, using:

error_reporting( E_ALL ); ini_set( 'display_errors', 1 ); $wgShowExceptionDetails = true;

in LocalSettings.php, but that doesn't produce anything either.

Any ideas???

Anderssl (talk)13:04, 24 May 2012

Forgot to say, but the images directory in the MW installation has rights 777, as do all the subfolders.

Anderssl (talk)13:05, 24 May 2012

Are you able to write to /tmp from your web process? Could you write a test script to verify this? If you don't know how, could you install a test I write to verify it?

MarkAHershberger(talk)13:26, 24 May 2012

Good question. Sure, pass me the script if you have one! (I think I could figure it out myself, but not without some effort...)

Anderssl (talk)19:27, 24 May 2012

Some more info that I guess is relevant: I have another, older mediawiki installation running on the same server, where file uploads work fine. That is MW 1.15.1 though. I also just realized that php safe mode is enabled on our server. Is that a likely cause for trouble?

CORRECTION: I just realized that, although file uploading has worked fine for the purposes I have had till now, *thumbnailing* does not seem to work in any of the MW installations on our server. (Haven't had the need for thumbnailing until now.) So I guess this issue is not related strictly to version 19 of MW, but is a general issue with either MW or our server. Sorry about that.

Still, if anyone has any idea about how to diagnose this problem, I'd be thankful!

Anderssl (talk)08:32, 25 May 2012
Edited by another user.
Last edit: 12:39, 25 May 2012

I tried the following:

$handle = fopen("/tmp/test.txt", "x");
if ($handle) echo "Success!";
else print_r(error_get_last());

...which returns "failed to open stream: No such file or directory". According to the 'x' flag should cause the file to be created if it doesn't exist, so I guess there is something wrong somewhere? I have allow_url_fopen=off in phpinfo, but that shouldn't matter, right?

Anderssl (talk)08:56, 25 May 2012

Sorry for spamming the thread - I'm a noob. I changed the above script to point to the images directory, and then i get success. Could this be a php bug? (Or at least a very misleading error message...)

My open_basedir has "no value".

Anderssl (talk)09:51, 25 May 2012

Excellent work on reproducing the problem since I took too long to get back to you. Could you try this script?


function dirTest( $label, $dir ) {
    echo "Test for $label: $dir\n";

    if( file_exists( $dir ) ) {
        echo "Dir exists\n";
        $s = @stat( $dir );
        if( $s === false ) {
            echo "Stat failed: $php_errormsg\n";
        } else {
            echo "Permissions: ". decoct( $s[2] ) ."\n";
            echo "Is dir: ". ( is_dir( $dir ) ? "true" : "false" ) ."\n";
            echo "Is writable: ". ( is_writable( $dir ) ? "true" : "false" )  ."\n";

            $file = tempnam( $dir, "test" );
            echo "Attempting to create: $file\n";
            $fh = fopen( $file, "w" );
            if( $fh !== false ) {
                $written = fwrite( $fh, "stuff" );
                if( $written === false ) {
                    echo "Error when writing: $php_errormsg\n";
                } else {
                    echo "Wrote $written bytes.\n";
                    if( fclose($fh) === false ) {
                        echo "Error when closing: $php_errormsg\n";
                if( unlink( $file ) === false ) {
                    echo "Error removing $file: $php_errormsg\n";
                } else {
                    echo "Sucessfully removed $file\n";
            } else {
                echo "Error opening for writing: $php_errormsg\n";
    } else {
        echo "Directory does not exist!\n";
    echo "\n";

dirTest( "Unix tmp dir", "/tmp" );
dirTest( "Window temp dir", "c:/windows/temp" );
dirTest( "sys_get_temp_dir", sys_get_temp_dir() );
dirTest( "upload_tmp_dir", ini_get( 'upload_tmp_dir' ) );
MarkAHershberger(talk)13:29, 25 May 2012

btw, on my laptop this gives:

Test for Unix tmp dir: /tmp
Dir exists
Permissions: 41777
Is dir: true
Is writable: true
Attempting to create: /tmp/testjmWbDE
Wrote 5 bytes.
Sucessfully removed /tmp/testjmWbDE

Test for Window temp dir: c:/windows/temp
Directory does not exist!

Test for sys_get_temp_dir: /tmp
Dir exists
Permissions: 41777
Is dir: true
Is writable: true
Attempting to create: /tmp/test6nrzCk
Wrote 5 bytes.
Sucessfully removed /tmp/test6nrzCk

Test for upload_tmp_dir: 
Directory does not exist!
MarkAHershberger(talk)13:40, 25 May 2012
Edited by another user.
Last edit: 14:36, 25 May 2012

Thanks for getting back to me! The above script returns:

Test for Unix tmp dir: /tmp
Directory does not exist!

Test for Window temp dir: c:/windows/temp
Directory does not exist!

Test for sys_get_temp_dir: /tmp
Directory does not exist!

Test for upload_tmp_dir: /tmp
Directory does not exist!

For the record, there IS a directory that appears to me as '/tmp' in my command line. But I posted this question on stackoverflow, and a commenter suggested the problem could have to do with 'chroot'. This server is part of a large university network, so I am sure the setup is fairly complex.

It seems odd though, given that the user 'nobody' - which I am almost certain is the user running php scripts - is able to write to /tmp.

Is there any way to have the thumbnailing process use some other tmp folder, for instance one under the images folder - where I know i can write?

Anderssl (talk)13:42, 25 May 2012

I'm facing the same problem with a brandnew MediaWiki 1.19.1.

I tried the first proposed patch. The thumbs in my articles were not shown. However thumbnails were shown in the list of uploaded files. But at the same time I got dozens of error messages: "Warning: file_exists() [function.file-exists]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/var/www/web1388/html/:/var/www/web1388/phptmp/:/var/www/web1388/files/:/var/www/web1388/atd/:/usr/share/php/) in /var/www/web1388/html/mediawiki_test/mediawiki/includes/GlobalFunctions.php on line 2495"

I saw that there is another patch. Is it also available as a patch file for Tortoise SVN? I'm not familiar with git.

Will this bug be fixed in 1.19.2?

BTW: I run another wiki on the same shared hosting with MediaWiki 1.16.2 and all thumbnailing works fine on this installation. I don't use ImageMagick on any of my wikis.
My PHP version: 5.3.13-1~dotdeb.0 (cgi-fcgi)
MySQL version: 5.5.25-1

Thanks for your help!

Stefahn (talk)11:43, 16 June 2012

If you are sitting in the root of your MediaWiki installation and have access to patch, then this patch should be able to be applied like so:

 $ curl;a=patch;h=99fdc6e838d4c7f6a7135a06b58d0bb232ca611c | patch -p1
MarkAHershberger(talk)11:32, 19 June 2012

Mark, thanks for your excellent support (also via mail)!

Just for the record:
I managed to apply the patch to my 1.19.1 version.
Then I created a temp folder in the images folder (with chmod 775).
Then I added the following line to localsettings.php:

# Make sure this directory exists and is writable by the webserver!
$wgTmpDirectory = "$IP/images/temp";

Now thumbnails work fine again :)

Stefahn (talk)20:51, 19 June 2012

Thank you, Stefahn! Was confronted with the same problem, then the patch + your temp folder solution made my day!, 29 August 2012


I experience the same problem, but not able to use patch. What else can I do to get it back to work?

Cheers Yogie, 3 July 2012

Why can't you use the patch?

MarkAHershberger(talk)20:56, 3 July 2012

I'm on a shared host and do not have ssh or bash access I need to upload my files via FTP., 4 July 2012

I did a fresh Install of 1.20.2 today with no modification to the uploadpath or so and now I'm facing the same problem. How can I use the patch (if its suitable for the current version) on a host with no shell access. example ist at

while an 1.18 works on the same host out of the box

Carchaias (talk)23:32, 29 December 2012

Ok I inserted all the files from the post of 4.Jul.2012. But now I get an MWException. With $wgShowExceptionDetails = true; it results in:

Preprocessor_DOM::preprocessToObj: generated node count limit exceeded


  1. 0 /users/blechschaden/www/wiki/includes/parser/Parser.php(2979): Preprocessor_DOM->preprocessToObj('$1 ??? {{SITENA...', 0)
  2. 1 /users/blechschaden/www/wiki/includes/parser/Parser.php(3036): Parser->preprocessToDom('$1 ??? {{SITENA...')
  3. 2 /users/blechschaden/www/wiki/includes/parser/Parser.php(540): Parser->replaceVariables('$1 ??? {{SITENA...')
  4. 3 /users/blechschaden/www/wiki/includes/parser/Parser.php(4636): Parser->preprocess('$1 ??? {{SITENA...', Object(Title), Object(ParserOptions))
  5. 4 /users/blechschaden/www/wiki/includes/cache/MessageCache.php(815): Parser->transformMsg('$1 ??? {{SITENA...', Object(ParserOptions), Object(Title))
  6. 5 /users/blechschaden/www/wiki/includes/Message.php(618): MessageCache->transform('$1 ??? {{SITENA...', true, Object(Language), Object(Title))
  7. 6 /users/blechschaden/www/wiki/includes/Message.php(436): Message->transformText('$1 ??? {{SITENA...')
  8. 7 /users/blechschaden/www/wiki/includes/Message.php(476): Message->toString()
  9. 8 /users/blechschaden/www/wiki/includes/OutputPage.php(790): Message->text()
  10. 9 /users/blechschaden/www/wiki/includes/OutputPage.php(833): OutputPage->setHTMLTitle(Object(Message))
  11. 10 /users/blechschaden/www/wiki/includes/Article.php(485): OutputPage->setPageTitle('Kategorie:Villo...')
  12. 11 /users/blechschaden/www/wiki/includes/CategoryPage.php(73): Article->view()
  13. 12 /users/blechschaden/www/wiki/includes/actions/ViewAction.php(37): CategoryPage->view()
  14. 13 /users/blechschaden/www/wiki/includes/Wiki.php(427): ViewAction->show()
  15. 14 /users/blechschaden/www/wiki/includes/Wiki.php(304): MediaWiki->performAction(Object(CategoryPage))
  16. 15 /users/blechschaden/www/wiki/includes/Wiki.php(536): MediaWiki->performRequest()
  17. 16 /users/blechschaden/www/wiki/includes/Wiki.php(446): MediaWiki->main()
  18. 17 /users/blechschaden/www/wiki/index.php(59): MediaWiki->run()
  19. 18 {main}
Carchaias (talk)00:12, 30 December 2012

Since this is a 1.20 issue, I've copied your question here and replied there.

MarkAHershberger(talk)00:28, 2 January 2013

My solution for MediaWiki 1.20.3 has been to add the following line to LocalSettings.php

$wgTmpDirectory = ini_get('upload_tmp_dir');
Actiuinformatica (talk)16:42, 16 March 2013

Release notes?

Those for 1.19 and 1.20 seem to have disappeared.

Cavila (MW 1.19.2, MySQL 5.1.66, Php 5.3.3-7, SMW 1.8, SF 1.5.2}15:06, 3 July 2013

Thanks for pointing this out. This is because of the move to gitblit.

MarkAHershberger(talk)21:49, 4 July 2013

Wiki trouble

Hello i've some problems with my wiki configuration too, including displaying .svg thumbs, it didn't work this time, but i have figure out, why the upload function generally don't work at this point, after reading and thinking of your conversation, i trying something and now it works fine for pictures like .jpg or .png.

Make following step: 1) put this line in your ls.php, save it and upload, don't forget to back up your latest working ls.php.

## To enable image uploads, make sure the 'images' directory
## is writable, then set this to true:
$wgEnableUploads  = true;
$wgDisableUploads = false; # Enable uploads
#$wgUseImageMagick = true;
#$wgImageMagickConvertCommand = "/usr/bin/convert";
$wgUploadDirectory = "{$IP}/images/";
Abani79 (talk)17:27, 25 May 2012

Sorry for moving this out of the thread... I did that before I realized you were offering a solution. And, now I can't move it back :(

MarkAHershberger(talk)18:24, 25 May 2012

Hello, ah no problem, hoping it helps everyone, if you would like to post it in the entire thread, then you can do it. In my wiki configuration works it, but thumbnailing .svg did not working.

Abani79 (talk)18:35, 25 May 2012

I don't get it. What does this fix?

Anderssl (talk)23:02, 25 May 2012

It is a possible solution for user, having trouble with enabling fileupload. By the way: my wiki can't create thumbnails of svg's, getting instead an output textmessage with following content:

Fehler beim Erstellen des Vorschaubildes: sh: convert: not found

i'm not sure, where the problem is, any help for solving this is appreciated.

Abani79 (talk)01:00, 26 May 2012

You need to install imagemagick. What sort of system is your host?

MarkAHershberger(talk)01:03, 26 May 2012

UML extension still support?

A thread, Thread:Talk:MediaWiki 1.19/UML extension still support?, was moved from here to Project:Support desk. This move was made by Kghbln (talk | contribs) on 6 June 2013 at 17:06.

login doesn't work since update.

Hi everybody,

I'm trying to update my wiki from 1.16.2 to 1.19.6. But when the update is terminated, the login doesn't work. password check works fine because if it's false I have the error message but when I connect with the good login. I don't have a connexion. Login/create account button comes and I don't have edit button.

Has anybody an idea ?


PS: Does mwusers forum closed ?

Lutch 2904 (talk)07:16, 21 May 2013

Check the cookies that MW is trying to send your browser. It sounds like MW isn't sending the right ones.

MarkAHershberger(talk)15:00, 21 May 2013

I think that's come of the server version (IIS5) and this bug but I'm not sur. I tried with Apache and it works.I will try with IIS 7.5 to confirm.

Lutch 2904 (talk)06:04, 22 May 2013

That was that. IIS5 server is too old ;-)

Thanks for your help

Lutch 2904 (talk)05:19, 23 May 2013

Fehler beim Erstellen des Vorschaubildes: Die Miniaturansicht konnte nicht am vorgesehenen Ort gespeichert werden

Hallo, ich probier's einfach mal in Deutsch: Ich habe MediaWiki in Version 1.20.0 auf einem Windows Server 2008 R2 mit IIS 7.5 installiert. PHP (5.3.13 (cgi-fcgi)) habe ich über den Web Plattform Installer (WebPI 2.0) installiert. MySQL (5.1.57-community) habe ich ebenfalls über den WebPi installiert.

Auf das images-Verzeichnis und die Unterverzeichnisse und Dateien habe ich in der Verzweiflung Vollzugriff für "Jeder" gegeben. Trotzdem erscheint die Fehlermeldung

 Fehler beim Erstellen des Vorschaubildes: Die Miniaturansicht konnte nicht am vorgesehenen Ort gespeichert werden

bei jedem Bild.

Erstaunlicherweise habe ich in einem parallelen Verzeichnis auf dem IIS ein Wiki in derselben Version, bei dem dieses Problem scheinbar nicht auftritt. Die LocalSettings.php-Dateien habe ich auch bereits verglichen. Auch da scheint es keine relevanten Unterschiede zu geben.

Hat jemand eine Idee, woran es noch liegen könnte? Danke, Alex., 29 November 2012

Hi Alex,

hast du dir schon den Thread eins drunter angesehen? Speziell ab dieser Stelle:'t_work_since_Update_to_1.19/reply_(31)

Stefahn (talk)13:33, 29 November 2012

I thought this problem from 1.19 had been fixed in 1.20, but yours is the second report of this in 1.20. In the meantime, can you set $wgUploadDirectory to an existing, writable directory?

MarkAHershberger(talk)15:33, 29 November 2012

Common.css - what's new?

What exactly means

New common*.css files usable by skins instead of having to copy piles of generic styles from MonoBook or Vector's css.

Is that a feature for extensions which define their own skins? What does the "*" stand for? I can't find any Bug report or Revision linked to it. Don't we already have standard.css for "generic styles"?

Bergi21:40, 13 February 2012

We've consolidated the CSS into skins/common/common*.css. See r95837 for the beginning of this.

MarkAHershberger(talk)01:40, 14 February 2012

Ah, thanks for the hint. But they are not loadable as own modules? I think they, most clearly the commonElements.css, would be a great base for a myskin.css.

Bergi11:59, 15 February 2012

Check out resources/Resources.php to see how this is done e.g. for the Vector skin. You will notice that you can use these files as a basis for any skin without having to copy them (I guess that was the reason for doing this seperation)., 20 February 2012

Error in Special:NewFiles

Hello, when I updated my wiki to 1.19 version, this error appear:

Someone know how do I fix this?, 7 May 2012

I just tried upgrading from MW 1.18 to MW 1.19, without a problem. Maybe this is related to the extensions you have installed?

MarkAHershberger(talk)23:57, 7 May 2012

Sprint to make the page actually useful

For MediaWiki 1.18, we had a really beautiful page that had a good, easy to read, easy to scan, summary of the things in 1.18. I'm not sure we can make this page as nice as that, but I would like something a little better than what we have right now. Today, I'll be working on updating the page and I invite others to join me.

MarkAHershberger(talk)13:22, 5 April 2012

I contributed some important details to the MediaWiki 1.18 page, and I'd be happy to jump in with this one as soon as I feel competent. Thanks for making me aware of the need.

Badon (talk)02:17, 6 April 2012

Also have a look at MediaWiki 1.19 which we'll be rolling out next week.

MarkAHershberger(talk)15:52, 11 April 2012

Reference tooltips

(This might not be the best talk page for this. If someone knows of a more appropriate talk page, please move this post.)

A few months ago, a design idea for Reference Tooltips was posted on this wiki. Thinking that this would be useful to have on Wikipedia, I proceeded to make the JS and CSS for it, and then I proposed that it be made available as a gadget on the English Wikipedia, as I had been informed the RT was "not an official project". I intended to then propose that it be added to the ENWP Common.js (whether or not it had gained consensus for being made an opt-in gadget yet).

More recently, I was looking at the WMFLabs MW1.19 test wikis, and was surprised to see that a RT functionality (although with the tooltips in a different location, with a different design, and lacking the ability for users to click on the reference content) in use. Despite the fact that many communities might not want to have RT on their wikis, it appears that all wikis are to have this version of Reference Tooltips enabled upon upgrading to MW1.19, assuming that the Labs wikis are an accurate portrayal of what the wikis will look like after the upgrade. As far as I know, the Wikimedia communities were not consulted in this decision, nor were any of them even informed in any way of this change. I am fairly certain that this change was not announced in any Village Pump, mentioned anywhere on the entire Mediawiki wiki, or at all mentioned in any mailing list. Nor is it mentioned in the MW1.19 release notes. It appears to me that the community consensus process was bypassed, and the possibility of any previous discussion was eliminated. I am also rather annoyed that all my work toward the RT script turned out to be useless, and that this came about as a result of just not being informed about any plan for the WMF to build Reference Tooltips.

So here's some questions:

  • Did the design document Reference Tooltips become an official project afterwards and end up as the current version after some heavy modification, or was the official implementation an entirely separate project created independently?
  • Is there any intention to inform the communities of this rather major change before it gets implemented on the live wikis, or will nobody be informed until it's actually running?
  • Will there be any way at all for individual wikis to disable this feature?
  • Where, if anywhere, did discussion take place? (Is there an entire communication channel I'm unaware of?) This wasn't just a decision taken by one individual, was it?
  • How is the box containing the reference content being in the lower right and unclickable supposed to be an improvement?

(PS: Sorry for the critical tone, I'm just really annoyed right now. If I actually misunderstood the whole thing, or just somehow missed discussion/announcement of RT, sorry again.)

Yair rand09:31, 5 February 2012

I confirm this. The test en.wikipedia with MediaWiki 1.19 is here:

Do you have a public wiki up somewhere that demonstrates your reference tooltips? Just judging from the screenshot, it looks superior to me, too. Once I've tested it out, I'd be willing to submit a bug report enhancement request for this issue.

Badon05:52, 7 February 2012

In addition to Bugzilla, here's another suitable place to report this, as a supplement:

Badon05:54, 7 February 2012

No, I don't have a public wiki set up demonstrating it. I suppose the best way to test it would be to add importScript("User:Yair rand/ReferenceTooltips.js");importStylesheet("User:Yair rand/ReferenceTooltips.css"); to one's common.js on ENWP.

Yair rand08:01, 7 February 2012

I didn't see that you did anything. Since I'd written something similar for a different job, I spent a few minutes one afternoon a few months ago turning it into an extension that works with Cite. Eventually, TheDJ (I think) actually integrated it into Cite, so it's made it into the standard product.

Andrew Garrett21:48, 7 February 2012

Right now (as Andrew's reply makes clear) we don't have a good way for people to know what sort of on-wiki development activities are taking place. Hopefully we'll have better ways to communicate about what we're all doing soon.

MarkAHershberger(talk)21:55, 7 February 2012

Do you know if this will be a part of the "better ways to communicate"?:

I took a look there, and it's very pretty, but I didn't immediately get a feel for anything "happening" there yet. Would Yair's work be part of the extensions project, even though it's not quite an extension? Or, is it something that needs to be handled differently?

In case anyone wants to get his work into MediaWiki via an extension, here's Extension:Cite.

Badon02:22, 8 February 2012

(sorry for the really late reply)

This wasn't part of the "better ways to communicate". For the 1.19 release we used blog posts, mailing list messages, m:Global message delivery, and Central Notice immediately prior to the update.

We think this worked fairly well, but one other thing we're considering are. If you have other ideas, let us know. In the meantime, how do you think these notices worked?

MarkAHershberger(talk)23:23, 7 March 2012

That's good to hear. :)

Yair rand20:35, 8 February 2012

Since we're looking for better ways to communicate with gadget, JS, and CSS devs who work on different WMF sites, what do you think would be a good way to attack this problem? Where could we have posted our plans so that you would have an opportunity to weigh in?

A big part of the problem seems to be that each wiki has (till RL2 anyway) its own copy of gadgets and its own developers who don't really collaborate.

We're working on addressing this, but I'm curious to hear what you think would be a good approach.

MarkAHershberger(talk)20:18, 9 February 2012

Whatever the solution ends up becoming, I'm sure it will involve centralizing communication on, since this is already the place to go for everything specific to MediaWiki. Already, it seems communication specific to an upcoming version of MediaWiki is gravitating towards pages like this one.

However, MediaWiki pages are isolated from each other. The best mass-communication model I know of is forums. My favorite is SMF, with a BIG list of recent posts on its main page. It makes it very easy to get an idea of what is happening in one glance. It beats mailing lists, wikis, email, IRC, and anything else I can think of. In fact, declines in IRC usage seem to be correlated with increases in forum usage, on a global scale.

I view LiquidThreads as a step away from the proper solution. Forums as a communication model are well-proven, widely used, and easy for anyone to feel comfortable with. Wikis and mailing lists have a barrier to entry, and other quirks that do not make it easy to participate, or gain information from them. Being ephemeral is just one problem.

MediaWiki nirvana will be achieved when talk pages are linked to SMF forums. I have heard some good reasons from people who disagree with me about why we should stay pure-wiki, but despite their good reasons, I keep wishing we didn't have to reinvent the wheel when forums are already so good at facilitating communication.

Badon00:34, 10 February 2012

JEDL is our first attempt at this. I'm going to be finding a way to contact gadget authors and point them to this resource. Hopefully we'll begin to have a better community develop.

MarkAHershberger(talk)23:26, 7 March 2012

...And now it appears to have been removed from the Labs wiki. Would someone be able to explain what happened/is going to happen with this, please?

Yair rand20:36, 8 February 2012

I'm interested in an update. I see that Yair's implementation is on Wikipedia now: Thread:Talk:Reference Tooltips/Some comments, +prototype/reply (3). It would be nice if this could make it into MW 1.19, I think it's excellent for usability.

Badon (talk)02:37, 6 April 2012

Not released on time

...since it's now April and we still only have a second beta.

Jasper Deng (talk)03:36, 5 April 2012

how to update

How do i update mediawiki on my wiki?

N64dude (talk)23:19, 25 May 2012

See Manual:Upgrading. Ask here (or on that talk page) for more help if you need it.

MarkAHershberger(talk)23:22, 25 May 2012