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 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:

Example 1 from http://www.mediawiki.org/wiki/Extension:GraphViz
 digraph example1 {Hello->"World!"}

Example 2 from http://www.mediawiki.org/wiki/Extension:GraphViz
 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; }

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 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  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:. 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,

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. 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)

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:

 graph { A [label=< ]; B [label=< ]; A -- B [taillabel="1",headlabel="2",color=";{{MyPort:B:2]]"]; } 

My extension takes this tag input and replaces the patterns it finds in the content with icons that represent the state of the HOST. The patterns get replaced with a color that reflects the interface state of the PORT on the HOST. The output of the extension is a tag with the 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)