## php error with svg=true

Help
2009-09-29
2013-04-30
1 2 > >> (Page 1 of 2)
• Chris White - 2009-09-29

Setting svg=true causes the following error

Warning: DOMDocument::loadXML() : Empty string supplied as input in C:\xampp\htdocs\mediawiki\extensions\SemanticGraph\includes\SemanticGraphHelperFunctions.php on line 176

Fatal error: Call to a member function getAttribute() on a non-object in C:\xampp\htdocs\mediawiki\extensions\SemanticGraph\includes\SemanticGraphHelperFunctions.php on line 180

• Rob Challen - 2009-10-03

I'm getting a bit rusty on this bit of code now…

I'm assuming you are getting this to work with non svg images.

This could be a result of dot not correctly generating the SVG output file, which I guess could depend on your graphviz setup maybe. This will show up in the system logs on a linux system but not sure where it would show up on XAMPP.

try and run the dot command manually - you can get the filename (or file) of the .dot from the &quot;click to download dot source…&quot; when it works with non svg method and then run the dot command using:

dot  -Tsvg -o somefile.svg dotsourcefilename.dot

see if that gives any errors &amp; let me know…
Rob.

• Chris White - 2009-10-05

When I ran the command line dot threw out tons of syntax type errors that looked like
&lt;pre&gt;&lt;code&gt;
ambiguous &quot;3C&quot; splits into two name: &quot;3&quot; and &quot;C&quot;
&lt;/code&gt;&lt;/pre&gt;

I trimmed down my query so that it would only graph a couple of nodes.  This gave a brand new syntax error.
&lt;pre&gt;&lt;code&gt;
syntax error near line 2
context: &gt;&gt;&gt; rankdir=LR, &lt;&lt;&lt; ranksep=1;
&lt;/code&gt;&lt;/pre&gt;

Here is a copy of the downloaded code
&lt;pre&gt;&lt;code&gt;
digraph &quot;fee6703757cd4bc831fdc0954131db52&quot; {
rankdir=LR, ranksep=1;
node ;
VMServer1 ;
DC1 ;
ESXi_Server ;
JIRA__opbra_aps01_clbra_ ;
HP2420 ;
Windows_2003_Server ;
Crowd ;
Fisheye+Crucible ;
JIRA ;
JavaFX ;
MySQL ;
Integrating_with_Crowd ;
VMServer1 -&gt; DC1;
VMServer1 -&gt; ESXi_Server;
VMServer1 -&gt; JIRA__opbra_aps01_clbra_;
DC1 -&gt; HP2420;
DC1 -&gt; VMServer1;
DC1 -&gt; Windows_2003_Server;
JIRA__opbra_aps01_clbra_ -&gt; Crowd;
JIRA__opbra_aps01_clbra_ -&gt; Fisheye+Crucible;
JIRA__opbra_aps01_clbra_ -&gt; JIRA;
JIRA__opbra_aps01_clbra_ -&gt; JavaFX;
JIRA__opbra_aps01_clbra_ -&gt; MySQL;
JIRA__opbra_aps01_clbra_ -&gt; VMServer1;
JIRA__opbra_aps01_clbra_ -&gt; Windows_2003_Server;
Crowd -&gt; Integrating_with_Crowd;
}
&lt;/code&gt;&lt;/pre&gt;

When I plugged that code into GVEdit (from graphviz) it also threw the same syntax error, but it did produce a graph (both in jpg and svg).

I don't particularly need svg format, I just want it to actively draw the graph on screen.  If I include the engine=dot argument, there is no error, but there also is not an 'on screen' display (besides the download code link).  When I set the svg=true is when the php error occurs.

• Chris White - 2009-10-05

Wow - I apologize for screwing up the formatting in the previous post.  The preview pane showed the formatting correctly using the &lt;pre&gt; and &lt;code&gt; tags.

• Rob Challen - 2009-10-05

The Rankdir=LR error is a known issue for 0.8.5 which I haven't updated the code for - it should produce a non fatal warning in the logs only. I'll roll the fix into another release one day. You can ignore that one - it isn;t the cause of your problem.

I'm not sure what you are expecting the svg option to do - it basically does the same as the png version - it doesn;t dynamically refresh or anything (the whole extension suffers a bit from the effects of page caching in Mediawiki anyway)

I reuse the wiki article names as the node names in the graphviz and I think the problem may be to do with article names in your wiki being somehow incompatible with graphviz (but only the svg option) - maybe using unescaped html characters possibly. If you post a copy of the errors and a copy of the dot file that produces them I can investigate.

Is the mediawiki publically accessible? I can have a look if so.

• Chris White - 2009-10-05

Its not a public wiki (corporate intranet) so I can't give you a link to it.

Maybe I misunderstood what the results were.  I thought that it would actually produce a displayed graph, not just the code to create a graph.

using the graphviz extension I was taking the code that semantic graph produced and just putting it between &lt;graphviz&gt;&lt;/graphviz&gt; tags.  Perhaps as an option for a future version you could include this instead of (or addition to) the download option.  Then to dynamically update all we need is to force a page edit event.

• Rob Challen - 2009-10-05

OK. It should definitely show a visualisation of the graph in either mode, either as a png image or as a svg image - the svg image just allows for scaling/zooming. If all you are getting is a link to the dot source then it is not working properly. It should recalculate this every time the page is edited (but not necessarily viewed, although you can disable caching on the wiki to achieve this).

Reasons for this could be that the script cannot write to the image output directories which are generally in the /images/hypergraph /images/mm and /images/dot directories under the mediawiki root, hence the extension cannot write the graphs out: I'm not sure how to achieve that on windows under XAMPP, if image uploads are working on your wiki then this should be OK.

The other thing that may be wrong is that the command to execute the dot command may be incorrectly set as it defaults to a linux command &quot;/usr/bin/dot&quot;. If the dot command you are using is non standard (e.g. C:/Program_files/dot.exe or something) then you may need to set those as a config option in your localsettings.php

$wgSemanticGraphSettings-&gt;dotCommand = '/path/to/dot';$wgSemanticGraphSettings-&gt;neatoCommand = '/path/to/neato';

This all probably could be documented better, and i'm afraid is untested on windows, but i haven;t had so much spare time to do this at the moment - sorry.

Let me know how you get on.

• Rob Challen - 2009-10-05

BTW the extension has the potential to consume a lot of resource if you try and generate big graphs. Start with a small depth setting.

• Chris White - 2009-10-05

Currently I have the variable set as

dotCommand = &quot;C:\\Program Files\\Graphviz2.24\\bin\\dot.exe&quot;;

This is what I had to do to get the graphviz extension working so I used the same settings for Semantic Graph.  Just for the hell of it, I tried of couple of different configurations for the variable, and none of them worked.

Files are set to be written to C:\xampp\htdocs\mediawiki\images\dot - which I set up during the graphviz install.  I know that the image files are being created, because the download link is properly referencing them.

Is there anyway to see an error output as to why the graph is not being displayed?

• Chris White - 2009-10-05

Error above, the variable setting is &quot;C:\\Program Files\\Graphviz2.24\\bin\dot.exe&quot;;

• Chris White - 2009-10-05

wow - no error, the post is altering my path…  it is not single slash, but a double slash that is being used to separate the path values

• Rob Challen - 2009-10-06

if the dot command as issued by the extension is working the in the directory &quot;C:\xampp\htdocs\mediawiki\images\dot&quot; you should see both input files which will be of the form someId.dot and an associated output file (which is of the form someId.svg or someId.png depending on the svg setting)

if you can't see the svg or png files in the directory then you will not be seeing any graphs rendered (but the link to dot source will work). If that is the case (i.e. there are no svg or png files in the directory) then the error you are seeing could be explained - the call out to dot.exe is not rendering the files, and there is nothing for the extension to pick up to display as a result. The extension is also failing silently to display a png version of the graph, I would guess, and failing noisily when svg because i have do do a little post processing on the file before display to add in the zoom functions.

So my theory is that the extensions call to dot is not executing for some reason in all cases. This could be a bug in the extension or could be a local setup problem. To find out which I would need to see the error that is thrown when the call is made to the dot. To do this I need you to edit the file extensions/SemanticGraph/includes/SemanticGraphFiles.php and do the following:

line 69, 70, 79
remove the @ sign such that :

@$ret = shell_exec($….);

becomes

$ret = shell_exec($….);

then you should see some more errors (I think) which hopefully will be informative.

• Chris White - 2009-10-07

I made the changes (and did a new query) but did not see any errors.  Should they be in the wiki, or output to a log file?

• Rob Challen - 2009-10-12

sorry for delay. I am trying to replicate this and been trying to set up an xampp mediawiki on windows. I notice the default error reporting suppresses warnings, thus may not explain what is going on.

Try changing in the /xampp/php/php.ini file to have the following settings in the error handling and logging section:

error_reporting = E_ALL

display_errors = On

log_errors = On

error_log = &quot;C:\xampp\xampp\apache\logs\php_error.log&quot;

Rob.

• Rob Challen - 2009-10-12

And reboot apache after making the changes to php.ini

• Rob Challen - 2009-10-12

Well I have set it up and a simple test graph is working OK on windows with XAMPP, both png and svg formats. I can;t reproduce the error. Had to work through a few problems with parser functions extension in the semantic bundle but otherwise all ok…

versions:
MW 1.15.1;
SMW: from semantic bundle…. 1.5;
Semantic Graph 0.8.5;
Graphviz 2.24;

• Rob Challen - 2009-10-12

The settings were:

&lt;code&gt;
require_once(&quot;$IP/extensions/SemanticGraph/includes/SemanticGraph2.php&quot;);$wgSemanticGraphSettings-&gt;dotCommand = 'C:\Program Files\Graphviz2.24\bin\dot.exe';
$wgSemanticGraphSettings-&gt;neatoCommand = 'C:\Program Files\Graphviz2.24\bin\neato.exe';$wgSemanticGraphSettings-&gt;circoCommand = 'C:\Program Files\Graphviz2.24\bin\circo.exe';
$wgSemanticGraphSettings-&gt;fdpCommand = 'C:\Program Files\Graphviz2.24\bin\fdp.exe';$wgSemanticGraphSettings-&gt;twopiCommand = 'C:\Program Files\Graphviz2.24\bin\twopi.exe';
$wgSemanticGraphSettings-&gt;maxToDispUnfolded = 10; &lt;/code&gt; • Chris White - 2009-10-12 single slashes or double slashes? • Chris White - 2009-10-12 and is it 'C:\&nbsp; or &quot;C:\ ? • Chris White - 2009-10-12 I think I may have found the problem - In my apache error log it shows that it is looking for &lt;path&gt;&lt;filename&gt;.png. The path and filename are correct, however the file type is .dot not .png. Here is the query command I have been using to test with {{#sgraph:resource=VMServer1 |depth=3 |engine=dot }} • Rob Challen - 2009-10-12 the require_once line must be double quotes, the others shouldn't matter in this particular instance - single is probably better php. The error here is only showing that the png is not being generated from the dot file. The flow in the extension is: - 1) Create dot file - 2) Invoke dot.exe with dot file to output png or svg - 3) Display resulting png or svg inline What you are seeing is a result of the call to dot.exe not working for some reason hence no png or svg and no picture. Might be your$wgSemanticGraphSettings, your apache/php setup, your graphviz sertup, or file permissions on the output directory. I can't recreate it so I can't really tell why unless you can get the logs to display the outcome of the call to the dot command. This should be happening now you removed the @ signs and your error level has been changed to E_ALL in php.ini.

I'm at a bit of a loss. Did you get the Extension:GraphViz working previously?

• Chris White - 2009-10-12

I did the changes to php.ini (and restarted apache) but I don't see an error log present.

Here are all of my SemanticGraph settings
# Added for Semantic Graphs
require_once(&quot;$IP/extensions/SemanticGraph/includes/SemanticGraph2.php&quot;);$wgSemanticGraphSettings-&gt;dotCommand = 'C:\Program Files\Graphviz2.24\bin\dot.exe';
$wgSemanticGraphSettings-&gt;neatoCommand = 'C:\Program Files\Graphviz2.24\bin\neato.exe';$wgSemanticGraphSettings-&gt;circoCommand = 'C:\Program Files\Graphviz2.24\bin\circo.exe';
$wgSemanticGraphSettings-&gt;fdpCommand = 'C:\Program Files\Graphviz2.24\bin\fdp.exe';$wgSemanticGraphSettings-&gt;twopiCommand = 'C:\Program Files\Graphviz2.24\bin\twopi.exe';
$wgSemanticGraphSettings-&gt;mmAppletPath = 'http://10.51.200.13/mediawiki/extensions/SemanticGraph/libs/freemind.jar';$wgSemanticGraphSettings-&gt;maxToDispUnfolded = 10;

The Graphviz extension does work, and here are the settings I used for it.
# Added for GraphViz
include(&quot;extensions/Graphviz/Graphviz.php&quot;);
\$wgGraphVizSettings-&gt;dotCommand = &quot;C:\\Program Files\\Graphviz2.24\\bin\\dot.exe&quot;;

I can see graphziv creates files in the same directory that SemanticGraph is looking for.

I'm not sure you understood my point about filename being mismatched.  According to the log its looking for &lt;filename&gt;.png to display to the wiki page.  There is a file in that location, but with the .dot extension, not the .png extension.  So following your flow above, it is invoking dot.exe, but its not correctly ordering it to output into .png, or I have misconfigured dot.exe so that it cant output into .png.  Do you know a command line test that I can peform to validate that dot.exe will output into .png?

• Chris White - 2009-10-12

..and I am not a fan of this forums attempts to implement markup.  No matter what I do to properly show code, it seems to ignore it.

• Chris White - 2009-10-12

using GVedit, I was able to create a .png file in the proper directory.  So I assume that dot.exe is configured correctly to do it.

• Chris White - 2009-10-12

Also, using GVEdit - If I open the file that SemanticGraph output, and then have it save as a .png or dot .svg format it works.  The problem has to be the output from dot.exe to .png/.svg

1 2 > >> (Page 1 of 2)

## Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks