Declaring functions in node content results in cannot redeclare fatal error in eval()'d code

Happened on a legacy site...

Fatal error: Cannot redeclare getosandplugin() (previously declared in /var/www/example/drupal/includes/common.inc(1685) : eval()'d code:14) in /var/www/example/drupal/includes/common.inc(1685) : eval()'d code on line 46

It shows how to edit but doesn't explain why the eval code is running twice...
http://emphaticnonsense.com/2009/11/12/drupal-fatal-error-cannot-redeclare-function/

Except that on this site it is really annoying because going to the node edit page triggers the same error.

Ah, here are the people with the same problem:

fatal error, cannot redeclare function supposedly previously declared
http://drupal.org/node/119165

Someone linked to this but that's not really the issue:
Fatal error: Cannot redeclare blah_function() in ../modules/blah.module
http://drupal.org/node/72099

Can't use php functions in body of nodes
http://drupal.org/node/79315

It is probably the nodewords (meta tags) module trying to parse out a description from this field.

http://drupal.org/node/76437#comment-431308

9

KarenS - August 17, 2006 - 19:57

I ran into this and reported it somewhere else, but I've lost track of where. It's because each field is evaluated at least twice, once by the field module and once by the content module. This is because the content module has to have a crack at the field info, too, so I don't think the fact that the field is massaged twice is a bug exactly. And it's possible that it gets massaged more than twice (the widget may have a shot at it too, maybe others).

My immediate workaround was to wrap any functions with if (!function_exists('myfunction'). The only other way to fix it is somehow to figure out exactly which pass through the field should trigger the eval, instead of evaling on every pass, but I'm not sure which would be the right time to do that. It might be easier just to check for function_exists.

Ideally you would not be using PHP in node body or field content at all, let alone defining functions there. Still, this is annoying for those times when ideal is the least of your worries. In this case, for legacy forms that will be replaced by an ecommerce solution (probably Ubercart) in the next phase, we put all the functions in a file, placed as an orphan in the site's custom module, which is called with drupal_module_load(). This prevents the duplicate parsing of functions and the fatal errors, and almost makes putting code in nodes not look like a total terrible practice hack. Almost.