Server Change Causing Script Not To Work

Trying to move a site to a new server but a virtual php include quit workin

[webfirst]

I hate being dumb to these types of things but I am trying to move a site to a different server because of so much downtime amongst other issues with the current hosting company, but one of the includes doesn't work on the new server, at least not as it was written before.

Ok, here's the scoop,

The site uses php imbedded in html so I use this code in the htaccess: AddHandler application/x-httpd-php .html .htm

I then place an include on the page where needed like this:
<script language="php"> virtual("/cgi-bin/widgets.pl"); </script>

This worked perfect on the old server, but not on the new server. The new hosting provider gave this help:

###START MESSAGE###
"Unfortunately, as it turns out, the virtual() function is unavailable on a server configured with PHPSuExec. This means that this bit of code:

<script language="php"> virtual("/cgi-bin/widgets.pl"); </script>

must be turned into this:
putenv('REQUEST_METHOD=GET'); putenv('QUERY_STRING=arg=value');
passthru("/cgi-bin/widgets.pl");

in order to maintain the security of the site and to also enable the script to function correctly."
###END MESSAGE###

I inserted this code but it still doesn't work. It does call the file that the pl file prints(hope that's the right term), which is a random line from a simple txt file, but this is what shows in place of the actual content:

Content-type: text/plain

Just to be clear what the pl file looks like and does, here it is:

#!/usr/bin/perl
print "Content-type: text/plain\n\n";
$WidgetDelimiter = "\\(1\\)";
$WidgetFile = "data/somepage.txt";
open(WIDGET, "$WidgetFile") ¦¦
die "Cannot open $WidgetFile\n";
@widget = <WIDGET>;
$bigdata = join("",@widget);
@widget = split(/$WidgetDelimiter/,$bigdata);
#@widget = split(/\(1\)/,$bigdata);
$WidgetCount= @widget;
srand();
$WidgetIndex = int(rand($WidgetCount));
print "$widget[$WidgetIndex]";

The txt file is nothing but sentences separated by the delimiter (1) as shown in the above pl file.

Like I said, it has worked with no problems for nearly a year on the old server but not at all on the new.

Is the code from the new hosting provider correct or is it missing something? Personally I've never seen this before and if anyone has any input, please give it.

[Habtom]

I might be missing something, but if you are just including the file why don't just use include or require?

<script language="php"> virtual("/cgi-bin/widgets.pl"); </script>

<?php include("/cgi-bin/widgets.pl");?>
OR
<?php require("/cgi-bin/widgets.pl");?>

Assuming this is still a valid path with your new host.

Habtom

[webfirst]

I have tried each of the includes you listed and the first was our original include line, and none of them work. In order for the pl file to work, I believe that the virtual include or something equal is needed. The pl file acts as a medium that tell which line of the txt file should be printed on the page.

To my limited knowledge, it must call the script to run, not print it on the page. A staight include such as <?php include("cgi-bin/widgets.pl");?> tries to print the contents of the pl file on the page and not run the script, at least this is how it appears to be happening.

The site has other includes like this <script language="php"> include("footer.html") </script> that are working fine, but they don't have to do anything. It seems to be this one type of script that actually does something that is not functioning.

[londrum]

i think it's porbably because you can't use absolute URLs in an include. you can only use relative URLs, or the full server path.
so
/cgi-bin/
won't work.
try changing it to
../cgi-bin/ (or whatever the relative path is)

that is why your footer.html URL is working okay -- because that is a relative path.

[webfirst]

Thanks for the help everyone. I now have it working. The solution was the relative page. For some reason, ../cgi-bin/ wouldn't work so I tried the full url http://www.somesite.com/cgi-bin/widgets.pl and now it works perfect again.

Thanks again for helping.