When trying to access the pdf-view page I get this error:

Fatal error: Call to undefined function php_eval() in C:\wamp\www\drupac\sites\all\modules\views_pdf\views_pdf_template.php on line 476

(however I can see the pdf page using the 7.x-1.x-rc1 version)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

zorax’s picture

Same issue,
I use Commerce PDF Invoice with.
I can enter in the view UI, but can't generate a pdf

maddin2007’s picture

I am not deep enough in Drupal, but a workaround is to use the standard eval-function from php ... works for me fine ... not to use the php_eval() from drupal.
Just replace in the 2 lines in the views_pdf_template.php "php_eval" with "eval" and it works. (line 476 and line 506)

zorax’s picture

It works for me!
thanks a lot!!

drupadawan’s picture

I don't know if there is a particular reason why the 'php_eval' is used instead of 'eval', maybe it can be changed in the module?

(but I thought I had read somewhere that it was used for security reasons, to sanitize the code or something? if so changing it would be unwise..)

farald’s picture

Quickfix: enable core php_filter module.

But; I don't think php_filter should be a required module for views_pdf for the sole purpose of providing php_eval().
I vote for using regular eval instead. Here's a patch.

farald’s picture

Status: Active » Needs review
firebird’s picture

If it's absolutely needed to use eval(), we should keep using php_eval(). It's got a couple of features that have been added there for a reason, see the API docs: http://api.drupal.org/api/drupal/modules!php!php.module/function/php_eval/7

Requiring a core module isn't bad at all in my book, the only problem is that the required module should be listed in the dependencies. This patch adds that.

idflood’s picture

Got the same error, enabling php module fixed the issue. So patch in #7 looks good.

idflood’s picture

Status: Needs review » Reviewed & tested by the community
wusel’s picture

I have the same issue.

But to enable the module "PHP filter" is not a good way. This may open new security-risks.

Wusel

idflood’s picture

@wusel: It will be a security risk if it is added to the filtered text format for instance. But I think that simply enabling the module isn't a risk by itself.

wusel’s picture

@idflood:

I think, if the module "PHP filter" is necessary, then is must be enabled for ALL users at "admin/people/permissions". That would be a big security-hole.

If the patch at #5 would be wrong/insecure, then there must be a solution to avoid this problem. All of my other modules never need the module "PHP filter", so why should this be different to use this module?

Wusel

idflood’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
1.02 KB

The php_eval() function doesn't check for user permission. So it should not be necessary to enable it for all users.

On a side note the eval_before and eval_after variables are empty by default so it looks like eval is not required at all by default.

So with that in mind here is a patch with a different approach.

s.Daniel’s picture

Status: Needs review » Reviewed & tested by the community

Works as well and it's a better solution in my opinion. PHP input through the UI is always something I would like to see avoided but is better than a http 500 error that you currently get without php module.

Note: The php module is about to be removed from core in D8 http://drupal.org/node/1203886 .

Closed http://drupal.org/node/1457864 as duplicate.

Simon Georges’s picture

Simon Georges’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
1019 bytes

What about using module_exists() instead of module_load_include()?
See attached patch. If there's a consensus with it, I'll commit it.

This patch is part of the #1day1patch initiative.

Simon Georges’s picture

Status: Reviewed & tested by the community » Needs review
vegansupreme’s picture

Status: Reviewed & tested by the community » Needs review

This patch doesn't work for me. It is an improvement, in that PDF rendering continues, but the PHP doesn't get evaluated/executed.

maxplus’s picture

Hi,
after I enabled the php filter and added permission to the needed roles, my problem was solved

Thanks

vegansupreme’s picture

Still can't get it working. I have PHP filter, and all users have full permissions (on dev site)

Simon Georges’s picture

@vegansupreme Did you add other patches (like the one that have recently been committed to the -dev version)?

vegansupreme’s picture

I only applied this patch to the latest dev version (7.x-1.0+5-dev)

vegansupreme’s picture

I tried this on another host. Still, any PHP code I enter has no effect. I've tried it in PHP 5.3 and 5.4. PHP filter is enabled and permission granted to all users.

haegar der schreckliche’s picture

It's the same problem for me. With the patch the fatal error is gone but the "PHP Code Before/After Output" is not evaluated.

Simon Georges’s picture

Does anyone know why there was a switch from eval() to php_eval()?

firebird’s picture

vegansupreme’s picture

In the API documentation, it says

Using this wrapper also ensures that the PHP code which is evaluated can not overwrite any variables in the calling code, unlike a regular eval() call.

But isn't this exactly what we need to do for basic page layout, for example $x=3;? Is that not overwriting a variable?

Also I noticed that the code needs to be wrapped in <?php ... ?> which is the opposite of how PHP was previously handled. Even still, I can't get it working.

psicomante’s picture

This notice has been popped up in our site.

Notice: Undefined index: eval_before in PdfTemplate->renderRow() (line 478 di /sites/all/modules/views_pdf/views_pdf_template.php).
Notice: Undefined index: eval_after in PdfTemplate->renderRow() (line 508 di /sites/all/modules/views_pdf/views_pdf_template.php).

However i fixed this error because it is related to #13

garphy’s picture

@vegansupreme : +1, regarding #27.

The reason of eval_before/eval_after to exist at all is to allow an alteration of the variables passed to TCPDF API.

We switched back to eval() on our production code bases.

If there's a general consensus for not using eval(), it'll be mandatory to design an alteration API.

Maybe any variables passed to TCPDF should be kept in a context array/object that can be altered with drupal_alter() hooks (ala theme variables).

killua99’s picture

Priority: Normal » Critical
Status: Needs review » Reviewed & tested by the community

Exist a patch to handle this issues and others. Please see #2032189: Multiple issue fixing in a single patch and review others issues patch.

This is RTBC, and ready to apply.

killua99’s picture

Priority: Critical » Normal
Status: Reviewed & tested by the community » Needs review
FileSize
298 bytes

The solution it's required the PHP core module, because we need that wrapper.

killua99’s picture

Status: Needs review » Fixed
garphy’s picture

Status: Fixed » Needs work

Well I think we're doing it wrong in that issue.

AFAIK somebody must have wanted to follow some security practice by killing theses two eval()s and replace them with hardened drupal's php_eval().

But let's step back : php_eval is there to sanitize and safely evaluate arbitrary and potentially unsafe code and capture its output to return it. On top of that, it prevent evaluated code from altering any variable of the calling context.

Look at the code ! We're even not retrieving the return value of php_eval so the whole process is pointless. (Until someone come with a valid use case)

eval() is (was) there to allow usages of TCPDF that the original maintainer couldn't have predicted but it clearly demonstrate a lack of a clean API here (hook, drupal_alter, plugin, ...)

IMHO the best thing to do is to eventually revert back to eval while we can design a more elegant extension mechanism.

That change bothered any concerned developper that I know and nobody can explain why we introduced it. Let's revert all that stuff.

killua99’s picture

Status: Needs work » Closed (fixed)

Stay this close while we do a hook/alter/theme. We know eval it's dangerous. So php_eval will stay until we replace it.

We have 4 post with the same problem the php_eval and eval.

garphy’s picture

I don't get it.

1. if you think vital to remove any eval() from the code then you can simply remove them. The php_eval() calls are useless. They do *nothing*.

2. There's many of us relying on this feature which is now consequently broken. this is a big regression and as we have not yet designed a replacement, you should put back eval() and clearly state that it's deprecated and pending removal.

candelas’s picture

:)
thanks for using your time resolving this.
now the feature doesnt work (i was trying to use it) and it is very needed to correct interpretations from html to pdf with php searches or other functions.
if not, it should be out from the interface for people trying to use it.
i tried with php_eval and without. i have php filter module enabled.

candelas’s picture

after digging for knowing why i couldnt use $content, i found in views_pdf_template.php line 495

    // Run eval before.
    if( !variable_get('views_pdf_prefer_eval', FALSE) ){
      php_eval($options['render']['eval_before']);
    }else{
      eval($options['render']['eval_before']);
    }

but i dont find any place where that varible is defined. if i change

if( !variable_get('views_pdf_prefer_eval', FALSE) ){
      php_eval($options['render']['eval_before']);
    }else{

to

if( !variable_get('views_pdf_prefer_eval', FALSE) ){
      eval($options['render']['eval_before']);
    }else{

manipulations on $content work.
i have the php filter module enable i realize that its better php_eval but it doesnt work in my case (last dev).

garphy’s picture

You can set the variable value in your settings.php

I didn't bother to provide an administrative UI for that as it's obviously a temporary solution.

candelas’s picture

@garphy in drupal there are many kinds of users, and not all as good techs as you :)
i suggest that if you do a thing like that, at least, put in documentation (like that you dont need to make the interface part). that would avoid time to people that starts to use this module or is a front-end developer.

at the moment, as i am not as good tech as you, i dont understand why if i have the php filter module enabled things like

$content = strtoupper($content);

doesnt work (i dont put the php part) unless i remove php_eval and put only eval.

i am following this issue at https://drupal.org/node/2040739 with very good work from killua99. it looks like this module is going to be bug cleaned at least and very useful :)
i am using it for commerce invoice and i think many people making commerce sites or views are going to be interested.