Allow to pass local variables to php_eval()

What would be the advantage of this over the current php_eval() in Drupal 7?

New features would be added to 7.x, so I'm changing the version number.

http://api.drupal.org/api/function/php_eval/7 we develop for Drupal 7 so see this. All PHP related functionality goes in PHP module. Check http://drupal.org/node/320 on how to check out HEAD.

Yes. Your original patch was against Drupal 6 but features go into Drupal 7. Also it was in common.inc and now it needs to be in php module

attached is a patch which tries to merge the previous patch and php_eval in php.module.

+1 for the idea of passing $variables to make available to the user
several of my modules already use a custom version of drupal_eval() because it was basically useless for a lot of cases if you had no data available to work with.
Anyone know what went wrong in the test? Was it the changed return value?

Re-rolled against HEAD.

+ added a couple of tests, including simple variable scope security test.

Even better. Even more useful. Even more secure.

Yay, tests pass! :)

With fields + stuff in core, this patch becomes a bit more important.

Great, thanks for taking an interest here sun. I should mention it would be convenient if the php filter format could be given vars, and the filter_form() could explain available variables to the user. Haven't given that much thought though.

@danielb: Please forget about passing variables to the PHP code filter. The filter system, as of now, does not support any kind of context.

This patch is about php_eval(), not about the PHP filter. I know of a couple of contributed modules that could not use php_eval() before, because the evaluated PHP code needed access to variables in the context, such as $node.

In terms of Drupal core, this facility would be very helpful for Block page visibility settings, where you can enter PHP code in case the PHP module is enabled.

Why not make the default array() and spare the isset? array $foo = NULL is weird, I say.

@sun, I know the filter system doesn't support this now, but it absolutely should. Using filter formats is an ideal and consistent way to allow php input, and making the variables available there is just as important as making them available in a custom php textarea. Giving users the ability to use variables is the central vibe of this issue, and that will have to be the next step. A further benefit is that we need a consistent standard help interface for explaining to the user what variables are available for them to use, similar to the tokens fieldset.

Would it be worth while changing the function to something like this so that it can also be used for modules like CCK where they want to get an actual PHP variable back, and not HTML. I've been using the following on some of my custom projects for some time now.

function eval_php($code, $drupal_eval = TRUE, $variables = NULL) {
  global $theme_path, $theme_info, $conf;

  // Store current theme path.
  $old_theme_path = $theme_path;

  // Restore theme_path to the theme, as long as php_eval() executes,
  // so code evaluated will not see the caller module as the current theme.
  // If theme info is not initialized get the path from theme_default.
  if (!isset($theme_info)) {
    $theme_path = drupal_get_path('theme', $conf['theme_default']);
  }
  else {
    $theme_path = dirname($theme_info->filename);
  }

  ob_start();
  // We need to get tricky here, as when display errors is off and
  // there is a syntax error, PHP returns a 500 status code instead
  // of a 200. To stop this, we turn on output buffering, enable the display
  // of errors, then run our code, then reset the state of display errors.
  ob_start();
  $display_errors = ini_get('display_errors');
  ini_set('display_errors', '1');

  // Allow the code to utilise passed in variables by reference, but
  // don't overwrite existing variables.
  if (isset($variables)) {
    extract($variables, EXTR_SKIP | EXTR_REFS);
  }
  if ($drupal_eval) {
    print eval('? >'. $code); <----------------------------- REMOVE SPACE BETWEEN ? > BEFORE USING CODE!
    $output = ob_get_contents();
  }
  else {
    $output = eval($code);
  }
  ini_set('display_errors', $display_errors);
  ob_end_clean();

  // Recover original theme path.
  $theme_path = $old_theme_path;

  return $output;
}

Basically, the $drupal_eval flag modifies whether we get back php values, or a string of output. Of course, any errors that occur when returning PHP values will be silently lost. Whether this is good or bad is up for someone else to decide.

#12: drupal.php-eval.12.patch queued for re-testing.

Bumping to D8...

#12: drupal.php-eval.12.patch queued for re-testing.

This requires an update as some things have changed in tests.