Hello Jarry,
On Thu, 2011-01-20 at 09:22 +0100, Mr. Jarry wrote:
That php-script works, when I call it directly.
If you call a php script via the Drupal PHP Filter it is included using eval() from within a function. The result of this is that none of your global variables remain visible as global. This is to avoid name space collisions, i.e. the overwriting of Drupal variables and functions with values coming from your script.
Also, your script should not output any http headers (and preferably no html headers and body tag, so you cannot use template rendering engines like Smarty to display the page. You *can* use a template engine to return the content and echo that, as Drupal uses output buffering (ob_start()) for eval()ed scripts.
I managed to get Retrospect GDS working via the PHP Filter by making all of the global variables it uses explicitly global again. Say you got something like
$myglobalvar = 1;
you have to change this to
$GLOBALS['myglobalvar'] = $myglobalvar = 1;
After that explicit globalization you can use your variables as usual. It looks a bit odd but it doesn't break any code if you call it directly.
Of course you should make sure your variables and functions do not clash with internal Drupal variables and functions. A save way to do this is to prefix your variables with a unique string, f.e. renaming $myglobalvar to $myapp_myglobalvar.
In the case of Retrospect I had only one name space collision with Drupal, being the function t().
Even better of course would be not to rely on any variable being global, but that might require a bit of a rewrite of your code to pass all parameters via function calls.
Regards, Leonard.