Extension talk:GraphViz/Archive3

Error Messages and other curious behaviour

I have expected that the diagrams created for the old graphViz extension would also work with the new one. Instead I get an error message: "Error: no valid link was found at the end of line 2".

What does this mean?
Answer: Extension:ImageMap now handles image rendering on behalf of the GraphViz extension. The "no valid link" message is actually from the ImageMap extension complaining that it doesn't understand the provided link syntax. The old GraphViz extension syntax for specifying an internal link (a bare string without enclosing square brackets) is not natively understood by MediaWiki or the ImageMap extension. If you add two sets of enclosing square brackets (the normal wiki syntax for internal links) you'll be back in business. Please see Extension:GraphViz#Links for more information about the new GraphViz link syntax. P.S. Do you have graphs with a ton of internal links in the old syntax? I dislike the idea of perpetuating a non-standard internal link syntax but if this is a significant hardship then I might consider a backwards compatibility shim. --Thanks, Keith Welter

Are there other error messages which should be explained?
Answer: In addition to returning error messages from Extension:ImageMap, the GraphViz extension also returns error messages from the graphviz and mscgen rendering tools (e.g. about syntax errors in the DOT or Mscgen language input). The GraphViz extension also returns error messages about problems uploading a rendered image (e.g. insufficient permissions or forbidden image type). Finally the GraphViz extension returns error messages about internal errors such as failure to create the working directory. These are the basic categories of error messages. If you see a specific error message and have questions about it, please let me know. --Thanks, Keith Welter

Because my own examples didn't work, I tried the first two examples from the extension page. I get a very curious behaviour when putting both examples on one page.
Here's the code:

== simple graphViz test ==

=== Example 1 from http://www.mediawiki.org/wiki/Extension:GraphViz ===
<graphviz border='frame' format='png' desc='none'>
digraph example1 {Hello->"World!"}
</graphviz>

=== Example 2 from http://www.mediawiki.org/wiki/Extension:GraphViz ===
<graphviz renderer='neato' caption='Hello Neato'>
graph EXAMPLE2 {
  run -- intr;
  intr -- runbl;
  runbl -- run;
  run -- kernel;
  kernel -- zombie;
  kernel -- sleep;
  kernel -- runmem;
  sleep -- swap;
  swap -- runswap;
  runswap -- new;
  runswap -- runmem;
  new -- runmem;
  sleep -- runmem;
}
</graphviz>

The first heading is shown on the left side (correct)
The first diagram is presented on the right side. (don't know if this is correct.)
Then the second heading is shown under the first diagram and the second diagram is also shown on the right side. (wrong)
The second heading and the second diagram should be placed on the left side.

Is this already known?
Answer: As mentioned above, Extension:ImageMap now handles image rendering on behalf of the GraphViz extension. It does standard MediaWiki image rendering. If you scroll down in the image format table, you'll see that format=frame does yield the image on the right of the screen. Also see, Help:Images#Horizontal_alignment I think all the answers to your formatting questions should be on the image page. If not, the talk page for that is the right place to post follow-up questions. --Thanks, Keith Welter

Workaround: For now, I have simply removed the border='frame' part. Then, there are no borders and both diagrams are shown on the left side.

Thanks, Martin

July 1st, 2014: Thanks Keith for the very fast answer!

I'll try with the new link syntax. I'm generating my diagrams from the results of sparql queries (working with Semantic MediaWiki). This way the diagrams always show the current state of the wiki. So I have only to do some corrections in a few templates. But at first, I'll try to get some hard-coded examples working. I'll share my experiences here. And I'll take a closer look at the ImageMap extension. Thanks for the explanations on that.

I have experimented further and I now see that there is another problem at the bottom of it. Even when I removed all links I got the error message with the link. And this was really confusing. But now I have seen this: when I change a graph without changing its name it is not re-rendered. I have now started with the simple "Hello, World" example and only added a second line to the DOT code: Hello -> Goodbye; . When saving the page the old diagram is shown. When changing the name to something not used before, the new diagram will be created. I'm sure that this works for you, so I think I'm doing something wrong. Where can I look for debugging this?

Hi Martin, I'm seeing the same problem on MW 1.22.2. Please open a bug (I'll be debugging in the meantime). The edit preview does still work for me. So you can try that to see how your rendered graphs look. Just click on the "Show preview" button on the edit page.

Actually, I just installed GraphViz version 1.3.0 and if I reload the page after clicking save then I see the rendering of the updated graph. Please try that and report back with your results (along with your MW version and GraphViz version which you can find on the Special:Version page of your wiki. Caching may be a factor so please also provide the $wgMainCacheType value from your LocalSettings.php.

For debugging, see Manual:How_to_debug. I use the following in my LocalSettings.php:

$wgDebugLogFile = "/var/log/mediawiki/debug-{$wgDBname}.log";
$wgDebugToolbar = true;
$wgShowExceptionDetails = true;
$wgDevelopmentWarnings = true;

The GraphViz extension uses wfDebug statements to produce debug log entries which include the function name. You can search for names like "GraphViz::", "GraphRenderParms::" and "UploadLocalFile::".

--Thanks, Keith Welter

Hello Keith, The `extension.json` file is missing and hence unusable in MW 1.28.2.

Hello Keith,

I wanted to try version 1.3.0 before filing a bug report but I couldn't download it. I have still MediaWiki 1.19.17 and therefore followed the git link. There I still get the version 1.1.0 from June 27th. I have even emptied my browser cache and downloaded again, same result. Perhaps due to caching at www.mediawiki.org???

Talking of caching: I'm using the default CACHE_NONE for my wiki.

And the extension works fine as long as I'm not updating the dot code. Even my templates work now. (so "Thanks!" again!)

Another point: when having finished this discussion I would look over this and keep only the essentials which may be of importance for other users. Is this OK for you?

Best regards, Martin

Hi Martin, I recreated the problem on MW 1.19.17. The problem is that the extension uses two hooks that were introduced in MW 1.21. There are alternative hooks (deprecated in MW 1.21) that should work for MW versions <1.21. I'll begin work on the backward compatibility fix. Please do proceed with opening the bug. Also, I agree about cleaning-up this talk page when we're done. And feel free to suggest any improvements for the doc on the main extension page. --Thanks, Keith Welter

Hello Keith,

I have filed the bug now. It's number 67587 [1]. And thanks for addressing the backward compatibility issue. Despite the newer versions of MediaWiki the 1.19.17 is a long-term stable one and there are still a lot of people using it. --Best regards, Martin

Preview

Every time a new graph is added to the page or an old one is edited, on preview or page save, instead of the graph, an inscription appears: Graph image source changed. Reload page to display updated graph image., and you need to press F5 to see the graph. It was not like this in previous versions of the extension. This is very uncomfortable since it renders the Preview button useless, and a graph is not something you can make perfect on the first attempt.

Alex Mashin (talk) 07:33, 20 July 2014 (UTC)

Hi Alex. First off, sorry for the slow response. This page is on my watch list but I didn't get notified (or it went to my spam folder which only goes back to August). I'll endeavor to remove the reload behavior in a future version (it requires a substantial design change so it will probably be version 2.x.x). Another apology-- I'm effectively on paternity leave so it will be some time before I can get to this. Thanks for your feedback and sorry the reload behavior is not to your liking. BTW, pressing F5 to reload the graph image on the preview page works for me to see graph changes reflected before saving them. --Welterkj (talk) 21:57, 18 September 2014 (UTC)

Hi Alex, I've released version 1.4.0 which avoids the reload message in most cases. Please give it a try and let me know how it goes. Thanks! --Welterkj (talk) 19:21, 19 October 2014 (UTC)

Dynamic Graphs

I've been using earlier versions of this extension for some time to generate GraphViz code and replace text/colors in the code with live status from a database to produce live network diagrams based on our monitoring systems. This recent update appears to have broken that ability. What I'd done was to have something like this in a page:

<my_graphviz>
graph {
  A [label=<<table><tr><td><img src="{{MyIcon:A}}"/></td></tr><tr><td>A</td></tr></table>];
  B [label=<<table><tr><td><img src="{{MyIcon:B}}"/></td></tr><tr><td>B</td></tr></table>];
  A -- B [taillabel="1",headlabel="2",color="{{MyPort:A:1}};{{MyPort:B:2]]"];
}
</my_graphviz>

My extension takes this tag input and replaces the {{MyIcon:HOST}} patterns it finds in the content with icons that represent the state of the HOST. The {{MyPort:HOST:PORT}} patterns get replaced with a color that reflects the interface state of the PORT on the HOST. The output of the extension is a <graphviz/> tag with the {{My...}} tags replaced then sent back through $parser->recursiveTagParse(). The tag is also calling $parser->disableCache() so the results are updated for each request.

This has worked well for many years until last week when I updated a DEV machine to the new release of this extension. Seems the new approach to storing the generated images as true file articles in MediaWiki is messing with me. I thought I'd reach out and see if there's some nice way to fix this or if I should just stick with the older code.

Thanks in advance.

PDugas (talk) 14:34, 28 July 2014 (UTC)

Hi PDugas. Please see my response to Alex about the "Preview" issue above. I suspect you are running afoul of the same reload behavior that Alex dislikes. I suggest you stick with the older code until the new version I described to Alex is available. Sorry the current version isn't working for you. --Welterkj (talk) 22:02, 18 September 2014 (UTC)

Hi PDugas, after more thought, I think the dynamic graph functionality you describe would require a new feature in the GraphViz extension (>1.0). I'll do some more investigation. --Welterkj (talk) 19:23, 19 October 2014 (UTC)

Dynamic graph functionality is now available at the development level (use "composer require mediawiki/graph-viz 'dev-master'"). Usage: <graphviz preparse="dynamic">...</graphviz>. You can also specify preparse="static" which will only replace variables/templates when saving or previewing an edit of the page containing the <graphviz> (or <mscgen>) tags. --Welterkj (talk) 20:34, 26 October 2014 (UTC)

The preparse tag argument is now available in version 1.5.0. --Welterkj (talk) 21:25, 28 October 2014 (UTC)

Does not always work with me: Error: blablabla.src:0: syntax error near line 0 context: digraph example1 >>> {Hello- <<< >World} With dynamic as well as static setting of the preparse argument. edit: at times it appears to be working, though it is difficult to make out the reason why, because on another occasion it refuses to do so and throws out a considerable amount of errors messages.--Temptuousinsolence (talk) 15:04, 31 October 2014 (UTC)

Hi Temptuousinsolence, please raise a bug under component "[other]" and provide the wikitext that caused the problem as well as a debug log. Thanks. --Welterkj (talk) 16:02, 31 October 2014 (UTC)--

Bugfix Version 1.3.1 (2014-07-10)

Hi, I don't know how to report this on https://bugzilla.wikimedia.org because the extension is not listed there, so I report this here:

• the contruction of the class GraphVizSettings() is wrong and stops the Wiki from functioning. (I use MediaWiki 1.23.2, PHP 5.4.20 (fpm-fcgi), MySQL 5.6.12-log)

Here is a patch:

--- GraphViz.php	2014-08-06 22:49:40.000000000 +0200
+++ GraphViz_neu.php	2014-08-06 22:47:07.000000000 +0200
@@ -69,20 +69,20 @@
 	public $defaultImageType;
 };
 
-$wgGraphVizSettings = new GraphVizSettings();
 
 //self executing anonymous function to prevent global scope assumptions
 call_user_func( function() {
 
+	$wgGraphVizSettings = new GraphVizSettings();
 	// Set execution path
 	if ( stristr( PHP_OS, 'WIN' ) && !stristr( PHP_OS, 'Darwin' ) ) {
-		$GLOBALS['wgGraphVizSettings']->execPath = 'C:/Program Files/Graphviz/bin/';
+		$wgGraphVizSettings->execPath = 'C:/Program Files/Graphviz/bin/';
 	} else {
-		$GLOBALS['wgGraphVizSettings']->execPath = '/usr/bin/';
+		$wgGraphVizSettings->execPath = '/usr/bin/';
 	}
 
-	$GLOBALS['wgGraphVizSettings']->mscgenPath = '';
-	$GLOBALS['wgGraphVizSettings']->defaultImageType = 'png';
+	$wgGraphVizSettings->mscgenPath = '';
+	$wgGraphVizSettings->defaultImageType = 'png';
 
 	$dir = __DIR__ . '/';

--Andreas P. 11:24, 7 August 2014 (UTC)

Hi Andreas. The existing code works fine for me on MW 1.23.2. Can you be more specific about the symptoms of your problem? It seems to me that with your patch $wgGraphVizSettings would only be visible within the local scope of the anonymous function that contains it (though it is meant to be global scope). Thanks. --Welterkj (talk) 22:27, 18 September 2014 (UTC)

I had the same problem and it helps at least to get rid of the error message in line 81 of the Graphviz.php: $GLOBALS['wgGraphVizSettings']->execPath = '/usr/bin'; The symptom is that there is a persistent error message that does not want to vanish. --Temptuousinsolence (talk) 10:16, 21 October 2014 (UTC)

I reproduced the problem and raised bug 72325 (component [other] is fine for GraphViz bugs). Thanks! --Welterkj (talk) 18:04, 21 October 2014 (UTC)

Fixed in version version 1.4.1. --Welterkj (talk) 04:03, 22 October 2014 (UTC)

Specific example?

The link given the for example is a link to the gallery for the Graphviz library, not Extension:GraphViz itself. Is there a demo site where this extension is running? If a live demo site isn't available, maybe show some screenshots/PDFs of the page source showing Graphviz syntax and the resulting output. --Lance E Sloan 17:39, 16 September 2014 (UTC)

Hi Lance. I changed the link to point to Extension:GraphViz#Examples. If I find a good live demo site I'll update it again. Thanks. --Welterkj (talk) 22:10, 18 September 2014 (UTC)

GraphViz 1.5.0 internal error with MW 1.23.6

I run MW 1.23.6. GraphViz 1.3.1 works fine. But when I upgrade GraphViz extension (using composer) to 1.5.0, I get following "Internal error" when opening a page with embeded graphs or try to create a new graph:

[exception] [107987dc] /mediawiki/index.php?title=Sandbox&action=submit
Exception from line 77 of /srv/www/htdocs/mediawiki/includes/parser/StripState.php:
Invalid marker: ^?UNIQ9f35223a283f1154-graphviz-00000001-QINU^?

Anybody having the same issue? --Ralfk (talk) 12:39, 31 October 2014 (UTC)

Yes, I have the same issue. Preparsing (see a bit above) makes it at least possible to edit the page and enter the content to the MW-page, but the current GraphViz extension is hardly working smoothly. --Temptuousinsolence (talk) 15:06, 31 October 2014 (UTC)

Hi guys, sorry for your trouble with GraphViz 1.5.0 and MW 1.23.6. I did my testing on MW 1.23.2 and MW 1.19.20 so I'll upgrade the former and try to reproduce. In the meantime, please raise a bug under component "[other]" and provide a debug log. Thanks. --Welterkj (talk) 15:55, 31 October 2014 (UTC)

I have setup xdebug and will upload a log file once I have configured it properly.--Temptuousinsolence (talk) 10:11, 4 November 2014 (UTC)

I got some time to investigate today and it appears that the contents of the git repository are not what they should be. So please disregard the request for a debug log file while I sort-out what happened with the relevant commits. To revert to a stable version: composer require mediawiki/graph-viz '1.4.1' Sorry again for the inconvenience. --Welterkj (talk) 00:13, 5 November 2014 (UTC)

I have changed the GraphViz-Version, but still the same error.--Temptuousinsolence (talk) 13:41, 5 November 2014 (UTC)

I had tagged the wrong commit when I created release 1.5.0 for composer. That is fixed now so uninstalling/installing version 1.5.0 will now result in the correct code being installed. To uninstall, I delete the require graph-viz line out of the composer.json file in the MW installation dir and then do 'composer update'. I tested a composer install of the fixed version 1.5.0 on MW 1.23.6 and that worked fine for me (version 1.4.1 also works for me). Please reinstall version 1.5.0 and if you still have trouble we should really open a bug report and move the conversation there. I'm happy to do that if needed. Thanks. --Welterkj (talk) 20:29, 5 November 2014 (UTC)

What has changed is that the amount of errors has increased ...

for instance:

Error detected at line 4: syntax error, unexpected characters. > Vorlage->Vorlage [label="Erstellt"]; the ">" is not parsed correctly of the mscgen. I thought that maybe there was an error in the permissions, since I am on a Linux machine and played around with them and now I have an even longer trail of error codes ... Bugreport --Temptuousinsolence (talk) 09:39, 6 November 2014 (UTC)

I uninstalled the extension (even though this wiki was on 1.3.1 before) and installed it again as 1.5.0. But still the same error (and even one additional) --Ralfk (talk) 14:22, 6 November 2014 (UTC):

[Bug56269] Exception thrown with an uncommited database transaction: [8d1f035a] /wiki/Sandbox/Graphviz   Exception from line 77 of /srv/www/htdocs/w/includ
es/parser/StripState.php: Invalid marker: ^?UNIQbc7b8602bc553993-graphviz-00000003-QINU^?

[exception] [8d1f035a] /wiki/Sandbox/Graphviz   Exception from line 77 of /srv/www/htdocs/w/includes/parser/StripState.php: Invalid marker: ^?UNIQbc7b8602b
c553993-graphviz-00000003-QINU^?

• I confirm that the invalid marker error is still there as of today.
  Alex Mashin (talk) 10:53, 8 November 2014 (UTC)
  • After downgrading to 1.4.1 and 1.4.0, the error persists. 1.3.1 works, more or less ().
    Alex Mashin (talk) 11:30, 8 November 2014 (UTC)

I need a debug log to diagnose this problem since I am unable to reproduce it. If someone could attach a log to the bug report that would be a big help. -Welterkj

I uploaded a log ... I had been busy lately and did not have had the time to deal with this. --Temptuousinsolence (talk) 08:53, 13 November 2014 (UTC)

preparse

What is wrong with {{#tag:graphviz|...}}?
Alex Mashin (talk) 11:30, 8 November 2014 (UTC)

Hi Alex. I don't understand your comment. GraphViz has always been implemented as a tag extension. Are you requesting a new feature whereby the extension would also support a parser function alternative syntax? --Welterkj (talk) 18:31, 1 December 2014 (UTC)

I just successfully tried out {{#tag:graphviz|...}} and documented it here: semantic-mw:Help:Creating_Graphs_with_Semantic_MediaWiki . It allows for parser processed input to the extension, e.g. #if-statements, and does not require change to the extension code. --Hans Oleander (talk) 16:33, 2 September 2015 (UTC)

Polynomial explosion when used in templates

This extension creates articles in the File namespace, one per image. This is fine. But if you use the extension in a template, and 100 pages transclude the template, you get 100 identical images in the File namespace. And every time you update the template, potentially 100 uploaded files get replaced... all identical! That seems a fundamentally questionable design decision.

Is there a way around this non-scalable behavior? --Maiden taiwan (talk) 20:43, 21 November 2014 (UTC)

Hi Maiden. You should be able to create the graph once using <graphviz> tags outside of the template and then use image syntax to refer to the graph image generated by GraphViz. If the graph contains links, you can use ImageMap syntax instead. In this case, the file page for the graph image will include the ImageMap wikitext that you can copy and paste into your template definition. You can modify the Image line of the copied ImageMap wikitext with different layout options if you want. Cheers. --Welterkj (talk) 18:15, 1 December 2014 (UTC)

Call to a member function getId() on a non-object

When GraphViz first creates its File page, we are seeing this error:

PHP Fatal error:  Call to a member function getId() on a non-object
in /path/w/extensions/GraphViz/GraphViz_body.php on line 351

Here's the line:

return $title->getLatestRevID() != $title->getFirstRevision()->getId();

So getFirstRevision() is null, perhaps because the File page hasn't been created yet? Should this be:

return $title->getFirstRevision()
  ? $title->getLatestRevID() != $title->getFirstRevision()->getId()
  : false
  ;

MediaWiki bug tracker is down this week for an upgrade, so I'm reporting the problem here. Any workarounds?

--Maiden taiwan (talk) 20:54, 21 November 2014 (UTC)

Possible. But maybe it is related to the issue that is brought oup here. I somehow recall that I had problems with the id once as well, but it had been in a different environment that I am currently working with. --Temptuousinsolence (talk) 09:24, 24 November 2014 (UTC)

Please raise a bug. Thanks. --Welterkj (talk) 18:25, 1 December 2014 (UTC)

See bug T89325. --Welterkj (talk) 16:20, 11 April 2015 (UTC)

Latest "stable" GraphViz under MW 1.24

This happens hen MW tries to parse a page with a <graphviz> tag:

[e4fa625c] /wiki/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:
Alex_Mashin/%D0%9F%D0%B5%D1%81%D0%BE%D1%87%D0%BD%D0%B8%D1%86%D0%B0 Exception from line 6347 of (skipped)/includes/parser/Parser.php: Parser state cleared while parsing. Did you call Parser::parse recursively?

Backtrace:

#0 (skipped)/includes/parser/Parser.php(4752): Parser->lock()
#1 (skipped)/includes/content/WikitextContent.php(146): Parser->preSaveTransform(string, Title, User, ParserOptions)
#2 (skipped)/includes/page/WikiPage.php(2140): WikitextContent->preSaveTransform(Title, User, ParserOptions)
#3 (skipped)/extensions/SemanticMediaWiki/includes/src/MediaWiki/EditInfoProvider.php(88): WikiPage->prepareContentForEdit(WikitextContent, NULL, User, string)
#4 (skipped)/extensions/SemanticMediaWiki/includes/src/MediaWiki/EditInfoProvider.php(66): SMW\MediaWiki\EditInfoProvider->prepareContentForEdit()
#5 (skipped)/extensions/SemanticMediaWiki/includes/src/MediaWiki/Hooks/NewRevisionFromEditComplete.php(81): SMW\MediaWiki\EditInfoProvider->fetchEditInfo()
#6 (skipped)/extensions/SemanticMediaWiki/includes/src/MediaWiki/Hooks/NewRevisionFromEditComplete.php(76): SMW\MediaWiki\Hooks\NewRevisionFromEditComplete->getParserOutputFromEditInfo()
#7 (skipped)/extensions/SemanticMediaWiki/includes/Setup.php(392): SMW\MediaWiki\Hooks\NewRevisionFromEditComplete->process()
#8 [internal function]: SMW\Setup->SMW\{closure}(WikiFilePage, Revision, integer, User)
#9 (skipped)/includes/Hooks.php(206): call_user_func_array(Closure, array)
#10 (skipped)/includes/GlobalFunctions.php(3995): Hooks::run(string, array, NULL)
#11 (skipped)/includes/filerepo/file/LocalFile.php(1424): wfRunHooks(string, array)
#12 (skipped)/includes/filerepo/file/LocalFile.php(1184): LocalFile->recordUpload2(string, string, string, array, boolean, User)
#13 (skipped)/includes/upload/UploadBase.php(738): LocalFile->upload(string, string, string, integer, NULL, boolean, User)
#14 (skipped)/extensions/GraphViz/UploadLocalFile.php(238): UploadBase->performUpload(string, string, boolean, User)
#15 (skipped)/extensions/GraphViz/GraphViz_body.php(1140): UploadLocalFile::upload(string, string, User, string, string, boolean, boolean)
#16 (skipped)/extensions/GraphViz/GraphViz_body.php(740): GraphViz::render(string, array, Parser, PPFrame_DOM)
#17 [internal function]: GraphViz::graphvizParserHook(string, array, Parser, PPFrame_DOM)
#18 (skipped)/includes/parser/Parser.php(4156): call_user_func_array(array, array)
#19 (skipped)/includes/parser/Preprocessor_DOM.php(1262): Parser->extensionSubstitution(array, PPFrame_DOM)
#20 (skipped)/includes/parser/Parser.php(3281): PPFrame_DOM->expand(PPNode_DOM, integer)
#21 (skipped)/includes/parser/Parser.php(1239): Parser->replaceVariables(string)
#22 (skipped)/includes/parser/Parser.php(405): Parser->internalParse(string)
#23 (skipped)/includes/content/WikitextContent.php(338): Parser->parse(string, Title, ParserOptions, boolean, boolean, integer)
#24 (skipped)/includes/content/AbstractContent.php(490): WikitextContent->fillParserOutput(Title, integer, ParserOptions, boolean, ParserOutput)
#25 (skipped)/includes/poolcounter/PoolWorkArticleView.php(139): AbstractContent->getParserOutput(Title, integer, ParserOptions)
#26 (skipped)/includes/poolcounter/PoolCounterWork.php(123): PoolWorkArticleView->doWork()
#27 (skipped)/includes/page/Article.php(688): PoolCounterWork->execute()
#28 (skipped)/includes/actions/ViewAction.php(44): Article->view()
#29 (skipped)/includes/MediaWiki.php(414): ViewAction->show()
#30 (skipped)/includes/MediaWiki.php(282): MediaWiki->performAction(Article, Title)
#31 (skipped)/includes/MediaWiki.php(584): MediaWiki->performRequest()
#32 (skipped)/includes/MediaWiki.php(435): MediaWiki->main()
#33 (skipped)/index.php(46): MediaWiki->run()
#34 {main}

• Graphviz 1.5.0 (version 30798c3) 03:46, October 29 2014
• ImageMap (version 634ad79) 04:03, November 25 2014
• MediaWiki 1.24.0 (ebb1639) 08:36, November 27 2014.

You may want to try this version of GtraphViz: https://gerrit.wikimedia.org/r/#/c/174487/ It worked for me with the 1.23 version ... care to check whether it runs with 1.24 as well? --Temptuousinsolence (talk) 10:40, 1 December 2014 (UTC)

I agree that this is most likely another symptom of bug T75073. Please read the comments of that bug before testing the fix. Thanks. --Welterkj (talk) 18:19, 1 December 2014 (UTC)

I have just tested it ... runs fine. I have even been able to edit it wiht the Visual Editor, which is quite convenient if you ask me. --Temptuousinsolence (talk) 08:42, 2 December 2014 (UTC)

Encoding issues

<mscgen caption="äöüßÄÖÜ">
msc {
  Ä,Ö,Ü, ä, ö, ü, ß;

  ä->ä  [label="ä"];
  ö->ö  [label="ö"];
  ü=>ü  [label="ü"];
  ß=>ß  [label="ß"];
  Ä=>Ä  [label="Ä"];
  Ö=>Ö  [label="Ö"];
  Ü<<=Ü [label="Ü"];
}
</mscgen>

Is there anything that can be done in terms of the extension to deal with this issue? It appears as if it had been brought up here, but this discussion dates back to 2009 and not much appears to have been changed since.

According to the changelog it should actually be fixed ... strange.--Temptuousinsolence (talk) 10:52, 3 December 2014 (UTC)

I tried this on my system (with mscgen version 0.20) and got the following error:

Error detected at line 2: syntax error, unexpected characters. > Ä,Ö,Ü, ä, ö, ü, ß; Is this the same error message you see? Then I went to the images/graphviz directory and used the "file -i" command to display the encoding of an msc.src file that is accepted (i.e. no non-ascii characters). I see this: Main_Page_msc.src: text/plain; charset=us-ascii So, it looks like the file that the GraphViz extension is providing as input to the mscgen command is not UTF-8 encoded. Feel free to open a bug and I'll investigate further. Thanks. --Welterkj (talk) 03:10, 8 December 2014 (UTC)

Yes, this is exactly the same error. The curious thing is that GraphViz works fine, while mscgen throws an error; it is the one you have posted above. I should have posted it in the first post of mine. Yes, I will open a bug. --Temptuousinsolence (talk) 08:22, 8 December 2014 (UTC)

Here's an example that works:

<mscgen caption="äöüßÄÖÜ" uniquifier="1">
msc {
  A,O,U,a,o,u,B;

  a->a  [label="ä"];
  o->o  [label="ö"];
  u=>u  [label="ü"];
  B=>B  [label="ß"];
  A=>A  [label="Ä"];
  O=>O  [label="Ö"];
  U<<=U [label="Ü"];
}
</mscgen>

Perhaps mscgen only accepts non-ascii characters as labels. The encoding of the resulting file is correct in the file system:

file -i Main_Page_msc_1.src
Main_Page_msc_1.src: text/plain; charset=utf-8

I suggest asking the mscgen maintainer if this behavior is by design. Thanks. --Welterkj (talk) 15:32, 8 December 2014 (UTC)

Yes, it works indeed. Strange that that a character in the title fields still throws exceptions, while the program appears to be perfectly fine once they appear somewhere else. Still, this should be fixed somehow. Maybe the mscgen maintainer had forgotten about the fields in the head of the graphs. --Temptuousinsolence (talk) 15:41, 8 December 2014 (UTC)

Why does this extension create category pages?

I am wondering why this extension automatically creates some category pages in the wiki (since version 1.5.0). These pages are listed by other extensions which list category pages (examples: WikiCategoryTagCloud, DynamicPageList). This may be interesting for wiki administrators, but for readers of a wiki it may be confusing. Some extensions allow for an explicit exclusion of pages from their listings - this however requires additional administration work. Kappa (talk) 19:58, 21 December 2014 (UTC)

Hi Kappa. I'm assuming you've already read the GraphViz category documentation. The extension creates category pages so that it is easy to find the graph images generated by the extension (and by renderer). Here is the back-story. A user on this talk page asked for a link to a demo site. I didn't have time to create and maintain a demo site of my own so I went to wikiapiary to look for a public site that was using GraphViz. Next I visited all of the sites with a recent version and tried to find GraphViz generated graphs. I spent a lot of time manually searching but didn't find any graphs. That was frustrating and in my mind exposed a missing feature. I realized that categories would be a great solution for organizing graph images and making them easy to find. On a demo site with lots of graphs it would be perfect-- just put a link to Category:GraphViz from the main page and you'd see a master gallery of all the graph images without any manual editing. You could also navigate to a subcategory and see a gallery dedicated to each renderer (again, no manual editing). But I think what you're really asking is why does the extension create empty category pages. That is because it was easy to implement it that way. I suspect you would prefer that the extension create the category pages on demand rather than preemptively. I do think that would be an improvement. Let me know what you think. Thanks. --Welterkj (talk) 17:26, 22 December 2014 (UTC)

Hi Welterkj, thank you very much for your quick reply. I understand your point, but I was surprised by the fact that the GraphViz categories appeared in the tag cloud (WikiCategoryTagCloud) after an attempt to integrate GraphViz 1.5.0 (and 1.5.1) into a MW 1.23.8. The page "Category:GraphViz" was not empty, because the installation process also had installed four jpeg files. Realizing a GraphViz management support via categories has side effects on other uses of categories. These side effects would charge wiki administrators with the additional task of checking whether a side effect is desired for a wiki or not, i.e whether it informs or puzzles the users of a wiki. In case the effect is not so convenient, administrators would have to find a workaround (such as excluding the categories from a tag cloud and other possible presentation formats - if possible). I would prefer to have a parser tag (in the style of <showGraphVizInformation>) which I could set explicitly if I want to use the management overview, rather than checking the wiki after the installation of an extension for side effects. Kappa (talk) 21:08, 22 December 2014 (UTC)

Suppose I made the following modifications:

1. stop tagging the "dummy" images (4 jpeg files in your case)
2. only create a category page when it would be non-empty (i.e. on-demand instead of preemptive)
3. provide a configuration option to control automatic category page creation ($wgGraphVizSettings->createCategoryPages="yes|no", default=no)

Would that suit your needs? Thanks. --Welterkj (talk) 21:31, 22 December 2014 (UTC)

Yes, that sounds very good (1,2,3). A configuration option would be very helpful Kappa (talk) 16:58, 23 December 2014 (UTC)

The proposed change is now available at dev-master:

php composer.phar require mediawiki/graph-viz 'dev-master'

You may delete the GraphViz-created category pages and see that they are not re-created after upgrading to this version. Feedback is much appreciated. --Welterkj (talk) 22:54, 4 February 2015 (UTC)

Upgraded MW to 1.24, now tooltip no longer works

We upgraded our internal wiki to MW 1.24, and we're now running 1.3.1 of GraphViz. As a result, our existing diagrams that make use of "tooltips" are no longer generated. Example:

<graphviz>
digraph clcon_state_machine {
  Init -> Hold [ label="Up\laction_start_hold_timer", color="#a50026", fontcolor="#a50026", tooltip="A simple action which restarts the hold timer and sets the port up", labeltooltip="A simple action which restarts the hold timer and sets the port up" ];
}
</graphviz>

How can we resolve this problem?

Hi. I think you must have upgraded from a version of the GraphViz extension prior to 1.0.0. GraphViz >= version 1.0.0 uses the ImageMap extension to power links and ImageMap does not support tooltips without associated links. However, I see that the dot syntax does allow tooltip attributes without URL attributes so I'd like to have the GraphViz extension accept that case too. The solution that occurs to me is to change the extension to detect this case and add an innocuous link on the fly (such as a link to the page on which the graph appears). In the meantime, you can manually add URL attributes in your graph. Let me know what you think. --Welterkj (talk) 17:38, 30 January 2015 (UTC)

Thanks, adding URL="http://" worked for us. I like your suggestion for the fix though; if a URL is not given by the user, supplement the current page's URL. I tried to use the {{canonicalurl:}} and {{PAGENAME}} magic words, but the image map processor can't deal with it.

If you upgrade to GraphViz >= 1.5.0, you can use the "preparse" tag attribute to allow substitution of magic words (<graphviz preparse="dynamic">...</graphviz>). --Welterkj (talk) 03:44, 4 February 2015 (UTC)

The fix, now available at dev-master, supplies the dummy URL "http://" when a tooltip is present but the URL is absent in the DOT source:

php composer.phar require mediawiki/graph-viz 'dev-master'

--Welterkj (talk) 21:21, 5 February 2015 (UTC)

Could you make the URL into the page itself? That would be more useful. Ideally we wouldn't have to specify a URL at all (so clicking on the tooltip produces no action). The closest matching behaviour we can get for that is for the URL to lead to the page itself; going to "http://" will produce a blank page / error instead, which is less helpful.

Sure. I updated the fix available again at dev-master. --Welterkj (talk) 16:24, 4 March 2015 (UTC)

Problems on windows

The dot.exe and mscgen.exe do work from the command line.
They are in the system path variable.
I did try with \\ and / and also the ending slash.
The graphical Category browser extension is able to use dot.exe and to show the picture.
The graphViz extension only generates empty paragraphs.
I never got a png except of one time when i did play around with the wsShellExec command and replaced it with some sell_exec or exec command, ths did generate pictures in the right folder but then they where not in the page because some how the $ret variable was empty.
In the apache error log i get a message from the graphViz about command dot.exe not found, it contains the whole commandline for dot.exe but the parameter with the second path is broken, it should go to a subsubdirectory but the path after the -o option contains only the first directory like X:\dir\ and the rest does not appear in the apache log.
what did i miss? how can i fix this? Please help, i have no idea at all about PHP ... its the first time i look at such a thing and i dont know how to make this command run.
php-5.6.4-Win32-VC11-x86
mediawiki-1.24.0
Apache24
Win 8.1 64-bit
graphviz-2.38.msi
Msc-generator-v4.4.msi

Could you post the part of the apache-log that shows the error in the path? This would help to clear matters up.

--Temptuousinsolence (talk) 16:34, 18 February 2015 (UTC)

My vHost path to document root is
W:\WWW_DOC\(example.tld)\WWW-ROOT

Mediawiki is under
W:\WWW_DOC\(example.tld)\WWW-ROOT\mediawiki

Graphviz did successfully create some folders in the image directory
W:\WWW_DOC\(example.tld)\WWW-ROOT\mediawiki\images\graphviz
W:\WWW_DOC\(example.tld)\WWW-ROOT\mediawiki\images\graphviz\images

in my localsettings i have
$wgGraphVizSettings->execPath = "W:/Graphviz/bin/";
$wgGraphVizSettings->mscgenPath="W:/MscGenerator/";
$wgGraphVizSettings->defaultImageType = 'png';
i did try with \\ and / and also without / at the end and also with the full path to the dot.exe

in the system path i have
W:\Graphviz/bin
W:\MscGenerator

in the log i read
Der Befehl "W:/Graphviz/bin/dot.exe" -T "jpg" -o "W:\WWW_DOC\" ist entweder falsch geschrieben oder konnte nicht gefunden werden.
Der Befehl "W:/MscGenerator/mscgen.exe" -T "png" -o "W:\WWW_DOC\" ist entweder falsch geschrieben oder konnte nicht gefunden werden.
the command is mistyped or could not be found
i think "W:/*/*.exe" in the apache log is valid because / gets transformed into \
how ever i did also try with \\ and even \

in the CMD it self there is no problem with the commands
W:\MscGenerator\mscgen.exe
W:/Graphviz/bin/dot.exe

how ever the part after "W:/*/*.exe" -T "*" -o seems to be wrong
"W:\WWW_DOC\"
it should be
"W:\WWW_DOC\(example.tld)\WWW-ROOT\"

i do not know PHP, i just found the command gets build near the end of the parameters file, but i dont know what i could change there. in a other files is also a exec command wsExec or ShellExec, i dont remember ecactly, but once i did change this with a other php exec command which i found some where on google, then i got a src and a image file in the image folder but still not embeded in the wiki
it looks realy great, and many other extensions depend on this one
it would be great if some one could show how to fix this.
thanks in advance ;)

I am also having a similar problem on Windows 64-bit, with a similar software set-up to what was described above. Only blank paragraphs are being produced by the GraphViz extension. Other PHP scripts are able to access dot.exe and render graphs (including the Graphical Category Browser extension). Has there been any resolution to this issue? Wikipedian1544 (talk) 06:37, 1 March 2015 (UTC)

Until today I have no solution to this problem. If you have access to the server log files, you can maybe post the part where the dot.exe command fails, at my side i got a error message in the mediawiki debug (if turned on) about a missing picture, not much more, later in the server log of apache i found the path to the dot.exe but the parameter is wrong (as said in a post before), and i have no idea how to fix this :(

It appears that the information is being wrongly passed over to the GraphViz environment. As I run a linux server, I am not able to recreate your problem. Can you write a bit about your steps in setting up the MW installation? Is this an xampp thing or how do you run it? --Temptuousinsolence (talk) 14:26, 2 March 2015 (UTC)

i try to concentrate the ifos
php-5.6.4-Win32-VC11-x86
mediawiki-1.24.0
Apache24 (not xampp, ampps or wampp)
Windows 8.1 64-bit
graphviz-2.38.msi
Msc-generator-v4.4.msi
in the mediawiki debug is just a message about a missing picture.
the only realy useful message appears in the apache server log
it says
The command "W:/Graphviz/bin/dot.exe" -T "jpg" -o "W:\WWW_DOC\" could not be found or is wrong.
same for mscgen
the command at my side should look some thing like "W:/Graphviz/bin/dot.exe" -T "jpg" -o "W:\WWW_DOC\(domain.tld)\SomeFolder\mediawiki\images\graphviz\someFile.src"
i am not sure if the slash has to be forward or backward, in apache conf files we need forwardslashes, but windows needs backwardslashes in the system, but apache should fix this but i dont know how exactly or where.
How ever after the path in the parameter ("W:\WWW_DOC\") is, if i am not totaly wrong, at least the source file name missing.
I realy hope it is possible to fix this, other extensions in the same wiki use the dot.exe command and have not this kind of problem
there is a QuickGV extension, it uses the dot.exe directly and it works, also other extensions use the dot.exe, just this one has problems, curiously the most popular one ;(

Well. Did you try it without the -o parameter?

"W:/Graphviz/bin/dot.exe" -T "jpg" -o "W:\WWW_DOC\(domain.tld)\SomeFolder\mediawiki\images\graphviz\someFile.src"

You set the format (-T) to JPG and then try to write it into a src file. That is a bit strange. --Temptuousinsolence (talk) 12:46, 12 March 2015 (UTC)

There is likely a problem with the paths being created on Windows machines - possibly to do with forward slashes/backslashes. Is it possible for the developer of this extension to inspect all of the paths being created on Windows to discover where exactly the problem is occurring within the code? Wikipedian1544 (talk) 03:25, 14 March 2015 (UTC)

I had a similar problem running mediawiki 1.24 in a windows environment. In the end I replaced function wfShellExec in GlobalFunctions.php with the version from mw 1.22.15. Now everything works fine.

I appear to have the same problem; it certainly seems to be something to do with the call to wfShellExec. However, replacing it with the version from MW 1.22.15 did not work for me. --Ggreig (talk) 22:17, 20 April 2015 (UTC)

Using MediaWiki-Commands in Dot-Language

Hello there, I'm wondering if it is possible to use Inline Queries or other Wiki-Commands within the Dot-Language e.g. to display Properties. The Semantic Result Formats are not working for me in this case. Thanks for your help. --Miles Fides (talk) 10:44, 19 February 2015 (UTC)

Sorry, but I am unable to follow you. What do you want to do and what do you want to achieve? GraphViz is used to create graphics of some sort ... but nothing else. Or do you want to use inline-queries in order to create some kindof result that would then be passed over to the graphviz environment in order to create some form of visualization? --Temptuousinsolence (talk) 14:29, 2 March 2015 (UTC)

Yes exactly, I want to pass inline-query-results to the graphviz-environment to display the queries in a graph. I know that there is the Semantic Result Format-Extension, but it's not working for me... Do you know how I could achieve that? --Miles Fides (talk) 07:05, 3 March 2015 (UTC)

This is actually something I had a discussion about as well and I do not think that it is possible right now. I still have my hopes hat the PHP-extension of MediaWiki would be able to handle the data created on a page that is then used to create a string that could be parsed by the GraphViz extension. Honestly, I have not checked recently on the status fo the development of the PHP-extension but this might be one possible way to get it done.

MW-site => PHP extension => creates string => GraphViz uses the string => image

--Temptuousinsolence (talk) 11:29, 12 March 2015 (UTC)

I think what you want is the preparse=dynamic graph tag attribute. Below is an example that worked for me. --Welterkj (talk) 18:09, 25 October 2015 (UTC)

<graphviz preparse="dynamic">
graph inlineQuery {
  nodeA [label="{{#show: TestSMW | ?Creation date }}"];
}

Graphs generated by graphviz extension are not displayed in books exported using the collection extension

Graphviz/mscgen extension works well, I see generated graphs on page and on the "printable version page". Anyway when exporting the page in pdf with collection extension it does not display graphviz graphs while mscgen graphs are rendered as simple text. The collection extension works well with normal uploaded images (and works well with uploaded files generated by graphviz if i use it directly). May you check? I'm using the collection extension as a collaborative way to create books and need graphviz/mscgen desperately!

No works fine ... how do you export the page? What kind of software do you use? --Temptuousinsolence (talk) 11:34, 12 March 2015 (UTC)

I had trouble myself when running my own mwlib render server on Ubuntu. It appears that the graphviz tag is explicitly ignored by mwlib whereas the mscgen tag is not. See mwlib/tagext.py line 100. Temptuousinsolence, are you using an online renderer (e.g. http://tools.pediapress.com/mw-serve/ for $wgCollectionMWServeURL)? --Welterkj (talk) 22:03, 23 March 2015 (UTC)

I installed OCG (in place of the older mwlib render server) and GraphViz does not work with the collection extension that way either. The problem is in both OCG and parsoid. I chatted with OCG (and parsoid) devs about the issue and bug T94793 is the result. --Welterkj (talk) 22:42, 10 April 2015 (UTC)

1.24.2

When I try to submit page with graphs under MW 1.24.2 and HHVM:

Unexpected non-MediaWiki exception encountered, of type "BadMethodCallException"
[d7ee63db] /w/index.php?title=%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:Alex_Mashin/%D0%9F%D0%B5%D1%81%D0%BE%D1%87%D0%BD%D0%B8%D1%86%D0%B0&action=submit Exception from line 468 of .../w/extensions/GraphViz/GraphViz_body.php: Call to a member function addHTML() on a non-object (NULL)
Backtrace:
#0 /.data/www/traditio.ru/w/extensions/GraphViz/GraphViz_body.php(441): GraphViz::uploadImagesForTitle(Title, User)
#1 /.data/www/traditio.ru/w/includes/Hooks.php(206): GraphViz::onOutputPageParserOutput(OutputPage, ParserOutput)
#2 /.data/www/traditio.ru/w/includes/GlobalFunctions.php(3995): Hooks::run(string, array, NULL)
#3 /.data/www/traditio.ru/w/includes/OutputPage.php(1727): wfRunHooks(string, array)
#4 /.data/www/traditio.ru/w/includes/EditPage.php(3513): OutputPage->addParserOutputMetadata(ParserOutput)
#5 /.data/www/traditio.ru/w/includes/EditPage.php(2315): EditPage->getPreviewText()
#6 /.data/www/traditio.ru/w/includes/EditPage.php(553): EditPage->showEditForm()
#7 /.data/www/traditio.ru/w/includes/actions/EditAction.php(56): EditPage->edit()
#8 /.data/www/traditio.ru/w/includes/actions/SubmitAction.php(40): EditAction->show()
#9 /.data/www/traditio.ru/w/includes/MediaWiki.php(414): SubmitAction->show()
#10 /.data/www/traditio.ru/w/includes/MediaWiki.php(282): MediaWiki->performAction(Article, Title)
#11 /.data/www/traditio.ru/w/includes/MediaWiki.php(584): MediaWiki->performRequest()
#12 /.data/www/traditio.ru/w/includes/MediaWiki.php(435): MediaWiki->main()
#13 /.data/www/traditio.ru/w/index.php(46): MediaWiki->run()
#14 {main}

Alex Mashin (talk) 00:28, 4 May 2015 (UTC)

Hi Alex, what is your GraphViz version? Has your page rendered properly before? There are several new fixes available on dev-master (see T89325 and subtasks). I suggest upgrading GraphViz to the latest dev-master and trying again.

php composer.phar require mediawiki/graph-viz 'dev-master'

--Welterkj (talk) 17:37, 8 May 2015 (UTC)

• 1.6.0, though it seems to have started sort of to work, for no apparent reason. I'll check out later versions, thank you.
  Alex Mashin (talk) 04:44, 9 May 2015 (UTC)

How to not upload the rendered image and render dynamic graph...

Hello, we're trying to upgrade our Mediawiki site:

• Current:
  • MediaWiki (Version 1.17.0)
  • Semantic MediaWiki extension (Version 1.8)
  • Graphviz extension (Version 0.9.1 alpha)
• Target:
  • MediaWiki (Version 1.25.2)
  • Semantic MediaWiki extension (Version 2.2.2)
  • Graphviz extension (Version 1.6.1 - 1515b85)

Our Graphviz diagrams are dynamic, their content is the result of a semantic mediawiki request.

The source code of the page containing the request and the diagram never changes.

We expect that the diagram is rendered only if the content of the diagram is different and we don't want to upload the image in the Wiki. (this works well with our current version of Graphviz extension)

How could we configure the target version of Graphviz extension to not upload the rendered image in the Wiki and to always render the diagram if its content is modified ?

Best Regards

dot keyword 'edge' does not seem to work. Also adding attributes to edges fail.

While trying to label an edge I get the bad link error in line 2 error message. The same applies doing something like

  edge [label='test']

or

  foo -> bar [label="example"]

inside a graphviz graph. How is that done correctly using the graphviz extension?

Graph image creation requires permission to upload.

Hello,

I am using mediawiki 1.25.3 and latest version of GraphViz i.e. 1.6.1. Unfortunately GraphViz is not working and it is giving an error i.e. "Graph image creation requires permission to upload."

I am using windows 7, with mediawiki is configured on localhost with wamp server. PHP file upload is allowed and the $IP/images folder has writing access as well.

Localsettings.php is configured as required.

require_once "$IP/extensions/GraphViz/GraphViz.php"; 
$wgEnableUploads = true;
$wgGraphVizSettings -> execPath = "C:/Program Files (x86)/Graphviz/bin/" ;
$wgGraphVizSettings -> mscgenPath = "C:/Program Files (x86)/Mscgen";
$wgGraphVizSettings -> defaultImageType = "png";
$wgGraphVizSettings -> createCategoryPages = "no";

But still it is not working :(

I hope you can help me with this.

Thanks

— Preceding unsigned comment added by 134.102.141.166 (talk • contribs) 01:59, 26 November 2015

It's probably not the right answer, but I've had to give the graphviz path as "C:/Progra~1/Graphviz/bin/" in Windows. Might be related. Sam Wilson 04:17, 26 November 2015 (UTC)

Same problem in MW 1.28.2 on Debian 8 running PHP 5.6.30. Solved with:

apt-get install graphviz mscgen
# enabled extension in LocalSettings.php
cd /var/lib/mediawiki/maintenance/
php update.php
which dot circo fdp neato twopi mscgen
# all binaries in /usr/bin/ folder

I had this problem, and I fixed this by adding to LocalSettings.php an appropriate line of this kind $wgGroupPermissions['group']['right'] = true. Replace 'group' and 'right' with the ones you want. You might want "edit" and the "upload" right. Look at Manual:User_rights for more information.--AWindowsWikiUser (talk) 23:00, 1 March 2018 (UTC)

Graph is created then deleted

Hello.

I'm using mediawiki in a windows 7 environment, with an Apache server at localhost.

GraphViz is fully configured and running, but the image graph is created and then deleted, showing nothing on screen. I've reproduced the exact command shown on log ("<program files>\Graphviz2.38\bin\dot.exe" -T "png" -o "<wiki directory>\images\graphviz\images\Example_digraph_G_dot.png" "<wiki directory>\images\graphviz\Example_digraph_G.src") and in fact does create the image, but the folder is empty after refreshing the page (even if I manually put a copy of the intended image there). Where can be the error? Why the data is gone?

Hope you can help, guys

Thanks

Problem apparently solved. It was the same as one of the messages above, and it was solved the same - copying wshellexec from 1.22.15 over the current version

Is there a way to -not- use the ImageMap renderer?

Is there any way to use the extension (programmatically) without the ImageMap functionality?

E.g. I'm using the Graphviz Extension to implement my own custom result format. Currently the GraphViz extensions (GraphViz::graphvizParserHook($graphInput, ...) returns the Image Map embed code. If I embed this into the wikipage, I'll get the Graph image source changed. Reload page to display updated graph image error. Since I'm dynamically displaying the Graph, based on query results, there is no way for me to trigger the onPageSaveComplete hooks (I'm missing the context for that)

So is there a simple way to provide the graphviz code and get something like an SVG or a base64 encoded image (which I can embed directly) returned? The fact that there is no need to create (and delete) image uploads would also be a benefit in this case.

Best, Simon

Tag param preparse="dynamic"

Hi,

I made some additional lines, which makes preparse="dynamic" work better.

One problem was, that sometimes we got stripped results. So I changed line 1040 of GraphViz_body.php from

$input = $parser->recursiveTagParse( $input, $frame );

to

$input = $parser->mStripState->unstripBoth($parser->recursiveTagParse( $input, $frame ),$parser->mStripState);

The next problem is the use of preparse="dynamic" with ImageMaps links. Example:

{{:Testpage GraphViz}} [URL="[[Testpage GraphViz]]"];
or
{{:Testpage GraphViz}} [URL="http://www.sample.org"];

In both cases the parser scrambles the link. So I added stripping and unstripping for the links to the recursiveTagParse:

// strip mw squared brackets and "http" from links
	$input = str_replace ( '[[' , '!mw-link-open-brackets!' , $input );
	$input = str_replace ( ']]' , '!mw-link-close-brackets!' , $input );
	$input = str_replace ( 'http' , '!non-mw-link-http-placeholder!' , $input );
			
	$input = $parser->mStripState->unstripBoth($parser->recursiveTagParse( $input, $frame ),$parser->mStripState);
	//$input = $parser->recursiveTagParse( $input, $frame ); (the replaced above line)
	
// unstrip mw squared brackets and "http" from links
$input = str_replace ( '!mw-link-open-brackets!' , '[[' , $input );
$input = str_replace ( '!mw-link-close-brackets!' , ']]' , $input );
$input = str_replace ( '!non-mw-link-http-placeholder!' , 'http' , $input );

Now links are working with preparse="dynamic" param.

If you want to use HTML-Like Labels and preparse="dynamic" together, you can add these 4 lines:

Before recursiveTagParse:

$input = str_replace ( '<' , '!tag-open!' , $input );
$input = str_replace ( '>' , '!tag-close!' , $input );

After recursiveTagParse:

$input = str_replace ( '!tag-open!' , '<' , $input );
$input = str_replace ( '!tag-close!' , '>' , $input );

Now you can include templates. If you want to use other MW tags, you have to place them in a template and include the template.

Baxi69 (talk) 19:12, 24 February 2016 (UTC)

Frequently uploaded and deleted dummy file in 1.6.0 (File graph GraphVizExtensionDummy dot.svg) ?

Why is there a dummy file uploaded and deleted, it seems to my by accident or is there a reason that this happens so often? It is somewhat annoying and not documented. Note that there is no graphviz file on the page or gets this triggered by some semantic mediawiki result function ? --Andreas P. 00:36, 27 February 2016 (UTC)

Bug. Function initDummyFilePages() - it will delete and recreate the file if the file has more than one page revision, but for some reason it creates said page with an earlier blank revision. I don't see the purpose behind the constant deletion/recreation, as they're likely identical on each revision. --Sigma 7 (talk) 17:06, 6 May 2016 (UTC)

I opened task T100795 to track this. -- Prod (talk) 23:10, 6 May 2016 (UTC)

I have de same Error, but Welterkj don't have recent activity :-( https://phabricator.wikimedia.org/p/Welterkj/ AlainBB

Incorrect behavior with type='thumb'

I am not sure if it is specifically my issue, but an attempt to create a graph with "type='thumb'" attribute causes the text after the produced image to be a link to the image, as if <a> HTML tag wasn't closed. This happens for Firefox, Chrome and IE. --77.34.230.87 11:07, 4 June 2016 (UTC)

Using for MW 1.26 or 1.27

Hello, I've up until now used the extension FlowChartWiki for my wiki and it worked fine, although due to limitations I've chosen to switch to GraphViz, but I can't get it to create any graphs without changing (as previously mentioned) the wfShellExec in globalsettings.php. The issue with this is that when I change to the MW version 1.22's wfShellExec which makes ImageMap and GraphViz throw errors. ImageMap:

 Fatal error: Call to undefined method OutputPage::transformResourcePath() in C:\wamp\www\mediawiki-1.26.2\extensions\ImageMap\ImageMap_body.php on line 346

#	Time	Memory	Function	Location
1	0.0010	257880	{main}( )	..\index.php:0
2	0.2370	14689840	MediaWiki->run( )	..\index.php:41
3	0.2370	14691248	MediaWiki->main( )	..\MediaWiki.php:508
4	0.3070	17720640	MediaWiki->performRequest( )	..\MediaWiki.php:714
5	0.3220	18646808	MediaWiki->performAction( )	..\MediaWiki.php:287
6	0.3220	18647224	SubmitAction->show( )	..\MediaWiki.php:490
7	0.3220	18647432	EditAction->show( )	..\SubmitAction.php:40
8	0.3300	19632464	EditPage->edit( )	..\EditAction.php:58
9	0.5441	20745504	EditPage->attemptSave( )	..\EditPage.php:560
10	0.5441	20749944	EditPage->internalAttemptSave( )	..\EditPage.php:1331
11	0.5631	21448936	doEditContent ( )	..\EditPage.php:1957
12	0.5631	21449672	Article->__call( )	..\EditPage.php:1957
13	0.5631	21450088	call_user_func_array:{C:\wamp\www\mediawiki-1.26.2\includes\page\Article.php:2049} ( )	..\Article.php:2049
14	0.5631	21452568	WikiPage->doEditContent( )	..\Article.php:2049
15	2.3672	34804376	WikiPage->prepareContentForEdit( )	..\WikiPage.php:1757
16	2.3782	34836408	AbstractContent->getParserOutput( )	..\WikiPage.php:2117
17	2.3782	34840976	WikitextContent->fillParserOutput( )	..\AbstractContent.php:497
18	2.3782	34841120	Parser->parse( )	..\WikitextContent.php:331
19	2.3792	34848776	Parser->internalParse( )	..\Parser.php:439
20	2.3792	34849200	Parser->replaceVariables( )	..\Parser.php:1239
21	2.3802	34850736	PPFrame_DOM->expand( )	..\Parser.php:3364
22	2.4532	35642128	Parser->extensionSubstitution( )	..\Preprocessor_DOM.php:1262
23	2.4542	35643320	call_user_func_array:{C:\wamp\www\mediawiki-1.26.2\includes\parser\Parser.php:4308} ( )	..\Parser.php:4308
24	2.4542	35643464	GraphViz::graphvizParserHook( )	..\Parser.php:4308
25	2.4542	35643768	GraphViz::render( )	..\GraphViz_body.php:802
26	3.2723	35668888	ImageMap::render( )	..\GraphViz_body.php:1262

Changing back to the current versions wfShellExec the graphs that had been created and were located in ../mediawiki/images/graphviz/ all gets removed. The only way to get this to work is by using an old version on ImageMap aswell, which works fine as a temporary solution. But this might become troublesome in the future for extensions dependent on ImageMap and on new versions of mediawiki which uses another wfShellExec.

So I suppose my question would be if there is a fix for using MW 1.26+ with the latest versions of GraphViz and ImageMap.

Thanks in advance and sorry for a long post.

Best regards, Stavflel

Dear Stavflel, Have there been any developments since you last posted the problem for MediaWiki 1.26+ on Windows ? I too have the issue, and was hoping for more information.....

Images in nodes

I've installed the latest version (not Master) via Composer into MediaWiki with Semantic MediaWiki. I can produce graphs fine, either with a semantic query or using the graphviz tags and dot language. What I can't seem to do is successfully use an image.

Example of graph:

<graphviz renderer="dot" caption="GraphViz test">
digraph examplesystem {
    rankdir="LR"; 
    node[minlen=3, width=0.15, height=0.15, group=main];
    edge[arrowhead=none];
    "Planet 1" [image="[[File:Planet Image.png|mouseover]]" ];
    Star -> "Planet 1" -> "Planet 2" -> "Planet 3" -> "Planet 4" -> "Planet 5" -> "Planet 6" -> "Planet 7";
    node[minlen=1, group=branches];
    "Planet 2" ->  "Moonbase";
    "Planet 2" ->  "Dr Who Villain";
    "Planet 5" -> "Tardis";
}
</graphviz>

Planet Image.png is uploaded as a file of that name into my MediaWiki instance, but when I use that markup, I get the error message "The dot image attribute must be the name of an uploaded file." Using [[File:Planet Image.png|mouseover]] works as expected. I've tried various different changes but if I don't set it up like that I'll get GV_FILE_PATH errors etc. This matches a query on the SMW site which is also unanswered (link to query).

— Preceding unsigned comment added by RDGGDR (talk • contribs) 16:47, 20 September 2016

• @RDGGDR: The image attribute should just contain the actual filename of the image (and it has to be a locally-uploaded image, too; i.e. not via InstantCommons). So:

  "Planet 1" [image="Planet Image.png"];

  —Sam Wilson 00:21, 24 November 2016 (UTC)

• @Samwilson: Thanks - unfortunately that produces the following error messages:

Warning: file loading is disabled because the environment contains: domain.name
and there is no GV_FILE_PATH variable.
Warning: "/home/filestructure/wikidirectory/images/f/f5/Planet Image.png" was not found as a file or as a shape library member
Warning: No or improper image="/home/filestructure/wikidirectory/images/f/f5/Planet Image.png" for node "Planet 1"

This looks to me like it's a thing that should be set by the extension (given the extension does not permit imagepath) and I am not sure how I would set it manually. I'm using GraphViz installed via Composer on shared hosting. RDGGDR (talk) 21:43, 21 December 2016 (UTC) 21:41, 21 December 2016 (UTC)

Double encoding problem (patch for review)

There seems to be a problem with URLs in graphs like the following:

<graphviz>
digraph g {
  test [URL="https://example.com/index.php?one&two" label="Test node"]
}
</graphviz>

This results in a link like: https://example.com/?one&two (i.e. the ampersand is represented by an HTML entity).

I've got a patch to fix this: https://gerrit.wikimedia.org/r/#/c/322834/ and would love anyone to come and review it.

Thanks! —Sam Wilson 04:29, 15 December 2016 (UTC)

Extension failure on private wiki

I am fairly sure this extension will not work with locked down users because an asynchronous upload page is created for the generated image and that page creation is being done by an anonymous user... does anyone have a suggestion how to work around that limitation? 192.41.148.220 19:20, 21 December 2016 (UTC)

Incompatibility with AbuseFilter and SpamBlackList extensions - MW 1.28; MW 1.27 works fine

• MediaWiki 1.28.0
• PHP 7.0.14 (apache2handler)
• MariaDB 10.1.20-MariaDB
• ICU 58.1

Dependant extension ImageMap was enabled without any problems. After installing GraphViz (first version 1.28 from https://www.mediawiki.org/wiki/Special:ExtensionDistributor/GraphViz - GraphViz-GraphViz-REL1_28-16ae1dc.tar.gz, later latest from git - mediawiki-extensions-GraphViz-master.zip; the results were the same) there were the following problems:

Message: Graph image source changed. Reload page to display updated graph image. during preview in WikiEditor.

TypeError from line 218 of /extensions/SpamBlacklist/SpamBlacklistHooks.php: Argument 3 passed to SpamBlacklistHooks::onUploadVerifyUpload() must be of the type array, null given, called in /includes/Hooks.php on line 195

Backtrace:

1. 0 /includes/Hooks.php(195): SpamBlacklistHooks::onUploadVerifyUpload(UploadFromLocalFile, User, NULL, string, string, NULL)
2. 1 /includes/upload/UploadBase.php(751): Hooks::run(string, array)
3. 2 /extensions/GraphViz/UploadLocalFile.php(238): UploadBase->performUpload(string, string, boolean, User)
4. 3 /extensions/GraphViz/GraphViz_body.php(549): UploadLocalFile::upload(string, string, User, string, string, boolean, boolean)
5. 4 /extensions/GraphViz/GraphViz_body.php(468): GraphViz::uploadImages(string, array, User, string)
6. 5 /extensions/GraphViz/GraphViz_body.php(699): GraphViz::uploadImagesForTitle(Title, User)
7. 6 /extensions/GraphViz/GraphViz_body.php(683): GraphViz::onTitleSaveComplete(Title)
8. 7 /includes/Hooks.php(195): GraphViz::onPageContentSaveComplete(WikiPage, User, WikitextContent, string, integer, NULL, NULL, integer, Revision, Status, boolean)
9. 8 /includes/page/WikiPage.php(1912): Hooks::run(string, array)
10. 9 /includes/libs/rdbms/database/Database.php(2668): WikiPage->{closure}(DatabaseMysqli, string)
11. 10 /includes/deferred/AtomicSectionUpdate.php(33): Database->doAtomicSection(string, Closure)
12. 11 /includes/deferred/DeferredUpdates.php(263): AtomicSectionUpdate->doUpdate()
13. 12 /includes/deferred/DeferredUpdates.php(225): DeferredUpdates::runUpdate(AtomicSectionUpdate, LBFactorySimple, integer)
14. 13 /includes/deferred/DeferredUpdates.php(129): DeferredUpdates::execute(array, string, integer)
15. 14 /includes/MediaWiki.php(592): DeferredUpdates::doUpdates(string, integer)
16. 15 /includes/MediaWiki.php(561): MediaWiki::preOutputCommit(RequestContext, Closure)
17. 16 /includes/MediaWiki.php(867): MediaWiki->doPreOutputCommit(Closure)
18. 17 /includes/MediaWiki.php(512): MediaWiki->main()
19. 18 /index.php(43): MediaWiki->run()
20. 19 {main}

The extension (installation from https://www.mediawiki.org/wiki/Special:ExtensionDistributor/GraphViz - GraphViz-REL1_27-6281429.tar.gz) is working fine on MW 1.27, the following configuration:

• MediaWiki 1.27.1
• PHP 7.0.14 (apache2handler)
• MariaDB 10.1.20-MariaDB
• ICU 58.1

together with SpamBlackList and AbuseFilter extensions except the message 'Graph image source changed. Reload page to display updated graph image.' during preview in WikiEditor. The message can be ignored and the page saved.

This is the third time I encountered the problems with the extensions under MW 1.28 that worked fined under MW 1.27, I suspect the problem might be in the MW 1.28 interface than the extensions themselves.

They changed the way SpamBlacklist works in https://phabricator.wikimedia.org/T134453. They had to update UploadWizard to work with it, so this would probably need the same thing. -- Prod (talk) 04:49, 5 January 2017 (UTC)

[LocalFile] Failed to lock 'File_graph_GraphVizExtensionDummy_dot.gif'

When I try to add a graph to a page, I get following error message (translated from Swedish)

Action failed
Could not open lock file "mwstore://local-backend/local-public/5/51/File_graph_GraphVizExtensionDummy_dot.gif".

I the debug log, I find following:

Unstubbing $wgParser on call of $wgParser::_unstub from GraphViz::initDummyFilePages
[DBQuery] mediawiki SELECT /* LinkCache::fetchPageRow  */  page_id,page_len,page_is_redirect,page_latest,page_content_model,page_touched  FROM `mw_page`    WHERE page_namespace = '6' AND page_title = 'File_graph_GraphVizExtensionDummy_dot.gif'  LIMIT 1  
GraphViz::initDummyFilePages: file page for File_graph_GraphVizExtensionDummy_dot.gif does not exist
GraphRenderParms::__construct: userName: Magolsso graphName: File_graph_GraphVizExtensionDummy
GraphRenderParms::__construct: sourceAndMapDir: /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/ imageDir: /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/
GraphRenderParms::__construct: renderer: dot imageType: gif
GraphViz::render: isPreview:  saving:  isDummy: 1
GraphViz::render: preParseType: none doRecursiveTagParse:
[DBQuery] mediawiki SELECT /* LocalFile::loadFromDB  */  img_size,img_width,img_height,img_bits,img_media_type,img_major_mime,img_minor_mime,img_metadata,img_timestamp,img_sha1,img_user,img_user_text,img_description  FROM `mw_image`    WHERE img_name = 'File_graph_GraphVizExtensionDummy_dot.gif'  LIMIT 1  
[DBQuery] mediawiki SELECT /* LocalRepo::{closure}  */  rd_namespace,rd_title  FROM `mw_page`,`mw_redirect`    WHERE page_namespace = '6' AND page_title = 'File_graph_GraphVizExtensionDummy_dot.gif' AND (rd_from = page_id)  LIMIT 1  
GraphViz::render: imageExists:  mapExists: 1
GraphViz::isSourceChanged: /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/File_graph_GraphVizExtensionDummy.src matches wiki text
GraphViz::render: sourceChanged:
wfShellExec: /bin/bash '/opt/bitnami/apps/mediawiki/htdocs/includes/limit.sh' ''\''/usr/bin/dot'\'' -T '\''gif'\'' -o '\''/opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif'\'' '\''/opt/bitnami/apps/mediawiki/htdocs/images/graphviz/File_graph_GraphVizExtensionDummy.src'\'' 2>&1' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=300; MW_CGROUP='\'''\''; MW_MEM_LIMIT=409600; MW_FILE_SIZE_LIMIT=307200; MW_WALL_CLOCK_LIMIT=180; MW_USE_LOG_PIPE=yes'
[Mime] MimeAnalyzer::doGuessMimeType: analyzing head and tail of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif for magic numbers.
[Mime] MimeAnalyzer::doGuessMimeType: getimagesize detected /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif as image/gif
[Mime] MimeAnalyzer::guessMimeType: guessed mime type of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif: image/gif
[Mime] MimeAnalyzer::doGuessMimeType: analyzing head and tail of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif for magic numbers.
[Mime] MimeAnalyzer::doGuessMimeType: getimagesize detected /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif as image/gif
[Mime] MimeAnalyzer::guessMimeType: guessed mime type of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif: image/gif
[DBQuery] mediawiki SELECT /* Title::getTitleProtection  */  pt_user AS `user`,pt_reason AS `reason`,pt_expiry AS `expiry`,pt_create_perm AS `permission`  FROM `mw_protected_titles`    WHERE pt_namespace = '6' AND pt_title = 'File_graph_GraphVizExtensionDummy_dot.gif'  
[DBQuery] mediawiki SELECT /* Title::getCascadeProtectionSources  */  pr_page,page_namespace,page_title,pr_expiry,pr_type,pr_level  FROM `mw_imagelinks`,`mw_page_restrictions`,`mw_page`    WHERE il_to = 'File_graph_GraphVizExtensionDummy_dot.gif' AND (il_from=pr_page) AND pr_cascade = '1' AND (page_id=pr_page)  
[DBQuery] mediawiki SELECT /* LocalFile::loadFromDB  */  img_size,img_width,img_height,img_bits,img_media_type,img_major_mime,img_minor_mime,img_metadata,img_timestamp,img_sha1,img_user,img_user_text,img_description  FROM `mw_image`    WHERE img_name = 'File_graph_GraphVizExtensionDummy_dot.gif'  LIMIT 1  
wfShellExec: /bin/bash '/opt/bitnami/apps/mediawiki/htdocs/includes/limit.sh' ''\''/usr/bin/dot'\'' -T '\''cmapx'\'' -o '\''/opt/bitnami/apps/mediawiki/htdocs/images/graphviz/File_graph_GraphVizExtensionDummy_dot.map'\'' '\''/opt/bitnami/apps/mediawiki/htdocs/images/graphviz/File_graph_GraphVizExtensionDummy.src'\'' 2>&1' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=300; MW_CGROUP='\'''\''; MW_MEM_LIMIT=409600; MW_FILE_SIZE_LIMIT=307200; MW_WALL_CLOCK_LIMIT=180; MW_USE_LOG_PIPE=yes'
GraphViz::render: File graph GraphVizExtensionDummy dot.gif does not exist
GraphViz::disableHooks: hooks disabled
[DBQuery] mediawiki SELECT /* LocalFile::loadFromDB  */  img_size,img_width,img_height,img_bits,img_media_type,img_major_mime,img_minor_mime,img_metadata,img_timestamp,img_sha1,img_user,img_user_text,img_description  FROM `mw_image`    WHERE img_name = 'File_graph_GraphVizExtensionDummy_dot.gif'  LIMIT 1  
[Mime] MimeAnalyzer::doGuessMimeType: analyzing head and tail of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif for magic numbers.
[Mime] MimeAnalyzer::doGuessMimeType: getimagesize detected /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif as image/gif
[Mime] MimeAnalyzer::guessMimeType: guessed mime type of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif: image/gif
[LocalFile] Failed to lock 'File_graph_GraphVizExtensionDummy_dot.gif'
Unstubbing $wgParser on call of $wgParser::_unstub from GraphViz::initDummyFilePages
[DBQuery] mediawiki SELECT /* LinkCache::fetchPageRow  */  page_id,page_len,page_is_redirect,page_latest,page_content_model,page_touched  FROM `mw_page`    WHERE page_namespace = '6' AND page_title = 'File_graph_GraphVizExtensionDummy_dot.gif'  LIMIT 1  
GraphViz::initDummyFilePages: file page for File_graph_GraphVizExtensionDummy_dot.gif does not exist
GraphRenderParms::__construct: userName: Magolsso graphName: File_graph_GraphVizExtensionDummy
GraphRenderParms::__construct: sourceAndMapDir: /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/ imageDir: /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/
GraphRenderParms::__construct: renderer: dot imageType: gif
GraphViz::render: isPreview:  saving:  isDummy: 1
GraphViz::render: preParseType: none doRecursiveTagParse:
[DBQuery] mediawiki SELECT /* LocalFile::loadFromDB  */  img_size,img_width,img_height,img_bits,img_media_type,img_major_mime,img_minor_mime,img_metadata,img_timestamp,img_sha1,img_user,img_user_text,img_description  FROM `mw_image`    WHERE img_name = 'File_graph_GraphVizExtensionDummy_dot.gif'  LIMIT 1  
[DBQuery] mediawiki SELECT /* LocalRepo::{closure}  */  rd_namespace,rd_title  FROM `mw_page`,`mw_redirect`    WHERE page_namespace = '6' AND page_title = 'File_graph_GraphVizExtensionDummy_dot.gif' AND (rd_from = page_id)  LIMIT 1  
GraphViz::render: imageExists:  mapExists: 1
GraphViz::isSourceChanged: /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/File_graph_GraphVizExtensionDummy.src matches wiki text
GraphViz::render: sourceChanged:
wfShellExec: /bin/bash '/opt/bitnami/apps/mediawiki/htdocs/includes/limit.sh' ''\''/usr/bin/dot'\'' -T '\''gif'\'' -o '\''/opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif'\'' '\''/opt/bitnami/apps/mediawiki/htdocs/images/graphviz/File_graph_GraphVizExtensionDummy.src'\'' 2>&1' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=300; MW_CGROUP='\'''\''; MW_MEM_LIMIT=409600; MW_FILE_SIZE_LIMIT=307200; MW_WALL_CLOCK_LIMIT=180; MW_USE_LOG_PIPE=yes'
[Mime] MimeAnalyzer::doGuessMimeType: analyzing head and tail of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif for magic numbers.
[Mime] MimeAnalyzer::doGuessMimeType: getimagesize detected /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif as image/gif
[Mime] MimeAnalyzer::guessMimeType: guessed mime type of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif: image/gif
[Mime] MimeAnalyzer::doGuessMimeType: analyzing head and tail of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif for magic numbers.
[Mime] MimeAnalyzer::doGuessMimeType: getimagesize detected /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif as image/gif
[Mime] MimeAnalyzer::guessMimeType: guessed mime type of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif: image/gif
[DBQuery] mediawiki SELECT /* Title::getTitleProtection  */  pt_user AS `user`,pt_reason AS `reason`,pt_expiry AS `expiry`,pt_create_perm AS `permission`  FROM `mw_protected_titles`    WHERE pt_namespace = '6' AND pt_title = 'File_graph_GraphVizExtensionDummy_dot.gif'  
[DBQuery] mediawiki SELECT /* Title::getCascadeProtectionSources  */  pr_page,page_namespace,page_title,pr_expiry,pr_type,pr_level  FROM `mw_imagelinks`,`mw_page_restrictions`,`mw_page`    WHERE il_to = 'File_graph_GraphVizExtensionDummy_dot.gif' AND (il_from=pr_page) AND pr_cascade = '1' AND (page_id=pr_page)  
[DBQuery] mediawiki SELECT /* LocalFile::loadFromDB  */  img_size,img_width,img_height,img_bits,img_media_type,img_major_mime,img_minor_mime,img_metadata,img_timestamp,img_sha1,img_user,img_user_text,img_description  FROM `mw_image`    WHERE img_name = 'File_graph_GraphVizExtensionDummy_dot.gif'  LIMIT 1  
wfShellExec: /bin/bash '/opt/bitnami/apps/mediawiki/htdocs/includes/limit.sh' ''\''/usr/bin/dot'\'' -T '\''cmapx'\'' -o '\''/opt/bitnami/apps/mediawiki/htdocs/images/graphviz/File_graph_GraphVizExtensionDummy_dot.map'\'' '\''/opt/bitnami/apps/mediawiki/htdocs/images/graphviz/File_graph_GraphVizExtensionDummy.src'\'' 2>&1' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=300; MW_CGROUP='\'''\''; MW_MEM_LIMIT=409600; MW_FILE_SIZE_LIMIT=307200; MW_WALL_CLOCK_LIMIT=180; MW_USE_LOG_PIPE=yes'
GraphViz::render: File graph GraphVizExtensionDummy dot.gif does not exist
GraphViz::disableHooks: hooks disabled
[DBQuery] mediawiki SELECT /* LocalFile::loadFromDB  */  img_size,img_width,img_height,img_bits,img_media_type,img_major_mime,img_minor_mime,img_metadata,img_timestamp,img_sha1,img_user,img_user_text,img_description  FROM `mw_image`    WHERE img_name = 'File_graph_GraphVizExtensionDummy_dot.gif'  LIMIT 1  
[Mime] MimeAnalyzer::doGuessMimeType: analyzing head and tail of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif for magic numbers.
[Mime] MimeAnalyzer::doGuessMimeType: getimagesize detected /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif as image/gif
[Mime] MimeAnalyzer::guessMimeType: guessed mime type of /opt/bitnami/apps/mediawiki/htdocs/images/graphviz/images/File_graph_GraphVizExtensionDummy_dot.gif: image/gif
[LocalFile] Failed to lock 'File_graph_GraphVizExtensionDummy_dot.gif'

--Magol (talk) 22:47, 12 February 2017 (UTC)

Database error for MySQL 5.7+

Tracked in Phabricator
Task T160057

Setup

• MediaWiki 1.27.1 (8c593e7) 22:49, 26 October 2016
• PHP 7.0.15-0ubuntu0.16.04.4 (apache2handler)
• MySQL 5.7.17-0ubuntu0.16.04.1
• Graphviz 1.6.1 (1515b85) 19:26, 16 June 2015

Issue

Database error

A database query error has occurred. This may indicate a bug in the software.

Query

    UPDATE  `image` SET img_size = '0',img_width = '0',img_height = '0',img_bits = '0',img_media_type = 'DRAWING',img_major_mime = 'inode',img_minor_mime = 'x-empty',img_timestamp = '20170307175458',img_description = 'generated by the GraphViz [[Special:Version#Installed_extensions|extension]] from the [[File:File graph GraphVizExtensionDummy dot.jpeg]] page',img_user = '74',img_user_text = 'Kghbln',img_metadata = '',img_sha1 = 'phoiac9h4m842xq45sp7s6u21eteeq1' WHERE img_name = 'File_graph_GraphVizExtensionDummy_dot.svg'

Function

LocalFile::recordUpload2

Error

1265 Data truncated for column 'img_major_mime' at row 1 (localhost)

Backtrace

#0 /.../w/includes/db/Database.php(901): DatabaseBase->reportQueryError('Data truncated ...', 1265, 'UPDATE  `image`...', 'LocalFile::reco...', false)
#1 /.../w/includes/db/Database.php(1512): DatabaseBase->query('UPDATE  `image`...', 'LocalFile::reco...')
#2 /.../w/includes/filerepo/file/LocalFile.php(1353): DatabaseBase->update('`image`', Array, Array, 'LocalFile::reco...')
#3 /.../w/includes/filerepo/file/LocalFile.php(1174): LocalFile->recordUpload2('20170307175458!...', 'generated by th...', '[[Category:Grap...', Array, '20170307175458', Object(User), Array)
#4 /.../w/includes/upload/UploadBase.php(727): LocalFile->upload('/var/www/html/0...', 'generated by th...', '[[Category:Grap...', 1, Array, false, Object(User), Array)
#5 /.../w/extensions/GraphViz/UploadLocalFile.php(238): UploadBase->performUpload('generated by th...', '[[Category:Grap...', false, Object(User))
#6 /.../w/extensions/GraphViz/GraphViz_body.php(549): UploadLocalFile::upload('File_graph_Grap...', '/var/www/html/0...', Object(User), 'generated by th...', '[[Category:Grap...', false, true)
#7 /.../w/extensions/GraphViz/GraphViz_body.php(468): GraphViz::uploadImages('File:File graph...', Array, Object(User), '')
#8 /.../w/extensions/GraphViz/GraphViz_body.php(699): GraphViz::uploadImagesForTitle(Object(Title), Object(User))
#9 /.../w/extensions/GraphViz/GraphViz_body.php(683): GraphViz::onTitleSaveComplete(Object(Title))
#10 /.../w/includes/Hooks.php(195): GraphViz::onPageContentSaveComplete(Object(WikiFilePage), Object(User), Object(WikitextContent), 'generated by th...', 0, NULL, NULL, 9, Object(Revision), Object(Status), false)
#11 /.../w/includes/page/WikiPage.php(1952): Hooks::run('PageContentSave...', Array)
#12 /.../w/includes/db/Database.php(2482): WikiPage->{closure}()
#13 /.../w/includes/db/Database.php(2454): DatabaseBase->runOnTransactionIdleCallbacks()
#14 /.../w/includes/page/WikiPage.php(1954): DatabaseBase->onTransactionIdle(Object(Closure))
#15 /.../w/includes/page/WikiPage.php(1657): WikiPage->doCreate(Object(WikitextContent), 9, Object(User), 'generated by th...', Array)
#16 /.../w/includes/filerepo/file/LocalFile.php(1437): WikiPage->doEditContent(Object(WikitextContent), 'generated by th...', 9, false, Object(User))
#17 /.../w/includes/db/Database.php(2482): LocalFile->{closure}()
#18 /.../w/includes/db/Database.php(2693): DatabaseBase->runOnTransactionIdleCallbacks()
#19 /.../w/includes/db/loadbalancer/LoadBalancer.php(1055): DatabaseBase->commit('MediaWiki::preO...', 'flush')
#20 /.../w/includes/db/loadbalancer/LBFactory.php(206): LoadBalancer->commitMasterChanges('MediaWiki::preO...')
#21 /.../w/includes/db/loadbalancer/LBFactorySimple.php(154): LBFactory->{closure}(Object(LoadBalancer), 'commitMasterCha...', Array)
#22 /.../w/includes/db/loadbalancer/LBFactory.php(208): LBFactorySimple->forEachLB(Object(Closure), Array)
#23 /.../w/includes/db/loadbalancer/LBFactory.php(250): LBFactory->forEachLBCallMethod('commitMasterCha...', Array)
#24 /.../w/includes/MediaWiki.php(560): LBFactory->commitMasterChanges('MediaWiki::preO...', Array)
#25 /.../w/includes/MediaWiki.php(539): MediaWiki::preOutputCommit(Object(RequestContext))
#26 /.../w/includes/MediaWiki.php(750): MediaWiki->doPreOutputCommit()
#27 /.../w/includes/MediaWiki.php(519): MediaWiki->main()
#28 /.../w/index.php(43): MediaWiki->run()
#29 {main}

A fix will be great. Cheers --[[kgh]] (talk) 22:57, 7 March 2017 (UTC)

File looping

Tracked in Phabricator
Task T100795

Setup

• MediaWiki 1.27.1 (8c593e7) 22:49, 26 October 2016
• PHP 7.0.15-0ubuntu0.16.04.4 (apache2handler)
• MySQL 5.7.17-0ubuntu0.16.04.1
• Graphviz 1.6.1 (1515b85) 19:26, 16 June 2015

Issue

On every edit I do on the wiki the file "File:File graph GraphVizExtensionDummy dot.svg" gets automatically deleted by this extension and at the same time automatically regenerated by the extension.

I have no idea what this is all about. A fix will be great. Cheers --[[kgh]] (talk) 23:11, 7 March 2017 (UTC)

This is phab:T100795. Sam Wilson 01:38, 8 March 2017 (UTC)

Using Graphviz Server (Container)

In times of docker it could be a good idea to move graphviz into an own container and use some http interface. Looks like there is such a project: https://github.com/omerio/graphviz-server Not sure if this could be used with the mediawiki plugin already? But could be a simple plugin parsing the graphviz tag sending the data to backend and receive the image.

graphviz imagemap use just one link

In the example below two nodes with different links result in an formally correct imagemap but using only the first link, what is the problem here?

<graphviz caption="Imagemap test">
digraph example3 {
  Google [URL="http://www.google.com" TITLE="Google"];
  Bing [URL="http://www.bing.com" TITLE="Bing"];
}
</graphviz>

<map name="ImageMap_1_1963306097"><area href="http://www.google.com" class="plainlinks" rel="nofollow" shape="poly" coords="102,29,99,22,93,15,82,10,68,7,53,5,38,7,25,10,14,15,7,22,5,29,7,37,14,43,25,49,38,52,53,53,68,52,82,49,93,43,99,37" alt="Google" title="Google"/><area href="http://www.google.com" class="plainlinks" rel="nofollow" shape="poly" coords="200,29,198,22,193,15,185,10,174,7,163,5,151,7,141,10,133,15,127,22,125,29,127,37,133,43,141,49,151,52,163,53,174,52,185,49,193,43,198,37" alt="Google" title="Google"/></map>

Which version to use for MW 1.27 (2.1.0?)

Using latest version of GraphViz in an MW 1.27 environment with composer loads 3.0.0 giving the error:

Fatal error: Uncaught Exception: /var/www/mediawiki/code/extensions/GraphViz/extension.json: unsupported manifest_version: 2 in /var/www/mediawiki/code/includes/registration/ExtensionRegistry.php:195 Stack trace: #0 /var/www/mediawiki/code/includes/registration/ExtensionRegistry.php(137):

which is also something to be expeced when looking at the json file

{
  "name": "GraphViz",
  "version": "3.0.0",
  "type": "parserhook",
  "author": [
    "Keith Welter",
    "[https://meta.wikimedia.org/wiki/User:Coffman Victor Fariña]",
    "[https://www.mediawiki.org/wiki/User:Matthewpearson Matthew Pearson]",
    "[https://www.mediawiki.org/wiki/User:Hummel-riegel Thomas Hummel]",
    "Gregory Szorc"
  ],
  "url": "https://www.mediawiki.org/wiki/Extension:GraphViz",
  "descriptionmsg": "graphviz-desc",
  "license-name": "GPL-2.0+",
  "requires": {
    "MediaWiki": ">= 1.29.0"
  },
...

stating Mediawiki 1.29 is required. But which version of the Graphviz extension is still compatible with MW 1.27?

• https://github.com/wikimedia/mediawiki-extensions-GraphViz/blob/master/RELEASE-NOTES.md

seems to answer this with: 2.1.0 leading to a composer.json entry of:

"mediawiki/graph-viz": "2.1.*",

Which also means wfLoadExtension is not available and

require_once "$IP/extensions/GraphViz/GraphViz.php";

has to be used --WolfgangFahl (talk) 10:23, 27 December 2017 (UTC)

AFAIK, GraphViz version 2.1.0 works fine with MW 1.27. According to the usage and version matrix, several installations are doing so. --Welterkj

ExecPath issue

I've had to locally install GraphViz because I'm on shared hosting with 1and1. I did this by downloading, configuring the script, make then make install. I didn't get any killer errors. However it does mean that I need to specify the execPath in LocalSettings.php.

I've tried the following:

$wgGraphVizSettings->execPath = '$HOME/adirectory/bin/graphviz24/bin/'

and if I do ls $HOME/adirectory/bin/graphviz24/bin/ then it lists the correct files including dot

Despite setting the execPath option I still get the error message: /bin/bash: /usr/bin/dot: No such file or directory.

Any ideas on why it's ignoring my specified execPath?

instant commons

I get "The dot image attribute must be the name of an uploaded file" when referencing a file with $wgUseInstantCommons = true; What can I do about fixing this? For more info see developer support discussion --WolfgangFahl (talk) 18:27, 7 March 2018 (UTC)

Status report on activation across Wikis

Any chance to see this live on English Wikipedia or on Wikimedia commons any time soon? It looks like some people have tried to use it, but the extension isn't active. Daask (talk) 14:00, 27 March 2018 (UTC)

$wgGraphVizSettings->createCategoryPages = "yes";

After I updated GraphViz to 3.0.0, I constantly get following warning message from Apache

PHP Warning:  Creating default object from empty value in /var/www/html/LocalSettings.php on line 51

On line 51, I have following setting:

$wgGraphVizSettings->createCategoryPages      = "yes";

--Magol (talk) 10:09, 16 June 2018 (UTC)

No charts showing on Windows

Hi

I am running GraphViz on a Windows 2012 R2 server, the Apache is WAMPserver.

I have installed GraphViz, have the extension installed on the Wiki, but I'm not getting any charts when I try the examples.

I have WAMP on a D Drive and GraphViz on the C drive, do these both need to be on the same drive?

Any help is appreciated

Gary

--Squeak24 (talk) 11:42, 17 October 2018 (UTC)

Not sure how often this page gets checked, but I have tried again today, and now I get an even weirder error.

I have tried to use:

=== Example 1 from http://www.mediawiki.org/wiki/Extension:GraphViz ===
<graphviz border='frame' format='png' desc='none'>
digraph example1 {Hello->"World!"}
</graphviz>

In the settings.php file I have the following set:

/**
 * Constructor for setting configuration variable defaults.
 */
public function __construct() {
    $this->execPath = 'C:\Program Files (x86)\Graphviz2.38\bin';
    $this->mscgenPath = 'C:\Program Files (x86)\Mscgen';
    $this->defaultImageType = 'png';
    $this->createCategoryPages = 'no';
}

My WAMPserver is installed on D:\wamp64

These are a sample of the errors I am getting in the log:

[Thu Oct 18 15:33:27.491049 2018] [core:error] [pid 2968:tid 956] (20024)The given path is misformatted or contained invalid characters: [client IP removed:62054] AH00127: Cannot map GET /index.php/Category:ICT_joining_rules HTTP/1.1 to file, referer: http://domain.com/index.php/Start_using
[Thu Oct 18 15:33:53.323523 2018] [core:error] [pid 2968:tid 956] (20024)The given path is misformatted or contained invalid characters: [client IP removed:63282] AH00127: Cannot map GET /index.php/Category:ICT_joining_rules HTTP/1.1 to file, referer: http://domain.com/index.php/Start_using
[Thu Oct 18 15:35:11.457123 2018] [core:error] [pid 2968:tid 968] (20024)The given path is misformatted or contained invalid characters: [client IP removed:56258] AH00127: Cannot map GET /entarch/index.php/Draft:GraphViz_Test HTTP/1.1 to file, referer: http://domain.com/index.php?title=Draft:GraphViz_Test&action=submit
[Thu Oct 18 15:37:18.547916 2018] [core:error] [pid 2968:tid 964] (20024)The given path is misformatted or contained invalid characters: [client IP removed:56309] AH00127: Cannot map GET /entarch/index.php/Draft:GraphViz_Test HTTP/1.1 to file, referer: http://domain.com/entarch/index.php?title=Draft:GraphViz_Test&action=submit
[Thu Oct 18 15:39:09.879080 2018] [core:error] [pid 2968:tid 984] (20024)The given path is misformatted or contained invalid characters: [client IP removed:56329] AH00127: Cannot map GET /entarch/index.php/Draft:GraphViz_Test HTTP/1.1 to file, referer: http://domain.com/index.php?title=Draft:GraphViz_Test&action=submit

I have imagemaps installed as well.

The error I am getting on the screen now is:

Internal error
[a717ce182645dbbb732b478c] 2018-10-18 15:22:31: Fatal exception of type "ParseError"

Anyone know what's going wrong?

Any help is appreciated.

--Squeak24 (talk) 15:23, 18 October 2018 (UTC)

OK, so I got that parser issue resolved. I now have the following in the settings file, but still no charts:

/**
 * Constructor for setting configuration variable defaults.
 */
public function __construct() {
	// Set execution path
	if ( stristr( PHP_OS, 'WIN' ) && !stristr( PHP_OS, 'Darwin' ) ) {
		$this->execPath = 'C:\Program Files (x86)\GraphViz\bin';
	} else {
		$this->execPath = '/usr/bin/';
	}

	$this->mscgenPath = '';
	$this->defaultImageType = 'png';
	$this->createCategoryPages = 'no';
}

Any help is appreciated.

--Squeak24 (talk) 16:40, 18 October 2018 (UTC)

I've finally gotten this extension to work on Windows.

# D:\WebApps\mediawiki-1.32.0\LocalSettings.php

# https://www.mediawiki.org/wiki/Extension:GraphViz
wfLoadExtension( 'ImageMap' );
wfLoadExtension( 'GraphViz' );

# D:\WebApps\mediawiki-1.32.0\extensions\GraphViz\includes\Settings.php

#$this->execPath = 'C:/Program Files/Graphviz/bin/';
$this->execPath = 'C:\\Program Files (x86)\\Graphviz2.38\\bin\\';

# D:\WebApps\mediawiki-1.32.0\extensions\GraphViz\includes\GraphViz.php

#$output = wfShellExec( $command, $ret );
exec( $command, $output, $ret );

if ( $ret != 0 || $output ) {
	#wfDebug( __METHOD__ . ": command: $command ret: $ret output: $output\n" );
	wfDebug( __METHOD__ . ": command: $command ret: $ret output: " . implode( "\n", $output ) );
	return false;
}

Explanation:

• I couldn't get the shell-command (wfShellExec(), which uses MediaWiki's Shell::command()) to work at all on Windows, even without spaces in the execPath. The command worked fine in cmd.exe, but retured exit code 1 when called from PHP. Replacing it with PHP's exec() worked.
• I tried to set the extension's execPath from LocalSettings.php, but I couldn't get that to work. (Tried setting $wgGraphVizExecPath and $wgGraphVizSettings->execPath, neither had an effect.) Ended up setting it in Settings.php instead.

--Ogroot (talk) 10:39, 2 May 2019 (UTC)

no sudo

I run mediawiki on a VPS where I don't have sudo, so I can't run sudo apt-get install graphviz. Also, graphviz is not pre-installed. Would it be possible to install it with composer? They do have a package for it, but it also talks about having to run a sudo install. How can I still run this extension without sudo on the server? Tenbergen (talk) 04:25, 18 March 2019 (UTC)

No, it can't be installed with Composer. Can you request that whoever maintains your system install it? It's available in most OS package repositories. Sam Wilson 17:17, 19 May 2019 (UTC)

GraphViz on MW 1.33

Tracked in Phabricator
Task T226616

Will the plugin work in MW v1.33.1?

Until today 14 Oct. 2019, it still doesn't work on v1.33 Neverfever (talk) 21:36, 14 October 2019 (UTC)

This is a known issue and is being tracked in phabricator:T226616. Personally, I think the solution is to move away from storing the generated graphs as wiki files, and instead have a separate PHP service that generates and returns them. I'm not sure what the general consensus is. I've had a go at a couple of patches to fix the issue, but I think maybe the extension isn't used all that much any more so there's not that much interest. Sam Wilson 00:44, 15 October 2019 (UTC)