Extension talk:GnuplotBasic

Use this page for your comment and feedback on GnuplotBasic

Configuration variables
I'm used to setting config variables before I include the extension PHP file. Please consider changing the code to not define the variables in the extension and requiring them to be set in LocalSettings.php in advance. --Dmulter 18:35, 12 March 2009 (UTC)

Gérard 09:18, 15 March 2009 (UTC) Thanks for your comment. The way this extension works with its settings is inherited from the two extensions it is based upon. If you know of an other extension that handles config variables the way you suggest I'll look in to it. Are you interested in using this extension?

Take a look at BugzillaReports and BugMilestone. The latter being a simpler one. --Dmulter 16:49, 25 March 2009 (UTC)

Gnuplot's font environment variables
I also think there should be another config variable that can be used to set the GDFONTPATH environment variable. Maybe use $wgGnuplotGDFontPath and do the export in the extension before executing the gnuplot shell command. --Dmulter 18:35, 12 March 2009 (UTC)

I'm using the extension now and it works great. I'm still working on getting it to find my TTF fonts via GDFONTPATH. Should figure it out soon. --Dmulter 16:49, 25 March 2009 (UTC)

I finally figured out the font path problem. There are probably other ways to solve it, but here's my approach. I set the GD environment variables in my Apache httpd.conf file. Unfortunately the extension does a shell_exec that creates a subprocess that does not inherit any environment variables, so they are not passed to the Gnuplot command. I added 4 lines to the extension code to force the process to use my variables. Here's the existing code with the 4 new lines. Please consider adding this to the extension. --Dmulter 18:26, 25 March 2009 (UTC)

Thanks for your work. I added the environment variable setting to the new version 0.9.4 Although I am not sure why getting- and setting them just before the shell_exec helps the created subprocess to find them. I am running under Windows and do not set the environment variables at all. --Gérard 12:16, 27 March 2009 (UTC)

security
''Note that gnuplot allows far more advanced syntax than is allowed and recognised here. This should however suffice most graph needs from within a MediaWiki instance. ''

So it's still not secure at all? 83.68.75.19 00:30, 10 April 2009 (UTC)
 * MY SOLUTION: do a whitelist instead of a blacklist.

function parsePlotScript( &$scriptline ) {

$wantedCommands = array( "set pm3d"=>"", ";"=>"", "plot"=>"", "splot"=>"", "abs"=>"", "sin"=>"", "cos"=>"", "log"=>"", "sqrt"=>"", "+"=>"", "-"=>"", "*"=>"", "/"=>"", "x"=>"", "y"=>"", "("=>"", ")"=>"", "1"=>"", "2"=>"", "3"=>"", "4"=>"", "5"=>"", "6"=>"", "7"=>"", "8"=>"", "9"=>"", "0"=>"", " "=>""       );

$unwantedCommands = array(               "`" => "",                "set output " => "xxx xxxxxx ",                "shell" => "xxxxx", // potentially harmful                "system" => "xxxxxx", // potentially harmful                "load " => "xxxx ",                "call " => "xxxx ",                "save " => "xxxx ",                "cd '" => "xx ",                "cd \"" => "xx ",                "update " => "xxxxxx "        );

$scriptline = trim($scriptline); if( strlen($scriptline) == 0 ) return false;

// Step 1: Delete everything after the first comment character $p = strpos($scriptline, "#"); if( $p !== false ) { $scriptline = substr($scriptline, 0, $p); $scriptline = trim($scriptline); if( strlen($scriptline) == 0 ) return false; }       // Step 2: Replace unwanted commands with substitutes #$scriptline = strtr($scriptline, $unwantedCommands); #$scriptline=trim($scriptline); #if(strlen($scriptline)==0)return false; #return true;

#safe1 $scriptlinetest=strtr($scriptline, $wantedCommands); $scriptlinetest=trim($scriptlinetest); if(strlen($scriptlinetest)==0) return true; $scriptline="error"; return false; } 83.68.75.19 18:49, 10 April 2009 (UTC)

It's more powerful if it's a really Parser extension
This is a nice extension (easy install, easy use and it works!). There is a problem. This should be tag extension not a Parser extension. I hope this extension can be used with followed format.

--Roc michael 05:04, 11 April 2009 (UTC)

I have corrected the implementation type of this extension to "Tag" in the documentation page. I'll consider changing it to a parser extension. At the moment I don't see the benefit or need for it. --Gérard 12:23, 11 April 2009 (UTC)
 * Hi Gérard
 * Thank you for your reply. Parser extension can be used with arguments. If this extension is a parser extension, users can use it with DPL or SMW just like Ploticus Extension. After someone make a easy use template, other users can generate graph image easily. --Roc michael 00:05, 12 April 2009 (UTC)

I just learned that as of MediaWiki version 1.12 there is a standard #tag magic word that can make a tag-extension behave like a parser-extension. Hope this helps any. For GnuplotBasic that would look like:

The tag remains the same since it is not a MediaWiki hook, but used by the GnuplotBAsic extension. --Gérard 12:50, 24 May 2009 (UTC)

Ask a setting restriction
Hi Gérard

As this extension has security limitations, It can be solved by adding a restriction that users can only add the Gnuplot code in the pages with mediawiki  (or some specific) namespace(s). Something like following: Then, olny users having rights to edit the pages with specific namespaces can use this extension.

Any idea?--Roc michael 13:17, 28 April 2009 (UTC)

error on Windows
When this extension is installed in a path containing a space (c:\Program Files\gnuplot), the extension does not work.

Replace $cmdlinePlot = $wgGnuplotCommand. ' ' . $fname; with $cmdlinePlot = "\"".$wgGnuplotCommand."\"". ' ' . $fname;

does the trick