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.

   // execute the gnuplot command
   $cmdlinePlot = $wgGnuplotCommand . ' ' . $fname;
   $gdpath = getenv("GDFONTPATH");
   putenv("GDFONTPATH=$gdpath");
   $gdpath = getenv("GNUPLOT_FONTPATH");
   putenv("GNUPLOT_FONTPATH=$gdpath");
   shell_exec($cmdlinePlot);

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

{{#gnuplot:
set terminal png transparent font SimSun 12
set title "GnuplotBasic Sample 2"
plot '-' using 1:2 t 'line 1' with linesp lt 1 lw 1, \
     '-' using 1:3 t 'line 2' with linesp lt 2 lw 1
{{#plotdata:
#num  line1  line2
  1    2     3
  2    4     9
  3    8     27
}}
}}

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

{{#tag:gnuplot|
set terminal png transparent font SimSun 12
set title "GnuplotBasic Sample 2"
plot '-' using 1:2 t 'line 1' with linesp lt 1 lw 1, \
     '-' using 1:3 t 'line 2' with linesp lt 2 lw 1
<plotdata>
#num  line1  line2
  1    2     3
  2    4     9
  3    8     27
</plotdata>
}}

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

$wgGnuplotnamespce = array( 'Namespace', 'Project' );
require_once("$IP/extensions/GnuplotBasic/GnuplotBasic.php");
$wgGnuplotCommand = "<yourGnuplotPath>";

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

Alternative chart extension pChart4mw

As of 2009-11-11 the new extension pChart4mw (PHP Chart for Mediawiki) was released. It serves as a good alternative for gnuplotbasic. As you can read on this discussion page there are several pros and cons using gnuplotbasic just because it uses the external (executable) program gnuplot.

After discovering the pChart library beginning 2009 a colleague and I were inspired to create a new extension to be able to have charts for MediaWiki. This resulted in pChart4mw.

If you're interested in line, bar, pie, scatter, radar and bubble charts for MediaWiki have a look at what pChart4mw can do for you.

Gérard 06:30, 11 November 2009 (UTC)

Bug 54221: Support for text/syntax/markup driven or WYSIWYG editable charts, diagrams, graphs, flowcharts etc. (Identify, develop, review and deploy extension on Wikimedia wikis to add)

FYI. --Nemo 12:19, 17 September 2013 (UTC)