Extension talk:AnyWikiDraw

AnyWikiDraw Project Status
I really like this very much and I would appreciate to use it. I know it is experimental, but please add a description, what still is to do until it is working.

Actually it would be nice to know about still missing functionality before installing, ...


 * Hi. I have added a "To Do" section to the page.
 * --Rawcoder 13:08, 6 September 2007 (UTC)

AnyWikiDraw PHP Errors
..., like the not working save-function of drawings: anything goes, but drawings are not saved and don't show up after finishing and they don't show up when trying to edit them again


 * Apart from the known refresh problems, the save function is working. Did you enable uploading of image files to your wiki? If you are not able to upload a SVG, PNG or JPG file using the upload page of the wiki, then the drawing applet can't do it either.
 * There is a controlling function in the applet. But it might not be checking for all possible error cases. Can you please check, if PHP prints an error message on the error log of the web-server?
 * --Rawcoder 12:29, 3 August 2007 (UTC)

I get a Parse error: syntax error, unexpected T_OBJECT_OPERATOR in .../extensions/AnyWikiDraw/AnyWikiDraw.php on line 105 What version of PHP is required?


 * I have implemented this extension with PHP 5.0 in mind. I am using it currently with PHP 5.0.4.
 * --Rawcoder 13:08, 6 September 2007 (UTC)

AnyWikiDraw Can't Find Files
This issue is fixed in AnyWikiDraw 0.11. --Rawcoder 07:23, 28 May 2008 (UTC)

I've set up AnyWikiDraw 0.1 as an extension to MediaWiki 1.9.1. It works fine creating and in saving the file created. However, when trying to reedit an existing file, it gives this message:


 * Couldn't load the drawing: http://www.proper-wiki-name.org/wiki/index.php?title=Special:AnyWikiDraw?Image:Test02.svg.

When the images is actually found here:


 * http://www.proper-wiki-name.org/wiki/images/1/1f/Test02.svg

In other words, the extension seems to work fine to create and save (one time) a new drawing, but not to edit an existing drawing.

Any ideas on how to fix this?

--C4duser 15:36, 11 September 2007 (UTC)


 * Looks like AnyWikiDraw can't handle article paths in the style of {$wgScript}?title=$1.
 * With the current version of AnyWikiDraw, you need to run MediaWiki with article paths in the style of {$wgScript}/$1.
 * I am going to take a look at this problem for the next version of AnyWikiDraw. But I can't tell you right now, when the next version will be released.
 * --Rawcoder 06:08, 13 September 2007 (UTC)

I hacked away at the AnyWikiDraw code and got the code to generate a full URL for the image. Yet for some reason the JVM still fails. The URL now looks something like this: http://cicswiki.org/cicswiki1/index.php?title=Special:AnyWikiDraw?image=/cicswiki1/images/e/ea/Test.gif Is this supposed to work? In other words - if the image variable refers to a real file - is AnyWikiDraw supposed to be able to edit the file?
 * --cbooysen 208.62.154.74 19:47, 12 October 2007 (UTC)


 * The question mark may only occur once in the URL. If you change your code to insert an ampersand "&" before the word "image" it might work - at least the editor should show up with this file - saving the edited image is another story and thus might still break.
 * Also note, that AnyWikiDraw does not support the GIF format, you need to use JPG, PNG or SVG.
 * http://cicswiki.org/cicswiki1/index.php?title=Special:AnyWikiDraw&image=/cicswiki1/images/e/ea/Test.png
 * --Rawcoder 05:57, 17 October 2007 (UTC)

AnyWikiDraw working (fairly well) on MW 1.9.1
This issue is fixed in AnyWikiDraw 0.11. --Rawcoder 07:23, 28 May 2008 (UTC)

I've managed to get AnyWikiDraw to work fairly well on MediaWiki 1.9.1 and it really is a tremendous extension &mdash; IMHO much better than any of the other programs for making diagrams and drawings on MediaWiki.

The problems I've found are as follows:


 * Something in AnyWikiDraw is causing this message to appear on the background to the Special:Allmessages page: "Warning: call_user_func_array [function.call-user-func-array]: First argument is expected to be a valid callback, 'AnyWikiDraw::loadMessages' was given in /home/ .. (my path) .. /wiki/includes/Hooks.php on line 114". Doesn't seem to be a big deal because I've got this page tucked away were the public rarely sees it.
 * SVG works fine. Can edit, save, and reedit. However, thumbnails don't show up on "recent uploads" page. Instead there is the message "Error creating thumbnails".
 * PNG, jpg can produce diagrams, but can't be re-edited.

The SVG drawings are compact and of good quality, better than PNG or jpg, anyway.

--C4duser 03:24, 6 May 2008 (UTC)


 * Hi C4duser. I am glad you like AnyWikiDraw so far. :)
 * I am very interested to get a look at the code changes you made for MediaWiki 1.9.1. I am looking forward to make AnyWikiDraw work with versions higher than 1.7 of MediaWiki. My intention was to go directly from 1.7 to 1.12. But if you have it working with 1.9.1, I don't mind at all. ;)
 * The warning on call_user_func_array is probably caused by API differences betwen MediaWiki 1.7.x and 1.9.x. There might be some rewriting needed to accomodate for this.
 * For creating the thumbnails, I had copied and pasted lots of code from MediaWiki 1.7.x into the AnyWikiDraw plugin. Maybe we need to copy and paste the same code sections again from MediaWiki 1.9.x. This needs careful checking though.
 * How exactly does the re-editing of PNG and JPG images fail? AnyWikiDraw doesn't store vector data in a PNG or JPG file (for example, like Adobe Fireworks does in a PNG file). This is why, after reopening a PNG or JPG file, everything which has been drawn so far, becomes part of the background image. So, on re-edit, it is only possible to draw over the background image.
 * --Rawcoder 15:49, 13 May 2008 (UTC)


 * In the meantime, I got a beta of AnyWikiDraw 0.11 working on MediaWiki 1.9.3.
 * I think, it didn't work for C4duser, because of the {$wgScript}?title=$1 issue. I have resolved this issue now for MediaWiki 1.7.1 as well.
 * I am now working on support for MediaWiki 1.12. I need to rewrite the plugin, because somewhere between MediaWiki 1.9 and 1.12 the plugin API has changed.
 * --Rawcoder 04:56, 26 May 2008 (UTC)
 * I installed version 0.11 and the same errors persist. However, I appreciate the improvements to the interface (collapsing panels). I have made no changes to the code and have the extension installed directly on MediaWiki 1.9.1.  The PNG and JPG files cannot be re-edited, giving the following error message: "Couldn't load the drawing" "Couldn't load image from file "java.io.BufferedInputStream@5dd915".."  The PNG and JPG files show up in the thumbnail gallery of images, but SVG files do not. However, SVG files can be re-edited and work just fine otherwise.  The same error message on the Special:Allmessages page persists. Thanks. --C4duser 19:54, 30 May 2008 (UTC)
 * In the meantime, I found a fix for the Special:Allmessages issue. I am taking a look at the PNG and JPG issue next. Is it possible, that your SVG thumbnail issue is the same issue that CGT has reported below? I mean, if you upload an SVG image using the Upload-special page, do you get a thumbnail image? --Rawcoder 08:41, 13 June 2008 (UTC)
 * I saved the svg image to my desktop and then uploaded it with the normal upload special page. The svg image still doesn't show in the thumbnail. In fact, it also doesn't show in the Image:imagename.svg page. Maybe this is a problem with MediaWiki or even with my installation? I don't usually upload svg images and don't know. --C4duser 00:06, 3 July 2008 (UTC)


 * If uploading SVG images using the Upload special page does not create thumbnails, then there is no way to make AnyWikiDraw work. Currently, AnyWikiDraw relies on MediaWiki for the creation of the thumbnail images. (Altough AnyWikiDraw uploads the thumbnail to MediaWiki, I couldn't figure out how to store them in MediaWiki). For installation instructions of the SVG functionality in MediaWiki see Manual:Image_Administration. --Rawcoder 12:46, 17 July 2008 (UTC)


 * OK. I guess the problem is that my installation is not set up properly for SVG. I've read the installation instructions for SVG on MediaWiki and can't seem to find what is wrong. Googly for help hasn't done much good except to find out the SVG has a lot of problems on MediaWiki. Are there some really clear instructions about setting up SVG on MediaWiki somewhere? Thanks. --C4duser 14:36, 19 August 2008 (UTC)


 * Hi C4duser. I had acceptable results with ImageMagick and setting all the $wg variables as described on the SVG page.
 * --Rawcoder 18:41, 23 June 2009 (UTC)

No image after save
Hi Rawcoder. Great extension. I have a problem : after drawing save (test) there is no image on the wiki article. More, i have an error message (Erreur lors de la création de la miniature : Param�tre non valide - white "in french") when i call the picture (test) from image namespace. I use : Windows XP, mediawiki 1.12 and Xampp last version.

Can you help me because this extension is fundamental for me. Thanks very mutch.

CGT 06/06/08


 * I think, you need to install ImageMagick on your computer. Does the generation of the preview image work, when you upload an SVG image using the Upload special page?
 * --Rawcoder 05:59, 9 June 2008 (UTC)

Hi Rawcoder

Effectively i dont have Imagemagick on my internal serveur. Is it possible to help me to install and configure this software (where is located for example). Is it a spécial configuration on mediawiki ?Is this soft installed on the web serveur or on the clients ? Thanks to help me

CGT 12/06/08 22:50


 * Hi CGT,
 * I just noticed, that the current version of ImageMagick can only handle very few SVG files. I think it is better, if you install Apache Batik on your MediaWiki server. I am going to do try this on my MediaWiki server. When I get it to work, I'll report back here my configuration settings. --Rawcoder 08:37, 13 June 2008 (UTC)

Hi Rawcoder

I have installed imagemagick (ImageMagick-6.4.1-Q16)on my WindowsXP. I m using Xampp with mediawiki 1.12.

The problème is the same : after drawing save (test) there is no image on the wiki article but i dont have any error message. It is impossible for me to change Xampp for Apache Baltic because my wiki is running for my compagny. Have you an idee ? Thanks for all CGT 18/06/08 23:00


 * CGT. Its not clear to me, what exactly your restrictions are on that server. Is there no Java at all installed on the server? Or can you just not install Apache Batik? If Java is installed, it still might be possible to install Batik, by just copying its files into a subdirectory on the server where you have write access (for example, into the extensions directory of MediaWiki). It would be great, if you could continue this discussion on the AnyWikiDraw forums or mailing list. --Rawcoder 12:56, 19 June 2008 (UTC)

Wrong size after saving
This issue is fixed in AnyWikiDraw 0.13. --Rawcoder 08:54, 28 June 2009 (UTC)

I use MediaWiki 1.12 on Linux and AnyWikiDraw for version 1.12. Everything woks but after saving, image size is always 256x256. If I edit again everything looks good in AnyWikiDraw. But generated image stay at 256x256. Do you see same issue ?


 * Yes, this is a known issue. I have added it to the known issues section on the extension page.
 * --Rawcoder 19:53, 9 January 2009 (UTC)

Image just showed
Whenever I try to use the extension, it shows me the image just like the image.jpg tag would do. It doesn't actually launch the applet.


 * This happens, because your user account does not have permission to upload files. Only if you can see the "Upload file" link in the toolbox, then are allowed to edit drawings using this extension.
 * --Rawcoder 18:43, 23 June 2009 (UTC)

Compatibility with MW 1.13.
This issue is fixed in AnyWikiDraw 0.13.1 --Rawcoder 12:59, 30 June 2009 (UTC)

can't get them run under Mozilla
I Rawcoder, thanks for fixing it. Actuall i runs very well under IE but not under Mozilla (Version 3.x). I get the following error: --Ozz 18:04, 29 June 2009 (UTC)


 * Hi Ozz,
 * That's weird stuff. Apparently this happens, because I compiled the applet with debug code, and then compressed it with pack200.
 * I have created a new release 0.13.1 which (hopefully) fixes this issue.
 * --Rawcoder 12:59, 30 June 2009 (UTC)

I try the extension with MW 1.13, and $wgGroupPermissions['*']['edit'] = false; and the extension fails ("Couldn't save the drawing. Forbidden"). I try to debug PHP code and see, that POST-request from Java-applet did not send wiki authorization cookies.


 * This happens because you have not explicitly allowed cookie access to Java and JavaScript by setting $wgCookieHttpOnly to false.
 * --Rawcoder 08:58, 27 June 2009 (UTC)

Can we wait for upgrade the extension soon? (I really like the extension but unfortunately I have not skills in Java-applet programming/debugging.) --StasFomin 09:51, 9 December 2008 (UTC)


 * No, there will certainly not be an upgrade very soon (meaning, not in the first quarter of 2009).
 * We are still running AnyWikiDraw on MediaWiki 1.7 on our own installation. We will probably upgrade to a
 * newer version of MediaWiki in the third or thourth quarter of 2009.
 * --Rawcoder 20:01, 9 January 2009 (UTC)


 * just wanted to say this is a very cool extension, I'm sad to be using 1.13 for other reasons or I'd regress to 1.12. May just have to start hacking the .jar to get auth cookies passed. Niels Olson 18:12, 26 February 2009 (UTC)
 * Rawcoder, it is extremely surprising to me that you are using a version of mediawiki from the 2006-2007 period. Many people prefer to use the mediawiki nightly code from subversion because that is what is used live on wikipedia. Giving the simplicity of upgrading mediawiki there really isn't any excuse for using such an old version. The end result is that the extension matrix is a nightmare because of extension rot as demonstrated by AnyWikiDraw. --Alterego 23:11, 7 March 2009 (UTC)


 * Alterego. On why we don't use the leading edge versions of MediaWiki: Unfortunately, upgrading is not a simple task on our installation. We have a large farm of MediaWiki's which are integrated into another platform. On the "extension rot" of AnyWikiDraw: AnyWikiDraw is clearly marked as an experimental extension. If you are not involved in the AnyWikiDraw project - you should not use it except for experimentation. Also note that AnyWikiDraw is an open source project. You can always make the necessary changes on your own. --Rawcoder 10:06, 18 March 2009 (UTC)

Problems Creating New Image
I have AnyWikiDraw 0.13.1 installed on MediaWiki 1.13.3 (Mowes Portable), and for the most part the extension works, but there is some weirdness when saving the initial version of an image. Here's what happens (forgive the excessive detail).
 * I create a new page with a syntax.
 * I save the page, which gives me the blank square and an Edit link.
 * I click Edit and Run the java applet.
 * I edit the picture, then click Save.
 * Instead of seeing the image, I see "Image:test.svg" text, along with an edit link. In the Apache error log, I see this: move_uploaded_file [function.move-uploaded-file]: Unable to move 'C:\\installers\\mowes\\mowes_portable\\php5\\temp\\php6F.tmp' to 'C:\\installers\\mowes\\mowes_portable\\www\\mediawiki/images/thumb/b/bd/Test.svg/400px-Test.svg.png' in C:\\installers\\mowes\\mowes_portable\\www\\mediawiki\\extensions\\AnyWikiDraw\\AnyWikiDraw.body.php on line 169.
 * I click the Edit link near the image again, then click Save in the applet.
 * The image shows up as expected, and editing is fine after that.

Seems like there's something going wrong with initial image creation. Any hints?

Image Creation Without Fixed Size
AnyWikiDraw 0.13.1, MW 1.13.3: It would be nice to not have to specify an initial size for the image in the wikitext. When I leave off the initial size, I get a show-stopping PHP error: PHP Fatal error: Call to a member function getWidth on a non-object in C:\\installers\\mowes\\mowes_portable\\www\\mediawiki\\extensions\\AnyWikiDraw\\AnyWikiDraw.php on line 131. So.. I need to specify a size, then start editing the image, decide what size I really want it to be, save the image, then go and change the original #drawing to remove the width and height.. and then everything works okay. Not a huge deal, but a couple steps that could be optimized.